India’s Digital Personal Data Protection Act, 2023 (“DPDP Act”) is a critical step towards strengthening data privacy and governance in the country. For an overview of the DPDP Act and its draft rules, respectively, see our notes here and here. The Business Requirement Document (“BRD”) for consent management, released by the Ministry of Electronics and Information Technology (MeitY) on June 6, 2025 through the National e-Governance Division (NeGD), provides a technical blueprint for organizations to design and implement a consent management system (“CMS”) in compliance with the DPDP Act and its rules.

This note discusses the BRD with respect to the functional and operational aspects of consent management, the roles and responsibilities of various stakeholders, and the implications for organizations building or updating their CMS.

The Importance of Consent Management under the DPDP Act

The DPDP Act provides individuals (“Data Principals”) with rights and control over the use of their personal data. For a discussion on the scope and meaning of personal data under the DPDP Act, see our notes here and here. Subject to certain exceptions, personal data may only be collected, stored, shared, and/or otherwise processed by entities (“Data Fiduciaries”) pursuant to free, specific, informed, and unambiguous consent. For discussions on consent management under the DPDP Act, see our notes here and here.

Objectives of the BRD

The BRD seeks to provide a framework for organizations to design a CMS that enables comprehensive consent lifecycle management in a manner that aligns with the DPDP Act’s emphasis on data minimization, purpose limitation, transparency, and accountability. For a discussion on data minimization and purpose limitation under the DPDP Act, see our note here.

Consent Lifecycle Management: Key Processes

The BRD introduces a structured lifecycle for consent management. For each step of such lifecycle – i.e., collection, validation, update, renewal, and withdrawal – the BRD provides a framework to highlight the primary use, key actors involved, pre-conditions, triggers, functional requirements, and indicative workflow (including use cases), among other things.

Consent collection

The first step in such lifecycle is consent collection. According to the BRD, consent must be:

• Granular and Free: Users need to be provided with explicit options (e.g., through separate checkboxes or toggles) for consent for each distinct purpose of data processing (e.g., account creation, marketing, analytics, fraud detection, third-party sharing), which must be presented through an intuitive, user-friendly interface. The Data Principal must be able to accept or reject/withhold consent for each purpose through a separate prompt. The CMS should be configured to display clear and concise consent notices pursuant to the DPDP Act and be able to generate a tailored consent request for each specific purpose. Importantly, the BRD specifies that there should not be any bundling of consents: i.e., each purpose must be independently consented to. Optional purposes should be separated from mandatory ones.
• Explicit and Affirmative: Users must take a clear action to signify consent (e.g., checking a box, clicking on an “I Agree” or “Submit Consent” button). Pre-checked boxes are not permissible, and there should be no default opt-ins.
• Multilingual: Consent notices must be available on the relevant interface in English and other languages listed in the Eighth Schedule of the Indian Constitution to ensure inclusivity. For an overview of notice and consent requirements under India’s new data protection regime, see our note here.
• Accessible: Consent collection mechanisms must follow Web Content Accessibility Guidelines(WCAG) to ensure that they are usable by individuals with disabilities.
• Revocable: Consent must be revocable by the Data Principal at any time.
• Validated and Stored: Once a Data Principal has submitted their preferences, the CMS needs to validate the consent. The CMS should generate a “Consent Artifact”, which is a digitally signed, immutable, tamper-proof, machine-readable record containing purpose(s) of consent and relevant metadata (e.g., timestamp, user and session ID, consent method), which is then required to be securely stored in the consent database.
• Recorded and Acknowledged: After the consent has been stored and recorded, Data Principals need to be notified about successful consent submission via email, SMS, or in-app notification.
• Synchronized in Real-Time: Once the Consent Artifact has been stored, the consent status needs to be synchronized across internal systems and third-party processors in real-time. Data Fiduciaries must receive updates via Application Programming Interfaces (“APIs”) to validate consents before processing data.

Consent validation

Stored consents must be validated before any data processing can occur. When a Data Fiduciary seeks to initiate a data processing activity (e.g., service delivery, marketing email), it needs to send a request for confirmation of consent status to the CMS through a system event or an API call by specifying the user and/or session ID, along with the purpose for which such validation is required. To make such API requests/calls, Data Fiduciaries need to integrate their systems with the CMS API.

Pursuant to the Data Fiduciary’s request/call, the CMS will search its database for an active Consent Artifact corresponding to the specified user ID and purpose, and then validate the following criteria: (i) the consent is specific to the requested purpose; (ii) the consent is still active; and (iii) the consent has not been withdrawn. Importantly, the CMS needs to ensure that the processing request does not exceed the purpose specified in the consent. For example, personal data collected for identity verification cannot be used for marketing purposes unless it has been explicitly consented to.

Next, the CMS will send a real-time response to the Data Fiduciary validating (or rejecting) the latter’s request. If the consent is valid, the Data Fiduciary can proceed with its intended data processing activity. If the consent is found to be invalid, the CMS must return an error or deny the processing request, and the Data Principal needs to be notified accordingly.

Consent update

For changes in data use (e.g., new third-party sharing, revised data retention policy), a fresh consent must be obtained. The Data Principal must be notified about such proposed changes, which should not take effect without their active agreement. Such notification must clearly explain the new purpose or scope, how it affects data processing, and the need for an updated consent. The CMS needs to generate a new Consent Artifact with corresponding metadata, including updated purpose IDs. Updated consents must specify the duration for which they remain valid.

Consent renewal

For consents that are time-bound (e.g., for specific/temporary promotions or time-limited services), a consent renewal must occur with respect to (i) an expired consent, or (ii) an existing consent which is nearing expiry. For consents about to expire, the system should alert the Data Principal about consent renewal along with an explanation of changes. Similar to consent updates, the Data Fiduciary must validate the changes, and the CMS should update the Consent Artifact with new preferences.

Consent withdrawal

The DPDP Act provides Data Principals with the right to withdraw their previously provided consent. Accordingly, the BRD suggests that they must be able to do so through a user interface (e.g., dashboard, mobile app, or customer portal) for one or more specific purposes (without affecting other purposes) pursuant to a process as simple as the original consent-giving mechanism.

The CMS must provide the Data Principal with a summary of implications related to consent withdrawal (e.g., loss of specific services or features). If the Data Principal confirms their withdrawal via the interface, e.g., by clicking on ‘Withdraw Consent’, the CMS needs to validate such withdrawal request through an API and must thereafter update the consent record. The associated Consent Artifact should be marked ‘Withdrawn’ and logged in the audit trail with a timestamp.

Next, all linked Data Fiduciaries and third-party processors must be notified about the withdrawal request, where details of the affected purposes and associated user data should be included to ensure all related processing activities (including by downstream systems) are ceased immediately. As acknowledgement, the CMS must also notify the Data Principal through a confirmation message.

Special Provisions for Cookie Consent and Digital Tracking

The BRD provides separate requirements for cookie consent management, including to ensure that Data Principals are (i) informed about cookies and tracking technologies used on websites and applications, and (ii) provided the ability to grant, modify, or withdraw consent for such use. Consent must be specifically collected for each kind of cookie (e.g., essential, performance, marketing, analytics). Data Principals should be able to (i) accept or reject each category independently, and (ii) modify or revoke their consent in real-time through a dedicated cookie preferences interface.

When a Data Principal first visits a website or an app, a cookie notice banner needs to be displayed, along with a clear and accessible cookie policy outlining cookie usage, purposes, and data sharing practices. Data Principals must be notified of changes to such cookie policies and requested for renewed consent, when applicable. Cookie notices must be made available in multiple languages to support inclusivity, and expiration periods must be set for user preferences and cookies.

Only essential cookies may be active by default until explicit consents are obtained for other categories. The CMS needs to validate user preferences and activate cookies accordingly, and then log such preferences with a timestamp for auditing purposes. For organizations using web or app-based tracking, the BRD recommends a complete overhaul of cookie banners, tracking architecture, and logging infrastructure.

User Dashboard and Data Rights

According to the BRD, a core feature of a CMS should be a centralized user dashboard that allows Data Principals to (i) view the history of all consent-related actions, (ii) modify or revoke consent, and (iii) raise grievances or data requests.

Consent history and consent modification/revocation

The consent history should provide Data Principals with a detailed log of all consent-related activities, including cookies, by (a) listing consents, such that the complete history is grouped in separate categories based on consent status (active, expired, or withdrawn); (b) displaying metadata (e.g., timestamp, purpose, consent status); and (c) providing search and filter options for easier navigation. Data Principals should be allowed to modify preferences for specific purposes without affecting other consents, including for cookies.

Raising grievances or data requests

To enable Data Principals to raise grievances regarding consent violations and/or misuse of personal data, or to request access, correction, or erasure of data, pursuant to provisions of the DPDP Act, Data Principals should be provided with an easy-to-use form/interface on the dashboard to log such complaints/data requests. For an overview of grievance redressal under the DPDP Act, see our note here.

To ensure streamlined processing, options for data requests and complaints should include pre-defined items/categories (e.g., (i) Access Data, Correct Data, Erase Data, and (ii) consent violation, data breach, processing errors, respectively), followed by standardized workflows for each category. Users must be allowed to submit complaints, along with descriptions and supporting evidence (if applicable), in regional languages. Users must be automatically notified about status changes and resolution outcomes at each significant stage of processing. Unresolved complaints must be automatically escalated after a pre-defined timeframe pursuant to an escalation workflow (e.g., time-based escalation rules). The CMS should route the request/complaint to the appropriate team (e.g., Data Protection Officer or other designated department) for processing/resolution. All complaint submissions must be encrypted using a specific Transport Layer Security (TLS) protocol to provide secure transmission. Complaint details also need to be linked with consent records for context and CMS integration. The CMS should maintain detailed action logs during the resolution process.

Consent Notifications

In general, Data Principals, Data Fiduciaries, and Data Processors must be informed about consent-related activities via real-time updates delivered through multiple channels. For Data Principals, such multi-channel support should include email, SMS, or in-app messages, according to user communication preferences. The system must be configured to send notifications automatically based on user actions or events (e.g., consent expiry, withdrawal). Data Fiduciaries and Data Processors, too, need to be notified in real-time to ensure compliance, processing adjustments, and operational continuity. To automate workflows, secure API-based alerts must be dispatched with actionable details (e.g., ‘Stop processing data for User ID X’).

System Administration

System administration of the CMS includes user role-based access control to prevent unauthorized access. For the purpose of configuring data retention policies in compliance with the DPDP Act, different categories of personal data and consent records must be retained or deleted based on specific schedules. In this regard, data retention periods and Consent Artifacts must be pre-defined in such policy, and automatic purging of expired records through secure deletion protocols (e.g., cryptographic erasure) should be scheduled. However, exceptions for data retained under legal or regulatory requirements need to be configured such that the system identifies and handles such exemptions.

Logging and Immutable Audit Trails

The BRD emphasizes the importance of audit logs, such that all consent-related actions and activities are recorded in a tamper-proof manner for compliance verification, dispute resolution, and regulatory audits, as mandated by the DPDP Act. Such audit logs should be maintained in a structured format for easy retrieval and reporting. Immutable logs can help organizations demonstrate accountability and resolve disputes efficiently.

Conclusion

In the specific measures suggested by it (including as to technical measures required for synchronicity between Data Fiduciaries and Data Processors), the BRD is a helpful guide for organizations that have commenced or are shortly looking to commence preparing for compliance with the consent requirements under the DPDP Act. Instead of, or in addition to, building in-house CMS capabilities, organizations may need to partner with certified Consent Managers, integrate with licensed providers, use modular platforms, and/or seek specialized/expert guidance to meet the BRD’s specifications and to comply with further rules and/or guidance from the Data Protection Board of India (DPBI) in respect of consent management.

This insight has been authored by Rachael Israel and Dr. Deborshi Barat from S&R Associates. They can be reached at [email protected] and [email protected], respectively, for any questions. This insight is intended only as a general discussion of issues and is not intended for any solicitation of work. It should not be regarded as legal advice and no legal or business decision should be based on its content.