Corporate India, eagerly awaiting the final version of the Draft Digital Personal Data Protection Rules, 2025[1] (“Draft Rules”), under the Digital Personal Data Protection Act, 2023[2] (“DPDPA”), was recently jolted by a Business Requirements Document for Consent Management under the DPDPA (“BRD”)[3] discreetly issued by the National e-Governance Division of the Ministry of Electronics and Technology (“MeitY”).
A technical document intended to guide designers of consent management systems, the BRD extends past the DPDPA and Draft Rules to propose a rigid consent architecture which, much like the Reserve Bank of India’s (“RBI”) Account Aggregator framework,[4] is designed to record and manage consents for narrowly defined, pre-coded purposes.
Stakeholders are perceiving the BRD, although not legally binding, as a concrete signal of the government’s detailed, platform driven, and surprisingly prescriptive compliance trajectory.
The timing is notable, as stakeholders had, thus far, drawn comfort from the principle-driven nature of the Draft Rules and the open consultative process preceding them. They expected flexible implementation that would build on, rather than overhaul, existing data practices.
As discussed in our earlier analyses of the Draft Rules here and the DPDPA’s consent-related obligations here, the principles-based framework encouraged sectoral innovation and proportional compliance. By contrast, the BRD’s rigid, one-size-fits-all approach limits flexibility and leaves little room for a calibrated rollout, raising concerns around not just overreach, but also the timing, ambiguity, and feasibility of these requirements, especially for smaller businesses.
Consent under Pressure
A key learning from the General Data Protection Regulation (“GDPR”) is that consent, while conceptually empowering, is practically difficult to record and maintain – particularly given the breadth of purposes for which digital platforms collect, store, and process data.[5] Opaque or overly complex consent flows often cause digital friction, regulatory scrutiny, and even litigation[6], resulting in penalties, user attrition,[7] and fatigue across markets.[8]
The GDPR mitigates these practical difficulties by allowing alternative lawful bases, such as performance of a contract, legal obligation, and legitimate interests,[9] which enable personal data processing without relying solely on consent. Current estimates indicate that consent accounts for only a minority of data processing under the GDPR, with most relying on more stable legal bases.[10]
The DPDPA, however, does not afford this latitude. It treats consent as the default basis for processing, offering only narrow exceptions and omitting broader grounds like contractual necessity. As a result, businesses operating in India may need to rely on it for much of their processing, even where the GDPR would have permitted alternatives. This elevates the risk of consent fatigue, leading users to disregard or undervalue consent altogether.
Various drafts of the DPDPA and associated guidance had sought to mitigate challenges like operational complexity and consent fatigue. For instance, the Draft Rules introduced itemised consent, allowing organisations the flexibility to consolidate related purposes under a collective consent flow. Leaked versions of the draft rules also included template consent forms and supportive language that encouraged practical implementation. Stakeholders welcomed this balanced, digital services-attuned approach, as it enabled structured, streamlined consent, without overwhelming businesses or disrupting user experience. The BRD, however, appears to reverse course, in that it mandates highly granular, purpose-specific consent without clarifying how to group or classify overlapping or sequential purposes.
Unpacking the BRD
The BRD requires businesses to identify individual checkboxes or toggles for each processing purpose, prohibits the pre-population of consent fields, and mandates strict mapping between purposes and consent items. It also calls for a clear separation between optional and mandatory purposes. Most significantly, it directs explicit communication to the data principal regarding any consequences of consent withdrawal, including potential loss of services or features. While the BRD requires identification of affected services per purpose, it does not clarify how enterprises processing data for interdependent purposes – such as product and solutions improvement and targeting – should delineate which services are impacted when one or more relevant consents are withdrawn.
It also mandates cookie consent banners and stresses the need for a detailed cookie policy, adding another layer of regulatory and documentation complexity. These measures significantly expand the scope of what traditionally counted as consent compliance, particularly for multi-platform, multi-ecosystem businesses.
For consents configured to expire, the BRD introduces a renewal flow requiring systems to proactively notify users and enable consent refresh before expiration. Though limited to consents with predefined time limits, it adds compliance burden for managing long-term or dormant user relationships. The BRD also mandates re-consent and fresh notifications when processing purposes change or expand.
By requiring real-time validation, system-wide propagation of consent status, and immutable audit logs, the BRD introduces architectural dependencies that may require substantial backend engineering.
Collectively, these requirements constrain design flexibility, especially for structuring consent flows across user journeys and products. While the BRD ostensibly provides operational clarity, it does so at the cost of legal adaptability and system-level discretion.
Though the DPDPA assigns legal responsibility to the data fiduciary, the BRD introduces a distinct role for the “Consent Management System”, tasked with artifact generation, real-time API sync, and dashboard visibility. This raises practical concerns about who owns and operates these systems. In fact, such complex operational demands coupled with the lack of clear role attribution may lead stakeholders to deflect accountability, even as legal liability remains unchanged.
Compliance in Practice
Even under the GDPR, operationalising granular consent is challenging. In India, this is further compounded by linguistic diversity and varying levels of digital literacy, which complicate efforts to implement a nuanced, itemised, and revocable consent framework. Designing systems that track such consent and allow specific withdrawals at any point in the processing lifecycle risks becoming technically intensive and practically unmanageable. Moreover, the BRD’s uniform compliance design applied across all entities irrespective of their risk profile, departs from global best practices that encourage proportionate, context-based implementation, and contradicts the DPDPA’s vision of tiered obligations for significant data fiduciaries.
Perhaps more problematic than the substance of the BRD is how these expectations have been introduced, showing that the consultation process for the BRD fell well short of the engagement seen with the Draft Rules.
The DPDPA’s evolution has consistently involved public consultation, with stakeholders repeatedly calling for clearer guidance on consent recording, renewal, and operationalisation. Many had expected the Draft Rules to address these concerns with practical standards – like thresholds for granularity or audit obligations – emerging from this process. Instead, the abrupt release of a prescriptive, technically specific framework through the BRD, without any accompanying legal or public discourse, risks undermining the collaborative ethos that has defined the DPDPA’s development so far. It also raises concerns about the possibility of other onerous obligations being imposed with little or no warning.
Going forward, we hope MeitY will clarify the BRD’s legal status and work toward an implementation framework that allows businesses to architect consent systems that are compliant, fair, and proportionate to their operational needs, while remaining aligned with the core principles of the DPDPA.
For further information, please contact:
Arun Prabhu, Partner, Cyril Amarchand Mangaldas
arun.prabhu@cyrilshroff.com
[1] Draft Rules, available here.
[4] RBI, Master Direction – Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016, available here.
[5] Association for Computing Machinery (“ACM”), available here.
[6] Commission nationale de l’informatique et des libertés (“CNIL”), Deliberation of the restricted committee No. SAN-2021-023 of 31 December 2021 concerning GOOGLE LLC and GOOGLE IRELAND LIMITED, available here; and CNIL, available here.
[7] Information Economics and Policy, The Impact of Privacy Regulation on Web Traffic: Evidence from the GDPR, Introduction – Paragraph 6, available here.
[8] The Association for Computing Machinery (ACM) ACM, Special Interest Group on Security, Audit and Control (SIGSAC) Conference on Computer and Communications Security (CCS’19), (Un) Informed Consent: Studying GDPR Consent Notices in the Field, Paragraph 4.5, available here.
[9] European Data Protection Board (EDPB), Guidelines 05/2020 on Consent under Regulation 2016/679, Paragraph 2-3, sssssavailable here and GDPR, Article 6(1) (b)-(d), (f), available here.
[10] The International Association of Privacy Professionals, Inc. (“IAPP”), Top 10 Operational Responses to the GDPR: Part 2- Lawful Bases of Processing, available here.
