Subscribe to get latest news delivered straight to your inbox


    Operationalizing Consent Under the DPDP Act: A Legal Review of the BRD Framework

    • 27.06.2025
    • By Suvarna Mandal, Sanchit Shrivastava and Saloni Neema
    Saikrishna & Associates

    Introduction

    • The Digital Personal Data Protection (DPDP) Act, 2023 establishes consent-based processing as the cornerstone of lawful data governance. Under the Act, consent must be free, specific, informed, unambiguous, unconditional, and tied to a clear affirmative action by the data principal. In this context, implementing automated, transparent, and accountable consent management systems is no longer optional—it is a legal necessity and a strategic imperative.
    • Effective consent management enables Data Principals to exercise meaningful control over their personal data by determining what data they share, for what purpose, and with whom. This includes the ability to grant, modify, or withdraw consent at any point. For Data Fiduciaries, the process involves not only capturing valid consent but also ensuring its secure storage, real-time traceability, and lawful application throughout the data lifecycle.
    • As part of the “Code for Consent” Innovation Challenge, the Ministry of Electronics and Information Technology (MeitY), through its Startup Hub platform, released the Business Requirements Document (BRD) for Consent Management. The BRD is designed to assist startups and developers in building Consent Management Systems (CMS) that align with the Digital Personal Data Protection (DPDP) Act, 2023, and the anticipated obligations under the forthcoming Draft Rules. While the BRD does not carry legal force and is not binding, it serves as a persuasive technical and policy reference. Its structured guidance may influence how the Data Protection Board of India interprets compliance expectations, particularly with respect to operational best practices. Accordingly, organisations should view the BRD as a supplementary implementation framework, rather than a substitute for statutory compliance under the DPDP Act and its upcoming rules.
    • The Consent Management System (CMS) outlined in the BRD presents a detailed, lifecycle-based framework for managing user consent. A CMS is a technical and administrative framework designed to oversee the entire lifecycle of user consent—from collection and validation to updates, renewals, and withdrawals. Its core purpose is to help organisations manage consent in a manner that is both legally compliant and user-centric.
    • A robust Consent Management Platform (CMP) typically includes:
      • Customisable consent interfaces, such as banners tailored to user needs, including geolocation-sensitive preferences.
      • Cookie auto-blocking functionality, ensuring that no tracking occurs before consent is explicitly obtained.
      • Immutable audit trails, allowing businesses to retain verifiable records of each consent interaction—critical for demonstrating compliance during regulatory audits.
    • Beyond procedural compliance, a CMS operationalises key data protection principles such as purpose limitation, data minimisation, and transparency. It functions as a digital gatekeeper, permitting data processing only when valid, purpose-specific consent is in place.
    • The Business Requirement Document (BRD) for Consent Management provides a granular breakdown of how these principles are translated into system features and workflows, defining the roles and responsibilities of each stakeholder—Data Principals, Data Fiduciaries, and Processors.
    • While it reflects a strong architectural foundation, a closer legal analysis reveals both areas of alignment and potential deviations from the requirements of the Digital Personal Data Protection (DPDP) Act, 2023. This blog adopts a narrative “Green Flag / Red Flag” approach to assess the BRD—highlighting elements that demonstrate compliance (green flags) and those that appear non-compliant, incomplete, or misaligned with the statutory mandate (red flags).

    Regulatory Green Flags: BRD’s Conformity with the DPDP Framework

      • One of the strongest features of the BRD is its proposed Consent Collection mechanism, which mandates granular, purpose-specific, and multilingual consent to be obtained through explicit affirmative actions, such as checkboxes or “I Agree” prompts. This approach closely aligns with Sections 5(3), 6(1), and 6(3) of the DPDP Act, which requires that consent be free, specific, informed, unconditional, and limited to the stated purpose, with clear support for local language notices and request for consent to ensure accessibility and comprehension.
      • The BRD’s approach to deploying a CMS that generates secure Consent Artifacts enriched with metadata—including timestamps, purpose identifiers, and language preferences—reflects a well-considered and compliance-oriented design. These artifacts act as verifiable records of consent, forming a critical foundation for regulatory auditability and demonstrable compliance under Section 6(10) of the DPDP Act.
      • Consent validation represents the second critical phase in the consent lifecycle, wherein the Data Fiduciary must confirm the existence of valid, active consent before initiating any personal data processing. This step is particularly vital for activities such as sending marketing communications or providing personalised services.

    In practice, the Data Fiduciary initiates a validation request via API to the Consent Management System (CMS). The CMS verifies the relevant Consent Artifact, checking for:

        • Purpose alignment,
        • Timestamp validity, and
        • Current consent status (e.g., active, expired, or withdrawn).

    Only if consent is deemed valid does the system permit the data processing to proceed; otherwise, the request is denied, and the user may be notified accordingly. Importantly, all validation requests and outcomes are immutably logged to ensure auditability and regulatory defensibility.

    The BRD’s emphasis on comprehensive audit logging of consent validations significantly strengthens the compliance posture under the DPDP Act, marking this feature as a clear “green flag” for implementation.

    • The BRD merits a green flag for incorporating a robust mechanism that enables Data Principals to modify previously granted consent in a granular, purpose-specific By allowing users to review and update their consents via a dedicated dashboard, supported by real-time synchronization and immutable audit logging, the framework aligns closely with Section 6(1) of the DPDP Act, which mandates that consent be informed, specific, and limited to stated purposes. Moreover, this feature complements the right to correction and updating of personal data under Section 12(1) of the Act, thereby reinforcing the broader principles of user autonomy, transparency, and ongoing control over personal data.
    • The BRD’s consent renewal feature—which proactively notifies Data Principals 30 days prior to consent expiry and facilitates seamless revalidation—demonstrates strong alignment with the accountability framework under Section 6(10) of the DPDP Act. This provision places the onus on the Data Fiduciary to demonstrate the continued validity of consent. By ensuring that data processing is contingent upon renewed, valid consent, the feature also supports Section 8(7) of the Act, which mandates timely erasure of personal data once the purpose is fulfilled or consent is withdrawn, unless legal retention is required. This built-in renewal mechanism not only reinforces user autonomy but also strengthens compliance with data minimization and purpose limitation principles central to the DPDP framework.
    • The BRD outlines a streamlined and user-centric consent withdrawal mechanism that allows Data Principals to revoke consent—either fully or partially—at any time. This system facilitates real-time updates across all relevant stakeholders and ensures that data processing is promptly halted in response. It is firmly aligned with Section 6(4) of the DPDP Act, which guarantees the right to withdraw consent at any stage, and Section 6(6), which places an obligation on both Data Fiduciaries and their processors to cease processing upon such withdrawal. Further, Section 8(7) reinforces this by mandating the erasure of personal data once the specified purpose has been fulfilled or consent has been withdrawn, unless a legal requirement necessitates retention. Collectively, these features underscore the BRD’s alignment with the DPDP Act’s core principles of user autonomy, purpose limitation, and data minimization.

    Regulatory Red Flags: Misalignments with the DPDP Act

      • Exclusion of Consent Managers: A Missed Opportunity for Decentralization and Trust

    Despite the BRD’s strengths, a significant compliance gap emerges in its complete omission of Consent Managers—a role expressly envisaged under Sections 6(7) to 6(9) of the DPDP Act. These intermediaries are intended to empower Data Principals by facilitating consent management in a neutral, platform-agnostic manner. The BRD neither integrates nor acknowledges this statutory function, undermining the Act’s core objectives of decentralization, user autonomy, and trust enhancement. This omission may also raise regulatory and operational concerns around excessive control being concentrated with Data Fiduciaries, counter to the DPDP framework’s structural checks and balances.

      • Absence of Redressal Mechanism in Notice: A Compliance Gap

    The BRD’s consent collection framework overlooks a key statutory requirement under Section 5 of the DPDP Act—informing Data Principals of their right to file a complaint with the Data Protection Board. While the notice stage appropriately covers the categories of personal data being processed, the purpose of processing, and the modalities through which individuals can exercise their data rights, it fails to include any reference to grievance redressal mechanisms. This omission dilutes the transparency and accountability objectives of the DPDP Act and may render the notice non-compliant with statutory mandates.

      • Inadequate Enforcement Mechanisms for Child Consent: A Regulatory Vulnerability

    While the BRD makes a cursory reference to verifying guardian identity—suggesting mechanisms such as DigiLocker—it falls short of establishing a structured, verifiable consent mechanism as required under Section 9(1) of the DPDP Act. Critically, the document does not propose any enforceable procedures to obtain affirmative parental consent prior to processing a child’s personal data. Moreover, it entirely omits safeguards against behavioural profiling or targeted advertising aimed at minors, thereby contravening the protective mandates of Section 9(3). This deficiency presents a significant compliance risk, especially for digital platforms operating in sectors such as education, entertainment, and gaming—domains with high child user engagement and elevated regulatory scrutiny.

      • Over-Reliance on Consent to the Exclusion of ‘Certain Legitimate Uses’: A Missed Opportunity for Lawful Flexibility

    The BRD disproportionately centers consent as the exclusive legal basis for processing personal data, overlooking the broader spectrum of lawful grounds explicitly recognized under Section 7 of the DPDP Act for non-consent- based processing. These include vital exceptions such as processing for compliance with legal obligations, emergency medical interventions, employment purposes or the performance of state functions. By failing to incorporate these alternate legal bases, the BRD risks fostering a compliance environment that is overly restrictive and operationally inefficient. Such a narrow approach could lead to gaps in implementation, missed opportunities for lawful processing, and unnecessary legal exposure for entities relying solely on user consent.

      • Gaps in Data Retention and Withdrawal Enforcement: Risks to Compliance and Minimization

    Although the BRD mandates that consent withdrawals take effect immediately, it overlooks the nuanced obligation under Section 6(6) of the DPDP Act, which requires Data Fiduciaries to cease—within a reasonable time—all processing activities by themselves and their Data Processors, unless such processing is legally authorized. While the BRD does acknowledge retention and erasure, it frames these as optional, configurable settings rather than mandatory defaults. This approach stands in contrast to Section 8(7) of the DPDP Act, which explicitly requires erasure of personal data once the purpose is fulfilled or consent is withdrawn—unless continued retention is legally justified. The absence of enforced default erasure policies heightens the risk of prolonged or unnecessary data retention, thereby undermining both compliance and the fundamental principle of data minimization.

    Our Take
    • For Data Fiduciaries, business leaders, and compliance officers alike, the implementation of a Consent Management System (CMS) should be viewed not merely as a statutory requirement under the DPDP Act but as a long-term strategic asset within the organization’s broader data governance framework. The introduction of the CMS under the DPDP regime represents a significant step forward in operationalizing consent-based data governance. By standardizing consent flows and introducing lifecycle-based controls, the government has sought to reduce compliance ambiguities and empower data principals with clearer rights and enhanced transparency. The Business Requirement Document (BRD) offers a foundational blueprint in this regard. However, its practical effectiveness hinges on rigorous execution. Organizations must integrate consent workflows into internal systems to facilitate real-time validation, maintain audit trails, and ensure continuity during system or API failures. Intuitive, user-facing dashboards should enable individuals to view, manage, and retrieve their consent history with ease, reinforcing trust.
    • Yet, as businesses align with this model, implementation gaps must be acknowledged—particularly the BRD’s assumptions around universal digital access and seamless API integration, which may not hold true for SMEs or digitally marginalized populations. Further, the BRD overlooks critical compliance components, such as verifiable consent mechanisms for children and persons with disabilities and fails to account for the statutory role of Consent Managers envisioned under Sections 6(7)–6(9).
    • Accordingly, organizations should not treat the BRD as a static checklist but rather as a dynamic, evolving framework that must adapt to legislative developments, demographic realities, and user-centric best practices. Proactive measures—such as embedding fallback mechanisms, conducting DPIAs (for Significant Data Fiduciaries), appointing DPOs or authorised personnel, and instituting regular audits—will be essential to building resilient, compliant, and future-ready data ecosystems.
    Links

    Business Requirement Document For Consent Management Under the DPDP Act, 2023https://d38ibwa0xdgwxx.cloudfront.net/whatsnew-docs/8d5409f5-d26c-4697-b10e-5f6fb2d583ef.pdf

    * The contents of this blog reflect the personal opinions of the author(s) and should not be construed as the views or any endorsement of any particular legal or policy position by the Firm.

    This article was originally published on Saikrishna & Associates