In the lead up to the anticipated enforcement of the Digital Personal Data Protection Act, 2023 (“DPDP Act”), India’s Ministry of Electronics and Information Technology (“MeitY”) has released a ‘Business Requirement Document for Consent Management under the DPDP Act, 2023’ (“BRD”).  The BRD has been issued as part of the MeitY’s ‘Code for Consent:  The DPDP Innovation Challenge’, as part of which, Indian tech organisations are invited to develop modular consent management systems (“CMS”) that can be integrated / embedded into existing platforms and software applications that are currently utilised by data fiduciaries.  The BRD (while non-binding and not a part of the DPDP Act) is intended to act as a guideline for the development and implementation of a CMS.

To refresh – the DPDP Act has introduced the concept of ‘Consent Managers’, being entities that will be registered with the proposed Data Protection Board of India and act as a single point of contact to enable individuals to grant, manage, review, update or withdraw their consent on a case to case basis, through an ‘accessible, transparent and interoperable platform’.  The draft Digital Personal Data Protection Rules, 2025 (“Draft DPDP Rules”), which are subject to finalisation, prescribe the registration criteria, technical and organisational requirements, and ongoing compliance obligations in respect of consent managers, including access requirements and audit mechanisms.

The BRD seeks to define the functionalities of a CMS and its objectives which are: (i) enabling comprehensive consent lifecycle management; (ii) empowering data principals to exercise rights over their data; and (iii) ensuring compliance with the DPDP Act and Draft DPDP Rules.  The BRD also seeks to identify the key stakeholders involved in the CMS and define their roles in the CMS.

Functional Requirements of the CMS:

Functional requirements prescribed by the BRD encompass:

• The consent management lifecycle which is designed to ensure that consents provided are explicit, granular and purpose specific and revocable at any time.  The lifecycle has been dealt with in further detail below;
• Cookie consent management which provides control to the data principals and allows them to make real time updates as regards consents;
• A user dashboard which allows users to view a detailed log of all (active, expired and withdrawn) consent related activity; and also allows users to modify and revoke consents or raise and track grievances;
• Consent notifications to keep all relevant stakeholders (data principals, data fiduciaries and data processors) promptly informed of consent related activities;
• A grievance redressal mechanism for complaints to be raised by data principals with real time status tracking and escalation options;
• System administration in order to define and manage access controls within the CMS and put in place data retention policies; and
• Comprehensive logging which is tamper proof to ensure adherence to regulatory requirements with specified metadata being captured for each log entry.

Consent Management Lifecycle:

The consent management lifecycle as per the framework set out in the BRD is divided into five main categories, namely, collection, validation, updating, renewal and withdrawal, each of which have been summarised below:

Collection:

• Upon the data principal initiating a service request by interacting with a data fiduciary’s platform, actions requiring consent are identified by the data fiduciary’s platform and the CMS is notified, pursuant to which a tailored consent request is generated by the CMS.  These consent requests will need to be purpose-specific (bundled consent will not be allowed), granular (allowing data principals to provide consent for each request separately) and provided in English as well as languages listed in the Eighth Schedule of the Constitution of India.
• The data principal may confirm their consent by providing explicit consent (such as clicking on an “I Agree” or similar option) and the CMS will thereafter validate that the consent is in compliance with the requirements of the DPDP Act, including it being limited to the stated purposes.
• The CMS will then create a tamper-proof ‘Consent Artifact’ (containing the metadata of the consent, i.e., the timestamp, user ID, purpose ID, session ID and consent method), which will synchronise across systems in real time and be stored within CMS’ consent database.
• The data principal will be notified of the successful submission of consent by the CMS for processing of their personal data for the specified purposes.

Validation:

• Upon the data fiduciary initiating an activity that requires user consent, the data fiduciary system will query the CMS to verify whether relevant consent has been duly provided by the data principal and the status of such consent.  The CMS will run a search of its database and on the basis of the consent artifact that has previously been generated, validate that the relevant consent exists for the specific user and specific purpose and that the consent has not expired or been withdrawn.  The data fiduciary may proceed with the processing activity if a valid consent exists (with the processing request being denied and the data principal being notified by the CMS if valid consent does not exist).

Update:

• Where a data principal seeks to voluntarily update a previously granted consent or where a data fiduciary introduces new processing purposes or modifies any existing purpose which requires consent of the data principal (and will require that the data principal login in to the CMS platform), the CMS dashboard will display to the data principal, details of all active consents and will allow the data principal to make granular updates to their consents.  The consent artifact will be updated by the CMS and both the data principal and relevant data fiduciaries will be notified of the updated consent status in real time, ensuring that no processing occurs without updated consent.

Renewal:

• Where a previously provided consent is set to expire, the CMS system will notify the data principal.  The data principal may then login to the CMS system to renew the consent, which will follow the same process as set out above in the case of updates.

Withdrawal:

• The data principal may use the CMS dashboard to withdraw consent they have provided previously.  The CMS will display all active consents and provide the data principal with a summary of the implications of withdrawing consent.  Where the data principal opts to proceed with withdrawing their consent (by clicking a button stating – “Withdraw Consent” or similar), the CMS will update the consent artifact and notify the data principal and the relevant data fiduciaries in real time so that data fiduciaries immediately halt all processing activities related to the withdrawn consent.

In each of the above instances, the CMS will maintain a record and log all actions and updates that have taken place so as to have a verifiable audit log in place.

The BRD provides a valuable lens through which to understand the Indian Government’s approach to the dynamics and operationalisation of the consent manager concept proposed under the DPDP Act – particularly in terms of process and distribution of responsibilities between the various stakeholders through detailed workflows.  Although not binding, the comprehensive description of the various stages of the consent management lifecycle and interactions required at each stage, will serve to provide a path forward to organisations who are in the process of aligning their systems and processes in order to comply with the DPDP Act.  However, while the envisioned lifecycle management system appears to greatly reduce the compliance obligations of data fiduciaries (in cases where a consent manager is involved), it is to be noted that the DPDP Act in some instances imposes compliance obligations specifically on data fiduciaries and in others, on either data fiduciaries or consent managers, depending on the context.  For example, Section 5 of the DPDP Act places the obligation to provide a compliant notice to a data principal on the data fiduciary (whereas the workflow provided in the BRD requires the consent manager to generate a tailored consent request to be provided to the data principal) and Section 13 of the DPDP Act requires that a means of grievance redressal be provided by a data fiduciary or a consent manager.  While the consent manager may facilitate and handle most of the technical aspects of the consent management lifecycle, it is unclear whether ultimate legal responsibility (for example, to ensure that consent is validly collected, informed and appropriately actioned) will continue to rest with the data fiduciary.

The allocation of responsibility and liability between the various stakeholders will therefore remain at open question for the moment.  The effectiveness of the CMS and the apportionment of accountability (absent regulatory guidance or clarification) may only become clearer as these frameworks are implemented and tested in operational and regulatory contexts.