While every body is waiting for the notification of the DPDPA 2023, the Government has released a document titled “Business Requirement Document for Consent Management under DPDPA 2023” under the banner of NeGD.
It appears that this is an advisory issued by the MeitY to the industry on how they can approach the Consent Management for compliance of DPDPA 2023. It is not clear why the Government is coming up with such an advisory].. [Ed:.refer PS below]
The document outlines the objectives and functionalities of a platform designed to align with DPDPA 2023. Perhaps the Ministry wants to host the platform itself to be of assistance to not only the data fiduciaries in the Government sector but also to the private sector. Perhaps this is an attempt by the Government to become a software solutions provider.
If the Government comes up with its own platform, other private sector solutions providers will face a significant competition in terms of pricing and perceived “Deemed Compliance benefit” if they host their consent management system on this platform.
It is also not clear if this platform can be adopted by “Consent Managers” who accredit themselves with the DPB. If so, the Consent Managers may provide the platform as a service and either let the users manage the data by themselves or provide the service as a complete service along with data management by itself.
Now that Government has owned a document of this nature, the architecture provided here becomes a Government’s own suggestion and any body who is using the platform as suggested will be “Deemed” to be in compliance of DPDPA 2023. It is difficult to argue that MeitY is different and NeGD is different and hence this is CMS system cannot be considered as a “Deemed” compliance. Only time will tell if Courts accept such artificial division.
Through this document, the Government is itself owning the responsibility to drive the community towards compliance. In case there is any deficiency in compliance arising from an improper implementation of the Business Requirement Document (BRD), the data fiduciaries will argue that this is the approved process by the Government. Whether this was desirable or not is a matter for discussion at some point of time in the future.
It is expected that this platform would be considered as a standard platform for Consent Manager accreditation and all those who are likely to take up the responsibility as a Consent Manager will adopt it for easy clearance of their application with DPB. CERT-IN itself would be the auditor for the platform as presented and other auditors need only to make some peripheral checks.
The BRD defines the functional requirements of a platform for managing the “Consent” for Personal Data under DPDPA 2023. It includes a detailed breakdown of core modules such as Consent Lifecycle Management, User Dashboard, Notifications and Grievance Redressal Mechanisms. Additionally, the document outlines administrative capabilities, including user role management and data retention policy configuration, to ensure operational efficiency and compliance.
Three objectives have been defined for the CMS namely
- Enable Comprehensive Consent Lifecycle Management
- Empower Data Principals
- Ensure Compliance with DPDP Act and Rules
The document recognizes three stakeholders namely the Data Principal, Data Fiduciary and the Data Processor. Surprisingly the document states that the fourth stake holder is the DPO who acts as the primary compliance authority to oversee the adherence to the DPDPA 2023.
Judging the words used in the DPDPA draft Rules of January 2025, there was a doubt whether the DPO’s role would be limited to “Answering questions from the Data Principals”. This document clarifies that DPO is responsible to oversee the Compliance in an organization.
Six functional requirements have been identified namely,
1.Consent Collection
2.Storing Consent
3.Managing Consent
4.Consent Validation
5. Consent Renewal and
6. Audit Logs
The DGPSI system with its “Process based approach” is well suited for the requirements listed in the para 4.1.1. on consent collection. The suggestion specifically mentions that there should e no “Bundled Consent” and consent request has to be triggered when the service request is initiated. (Not earlier). It also specifies that “Consent Notice” specific to the purpose shall be displayed. The need to have multiple notices has been a bone of contention with organizations who are today accustomed to one comprehensive Privacy declaration for all present and future purposes anticipated.
The BRD ignores the need for Digital signature for the consent to be treated as an enforceable agreement. The BRD seems to be validating the “Click Agreement” which is ulra-vires the ITA 2000.
The document also seems to have ignored the parental consent requirement in case of minors or request for nomination.
The use cases referred to has not considered the “Consent Manager” as a stake holder and there would be a use case where consent is provided to the Data Fiduciary not by the Data Principal but by the Consent Manager though the request is triggered by the Data Principal.
The Consent Validation system as suggested is interesting as it prescribes a validation every time a certain data set is processed. When the same data is processed over a period multiple times, it means that validation is required repeatedly. This would introduce some complications.
The Consent update system needs to take note of disagreement if any between the Data Fiduciary and the Data Principal regarding the update.
Consent Expiry and Consent Withdrawal needs to take into account the validation and archival if required.
There is a special mention of the Cookie Consent which has not recognized the possibility that cookie information may actually be not an “Identifiable Personal Data” or “Personal Data to which DPDPA is applicable”.
A Consent notification and user notification module has been indicated which may require some elaboration.
A mention has been made on the Grievance Redressal Mechanism which is a system outside the core Consent collection, storage and retrieval system.
A mention has also been made about the Data Retention system which also is an additional sub system to be managed.
Overall, the document is a good starting point for the technical developers who were completely clueless on how to proceed. But there will be requirement of many improvements which needs to be configured.
It is interesting to observe the reaction of the community to this document and whether this will be considered as a template for architecting the consent management system.
Naavi
P.S: This is to clarify that the above document is being released as part of the initiative of NeGD to develop an open source platform for Consent Management. NeGD is in the process of organizing a “Coding Challenge” to develop the architecture and an operative platform code that can be shared on open source basis with MSMEs. Consequently the above post may kindly be read in this context. The document is not as an “Advisory” but a working document for the coding challenge. We regret the mis-understanding.
Also refer MeitY Startup hub for more details
7th June 2025
