There is a lot of buzz around a Business Requirements Document (BRD) that was published by NeGD (National e-Governance Division) and MeitY as a guide to build Consent Management Systems. This was released as part of the DPDP Innovations Challenge on 15 April 2025 – You can find the full details here. The idea being, the final version selected through the competition will be released as public good (open-sourced) for people to pick up and work on further.
Here’s the disclaimer from MEITY: “By participating in this coding challenge, contributors agree to grant MeitY a nonexclusive, royalty-free license to use, publish, and distribute their submitted code as open-source under a suitable license and General Licensing Arrangement. Selected submissions will be hosted on a public repository for free community use and further development. Contributors retain the right to continue working on their code and confirm that their submissions are original and do not infringe on any third-party rights”.
Some say this is meant for “Consent Managers” – a different concept altogether in the DPDPA – interpreted based on the inconsistent wordings within the document perhaps. Our take is that this is meant to act as a guide for developers building the consent management layer within the ambit of the larger DPDPA landscape. Even better for those who already have a consent management system to see if they are able to cover most, if not all, if the functional requirements. However, this definitely is not a holy grail of a CMS (as it’s missing several crucial features) or an extension to the DPD Act or DPDP Rules.
So, let’s dive in.
There are broadly three aspects to Data Privacy compliance – a data discovery module (know your systems and the policies and purposes that govern the data you collect, process, store, and share), a consent registry module (the entire consent lifecycle from collection through to expiry), and a data residency module (ensure data resides safely and is handled securely). While the BRD covers the mid-segment of the DPDPA like consent lifecycle, grievance redressal, logging processing activities, and so on, it doesn’t cover aspects such as gap assessment, data discovery, system lifecycle, data mapping, vendor risk management, breach notification, periodic impact assessment, right to nominate, age verification, and so on – so it’s a bit narrow in its scope.
Let’s look at a short summary here.
Consent Management Lifecycle – This is pretty clear in the DPDP Act and the DPDP Rules, which have detailed notes on providing clear, multilingual, independently understood (no links or consent groupings) consent with itemised description, purpose, and user rights over modifications, withdrawal, and revocation. So, the BRD just elaborates on it with a ton of assumptions that most Fiduciaries will find perplexing. We recommend using the DPDP Act and the Rules as a foundation rather than the BRD.
Cookie Consent – While the DPDP Act does not explicitly talk about cookies, it is wise to consider them as a source of PII data collection on websites and hence provide a cookie banner with the option to accept or deny such cookies. We recommend having a simple cookie banner to start with, along with their purpose and retention period, to build trust. Multi-language support would be overkill for cookie banners, but it’s a choice for individual Fiduciaries.
User Dashboard – A lot of attention has been given to having a self-service portal for consent management. This would surely make most Bankers run like their heads were on fire. The path I see is that most regulated entities would at least like to provide this behind a security wall such as online banking or a mobile banking app under a Privacy Centre function (with all of the internal plumbing within the DMZ). This would avoid phishing links and other threats that could allow bad actors to exploit innocent customers in the name of consent updation (much like how KYC updation was hijacked by fraudsters). A self-service portal is not mandated in the DPDP Act, so DFs can use this at their discretion.
Consent Notifications – These are general transaction notifications as one navigates the consent lifecycle (as and when the consent record is changed). The BRD talks about notifications such as consent expiry in Section 4.1.4, which states: “For consents with predefined expiration dates, provide renewal options prior to expiration; Notify the user 30 days before consent expiry and provide a seamless renewal process.” The whole idea of consent and data minimisation and purpose limitation is to ensure that the data is used only up to the necessary period and erased thereafter. So not quite sure intimating to renew consent is a good idea. And would citizens even care?
Grievance Redressal – The BRD covers a detailed workflow of a typical grievance workflow of initiation, recording, assignment, escalation, etc., so it is a good starting point for anyone trying to develop this module into their CMS. There is a mention of pre-defined workflows that cater to different complaint categories, but to start with, we recommend having a really simple way for users to raise a complaint – email, portal or app. The same is recorded and a Case ID is assigned for tracking purposes. The case is then assigned automatically to the right stakeholder group to investigate and respond. Once the case is resolved, it should be closed. And the system should maintain all of the audit logs. Notifications can be sent to the users once the case is created and once the case is closed (or intermediate ones if there is more information needed from the requestor). There should certainly be an option to escalate if the grievance is not resolved within a certain time period or if the resolution is not satisfactory to the data principal.
System Administration – These are the standard bells and whistles any good system worth their salt should have by default. These things cover details such as user management, role management, audit logs, and so on. One important function mentioned under System Administration is the
Data Retention Policy. We strongly recommended that this is taken up alongside system, policies, and purposes – way up the development chain, as it is a crucial function to be tackled by the business and not by the administrators.
If you are looking for an end to end DPDPA solution – not just bits and pieces – then look no further than ATLAS DPDP solution that covers the entire gamut of DPDPA compliance covering Assessments, Data Discovery, Data Classification, Consent Lifecycle, Processing Activities, Requests and Grievances, Breach Management, Admin Functions and many more. You can get an overview here and book a demo here.
