After months of waiting, the Ministry of Electronics and Information Technology (MeitY) leading the implementation of Digital Personal Data Protection Act (DPDPA)—has published the Business Requirements Document (BRD) for the Consent Management System (CMS). This document lays out everything needed to turn data protection rules from paper into real, working tools.
MeitY didn’t do this alone. The Digital India Programme, the National e-Governance Division (NeGD), and the Digital Office have all pitched in to build the technical framework. Together, they’re making sure businesses and government agencies can follow the DPDPA in a practical way. At the same time, the Digital Office is being set up to support the future Data Protection Board of India—providing the main operations for enforcing privacy rules across the country.
The Importance of the BRD Release
Releasing the Business Requirements Document (BRD) represents a major milestone. It establishes the foundation for the CMS—a system designed to collect, monitor, and enforce consent exactly as the DPDPA requires. As data privacy climbs higher on the agenda for both businesses and individuals, a reliable consent platform is essential. With this framework in place, organizations can manage personal data transparently, responsibly, and fully in compliance with the law.
Inside the Business Requirements Document
1. Purpose & Overview
This Business Requirements Document lays out our plan for building and rolling out a Consent Management System (CMS). Think of the CMS as a complete toolkit that handles every stage of managing consent—starting from collecting and verifying someone’s agreement, all the way through to updating, renewing, or withdrawing it. It’s main aim is to put individuals (Data Principals) providing them with greater control over their personal information or data, while also making sure meet all requirements of the Digital Personal Data Protection Act (DPDPA). With this system in place, organizations (Data Fiduciaries and Processors) can keep consents transparent and secure, and users can easily exercise their rights over their data.
Key Objectives
- Staying Fully Compliant: To meet the requirements of the Digital Personal Data Protection Act, CMS only collects data for specific purposes, keeps only what’s absolutely necessary, and stores everything in a secure way.
- Effortless Consent Management: The CMS takes care of every step in the consent journey—right from asking for and confirming someone’s permission, through any needed updates or renewals, all the way to letting them withdraw consent if they choose.
- Empowering Users with Control: We’ve built a straightforward dashboard where people can see exactly what data is collected about them and easily adjust their consent preferences whenever they want.
Stakeholders Defined
| Stakeholder | Definition | Responsibilities | Examples |
|---|---|---|---|
| Data Principal | Individual to whom the personal data relates | – Give, manage, and withdraw consent- Access and control personal data | A customer using a health app, an employee whose data is stored by HR, or a student on EdTech |
| Data Fiduciary | Entity that determines the purpose and means of processing personal data | – Collect valid consent- Ensure lawful processing- Provide user rights | Banks, hospitals, telecom companies, social media platforms like Facebook or Paytm |
| Data Processor | Third party processing data on behalf of a Data Fiduciary | – Process data as per instructions- Ensure data security and confidentiality | Cloud providers like AWS hosting user data for a bank; outsourcing firm handling payroll data |
| Data Protection Officer (DPO) | Compliance officer ensuring adherence to DPDPA regulations | – Monitor compliance- Address grievances- Liaise with Data Protection Board | A senior manager at a large tech firm designated as DPO to oversee privacy obligations |
Consent Management Lifecycle
Stage 1: Consent Collection
What Happens Here?
This is the first stage of the CMS lifecycle. Consent collection initiates when a Data Principal interacts with a service (e.g. registers on a website; registers on an app). The system concludes that personal data will follow.
Functionality Description:
- User-Friendly: Should be designed and developed in an easy to understand and navigate fashion (WCAG compliant) – so any user can understand how their data will be used.
- Purpose Specific and Granular Consent: Each purpose of processing data (marketing, analytics) must be presented purpose by purpose, not bundled or hidden check boxes.
- Explicit Action: The Data Principal must also provide explicit affirmative consent with action: click a button (I Agree) or check an unchecked box.
- Multi-Language: Consent notices are also provided in the english and Indian languages (Eighth Schedule).
- Metadata: Keying in metadata: user ids, timestamps, consent status, purpose ids.
Outcome: The end result is a Consent Artifact – a secure, verifiable consent record in the CMS database. This is the primary point of record for all activity to follow.
Stage 2: Consent Validation
What Happens Here?
Before any personal data is processed, the system carefully verifies that valid consent is available and still in effect. This step ensures that data is only used with proper authorization.
Functionality Description:
- When a Data Fiduciary wants to process data—such as sending marketing emails—they send a request to the Consent Management System (CMS) to verify consent.
- The system verifies whether consent exists for the specific user and purpose, and checks that the consent is still active, not expired or withdrawn.
- The system enforces that consent granted for one purpose cannot be used for a different purpose unless the individual explicitly approves it.
- The system securely records every consent validation in an immutable audit log, ensuring a reliable and transparent record.
- If the system confirms valid consent, it allows the processing to proceed. Otherwise, it denies the request and may notify the individual. This process enforces purpose limitation and data minimization.
Outcome: If consent is valid, processing continues. If not, the request is denied, and the user may be notified. This ensures purpose limitation and data minimization.
Stage 3: Consent Update
What Happens Here?
At this stage, people can change or add to their consent. For example, if the company wants to use their data for something new.
Functionality Description:
- The system lets the person know if there are any changes in how their data will be used or in the privacy rules.
- People can update consent only for the new or changed purposes without affecting the old ones they already agreed to.
- The process to update consent is simple and easy, just like when giving consent the first time.
- Every time consent is updated, the system records who made the change. When it happened, and what the new choices are.
- The system creates a new consent record and immediately updates all connected systems. The teams responsible for data processing are also notified of these changes.
Outcome: The system generates a new Consent Artifact that reflects the updated preferences and synchronizes all relevant systems in real time. It also notifies stakeholders, including Fiduciaries and Processors, promptly.
Stage 4: Consent Renewal
What Happens Here?
Consents often come with expiration dates. The system should have some way to remind the user to renew a consent when it is near its expiration date.
Functionality Description:
- The system will automatically notify the user of consent expired or will expire on a particular expiration date, such as 30 days prior to the consent’s expiration date.
- Renewing the consent should be easy and similar to the consent that was provided, that is, there are clear steps to follow and at the end, the user will provide confirmation.
- Each renewal will be recorded with important information, such as date and time of renewal, purpose ID, and new consent status.
- After the consent has been renewed, the consent will continue to be valid. That allows to ensure the data is accurate and the processing legally compliant.
Outcome: Consent continues to remain valid with full user awareness. This reinforces data freshness and legal validity of processing.
Stage 5: Consent Withdrawal
What Happens Here?
Data Principals can withdraw consent at any time and the system must ensure that all related processing ceases immediately.
Functionality Description:
- Self-Service Interface: Users will log into a dashboard and withdraw their consent/s for identified purposes.
- Immediate Action: The system records the consent as “Withdrawn” and informs any linked websites that processing should stop.
- Confirmation & Transparency: Users will receive notifications that the consent has been withdrawn and notified what that means for them.
- Exception Handling: There are scenarios (e.g., legal obligations) where processing may continue even after withdrawal, as provided for in law.
Outcome: Data processing halts for the withdrawn purpose, and this action is logged immutably for audit and compliance. This upholds the DPDP principle of revocability.
What’s Next? The Path to Data Privacy Compliance in India
The release of the Business Requirements Document (BRD) means that it is now time to build and implement the actual platform. This technical infrastructure will help organizations across all industries adopt privacy-by-design in a meaningful way. It will also support them in responsibly meeting their data rights obligations to individuals, both in principle and in practice.
As the country moves closer to implementing the DPDPA in India, this is significant. The CMS enables organizations to comply with the law and allows citizens to see how their data is handled. This is an important step in the journey toward privacy security and trust.
Keep a look out as we share more information on how this system operates and what the Data Protection Board will do. We will also provide guidance on how organizations can prepare for this change.
