Architecting Digital Trust: The Role of The BRD in Consent Management Under The DPDP Act, 2023
by Samyak Surana (Principal Associate) and Devanshi Rathod (Associate at ANM Global)
In an era where a single click on “Accept” can open the floodgates to unchecked data sharing, India’s Digital Personal Data Protection Act, 20231 marks a turning point by making consent central to lawful data processing. To operationalise this, the Ministry of Electronics and Information Technology (MeitY), on 6th June, 2025, issued the Business Requirement Document (“BRD”)2 for Consent Management Systems (“CMS”). The said guidelines aim to aid in the creation of compliant, intuitive, and trustworthy CMS for easy user access and robust data protection. This article presents how the document aims to make legal workflows and interface design actionable and explores the consent lifecycle (collection, validation, updating, renewal, and withdrawal). In doing so, this article will explore platform evolution, Consent Managers’ roles, Data Principals’ rights, Data Fiduciaries’ responsibilities, while highlighting the importance of privacy in the digital economy.
INTRODUCTION:
Imagine handing over your unlocked smartphone to a stranger, trusting them not to misuse it and without knowing what apps they will open, what messages they will read, or what photos they might copy. Yet in the digital world, this is effectively what millions of Indians do each day when they provide their ‘consent’ on vague privacy notices and cookie banners. Without realizing it, users give organizations sweeping access to their locations, contacts, transaction histories, photos and even biometric data, without knowing how it will be used, for how long, or by whom. This is precisely why a well-built, transparent and user centric consent management system is a digital necessity. One that empowers individuals to understand and control how their data is accessed and used.
The BRD outlines the guiding principles for Consent Management Systems under the Digital Personal Data Protection Act, 2023 (the “DPDP Act”). It is not a general discussion on privacy rights, but a technical and operational framework intended to guide organizations in building systems that collect, validate, track, and withdraw user consent in compliance with the DPDP Act. While the legal obligations under the DPDP Act are clearly laid out, the BRD seeks to translates those requirements into a practical and implementable framework that digital platforms can adopt to ensure compliance and enhance user trust.
The Context Behind Consent: A Quick Overview of the DPDP Act
Passed in 2023, India’s DPDP Act establishes a long-awaited regulatory framework for personal data protection. While aligning with international norms like the General Data Protection Regulation (GDPR)3, it is grounded in India’s constitutional principles wherein the right to privacy has been recognized as a fundamental right. The DPDP Act introduces certain key terms such as “Data Principals”4 (the users to whom the personal data relates), “Data Fiduciaries5” (determines the purpose and means of processing of personal data), and “Consent Managers6” (registered independent entities that allow users to manage consent across platforms).
Section 6(1)7 of the DPDP Act lays down that a consent must be free, voluntary, informed, specific, and unambiguous. It prohibits pre-ticked boxes or bundled consent practices that force users to accept either everything or nothing. The DPDP Act also introduces Consent Managers under Section 2(g)6, who act as facilitators to ensure individuals can manage, review, and revoke consent in a transparent and hassle-free manner. The BRD reflects such core principles in structured and a systematic approach.
Need Of the BRD:
To understand the BRD in a daily life scenario, let us imagine a fictional fintech app which can be referred to as “SmartApp”, used as an illustrative example throughout the article to understand how the concepts play out in the practical scenario. Today, SmartApp may bundle consent for marketing, third-party data sharing, and location tracking into one checkbox during sign-up. The user, in a hurry to make a payment, clicks “Accept All” without reading further. Under the DPDP Act, this blanket form of consent is unlawful. Moreover, if SmartApp continues using data after a user revokes permission, the company risks penalties as stipulated under the DPDP Act.
Thus, the BRD is introduced to help Data Fiduciaries like SmartApp avoid such violations by establishing granular consent workflows that clearly separate each data processing purpose. It provides not just a compliance roadmap but also helps build user trust through clarity and control.
The Shift in Power to Data Principals
With the DPDP Act in place and the introduction of the BRD, Data Principals are empowered to say, “I’ll share my location for payments but not for ads,” and Data Fiduciaries must adhere to the same. They now have the right to give, modify, or withdraw consent at any time, and this consent must be recorded with time stamps and traceability. This is where Consent Managers and a strong CMS come in, to make consent dynamic, not static.
The BRD anticipates that organizations will need to build an Application Programming Interface (API) or integrate with registered Consent Managers to track real-time updates in user preferences. SmartApp, for example, can no longer claim that it “did not receive” the revocation request. That defense can no longer be used, the system must honour updated consents automatically, backed by robust audit logs.
CORE COMPONENTS OF THE BRD:
The BRD’s scope defines the range of entities and use-cases it applies to, Consent Managers, Data Fiduciaries, and Data Principals. It also touches on what is outside the document’s purview, making clear that the BRD only addresses the consent management part of the data governance lifecycle. A company like SmartApp falls squarely within this scope, needing to revamp both its back-end systems and user-facing flows.
Here, the BRD identifies four primary actors: Data Principal, Data Fiduciary, Consent Manager, and Consent Management Platform, whose roles and responsibilities are defined in alignment with the DPDP Act. To understand these roles in a real-life context, consider Aman, a user of SmartApp, is a Data Principal in this scenario who is required to provide his consent, before SmartApp acting as the Data Fiduciary, can access or process his personal data. Further, the system he uses to manage these data consents is the CMS.
Consent Lifecycle Management: A Key Process
The BRD describes ‘consent’ as a multi-stage lifecycle comprising of request, capture, validation, update, renewal, and revocation. Each phase must be securely tracked and auditable implying that consent is not a one-time formality but a dynamic and ongoing right. If Aman revokes his consent to share geolocation data with SmartApp, the system must halt processing that immediately and log that change.
- Consent Request and Capture – Consent collection is the first and foundational step. The BRD emphasizes that consent must be granular and unbundled, users must have the ability to choose separately for each data processing purpose, such as identity verification, marketing, fraud detection, or data sharing. These choices must be presented clearly and in an accessible format. For instance, while using SmartApp, Aman must be able to consent to receiving account alerts without being forced to accept promotional emails. Moreover, consent must be explicit and require affirmative action. Passive mechanisms like pre-ticked boxes or default settings are invalid. Notices must be multilingual and accessible to people with disabilities, aligning with Web Content Accessibility Guidelines (WCAG)8. Once Aman makes his selections, SmartApp’s CMS generates a secure Consent Artifact, which is a digitally generated record that captures all the key details of Aman’s consent, including what he consented to, when was such a consent given, and for what purpose. This Consent Artifact serves as verifiable proof that valid and informed consent was provided and is then stored and synchronized in real-time across the internal systems and with third-party processors.
- Consent Verification – Before any personal data is processed, the CMS must validate that valid, active consent exists for the exact purpose. When SmartApp wants to send Aman a marketing message or use his data for a new feature, it must first verify consent via an automated API call to the CMS. The system checks whether the Consent Artifact exists, is unexpired, and specifically covers the requested use. If Aman had only consented to use his data for payments but not for targeted offers, SmartApp cannot proceed with the new activity. If consent is confirmed, processing moves forward. If not, the system rejects the request and notifies the relevant teams, and in some cases, Aman himself. This ensures that data use never exceeds what was originally agreed upon.
- Consent Update – As services evolve, the nature or purpose of data processing may evolve parallelly. Whenever there’s a shift in how data will be used, for instance, SmartApp starting to collaborate with a new loan aggregator, fresh consent must be obtained. The BRD mandates that users be clearly notified of any such change, with full transparency about the new use and its implications. For Aman, this means he must be asked again through a direct, intelligible notification, if he consents to his financial data being used for eligibility checks by the new partner. This update must not be presumed or backdated and must reflect the revised terms.
- Consent Renewal – Consent is not always indefinite. For consents tied to a specific time frame, like limited offers or trials, renewal becomes necessary. If Aman had agreed to share data for a three-month cashback program, SmartApp must remind him before the end of that period to renew his consent. The renewal prompt must clearly outline any changes since the original agreement and offer an easy way for Aman to continue or exit. If he agrees, the CMS logs this renewal by updating the Consent Artifact and extending its validity. If he does not respond or declines, the consent lapses, and all related processing must cease.
- Consent Withdrawal – One of the most significant features under the DPDP Act is the ability for users to withdraw consent at any time. As per Section 12(3)9 of the DPDP Act, the Data Fiduciary is required to erase personal data upon withdrawal of consent unless retention is legally necessary. In alignment, the BRD mandates that all processing activities related to the withdrawn consent must be halted, including any data sharing, analysis, or use of the associated data, with prompt updates across internal systems and third-party processors. The BRD stresses that this process must be user-friendly and easy to access, via an app dashboard, settings panel, or other intuitive interface. While using SmartApp, Aman must be able to see all the purposes for which he has given consent and selectively withdraw any of them without losing access to unrelated services. Suppose, Aman decides to opt out of promotional messages while still using SmartApp for bill payments, he should be able to make this change in just a few clicks. The CMS must validate his request, update the Consent Artifact to show its withdrawn status, and log the time and method of withdrawal. Critically, SmartApp must also notify all internal systems and third-party processors about the change to ensure data processing linked to that specific consent stops immediately.
Cookie Consent Management
As per the provisions captured under the DPDP Act, cookie banners and consent mechanisms for web tracking must be reimagined. Generic “Accept All Cookies” banners are no longer sufficient. The BRD mandates that consent obtained for cookie-based data collection must be as granular and purpose-specific as any other data processing activity. For example, when Aman visits SmartApp, he should be presented with a clearly structured interface that allows him to select which types of cookies he consents to. Each category must be explained in plain language, and Aman must be able to choose or reject each one independently. Moreover, the default state must be unselected unless the cookie is essential to delivering the service. These preferences must then be stored in a Consent Artifact and respected throughout his interaction with the platform. Importantly, Aman should be able to modify these preferences anytime via his SmartApp account dashboard or browser settings.
User Dashboard
A central aspect of user empowerment in the BRD is the provision of an accessible and informative “User Dashboard”. This dashboard functions as a single, unified platform, a one-stop location where a Data Principal can track, review and manage all the consents it has provided across various digital services. For Aman, the dashboard within SmartApp becomes the single source to understand what personal data he has shared, for which purposes, with whom and for how long.
The intention of a “User Dashboard” is to simplify the Data Principal’s experience by removing the need to search through scattered settings, policies or emails to know what they have consented to. Consent statuses must be presented in a readable, non-technical format. The dashboard should allow the Data Principals to easily update or withdraw consent for specific purposes easily, view timestamps of when a particular consent was given, and access contextual information such as detailed notices or potential consequences of changing their preferences. From a system design perspective, this interface must be dynamic, updated in real-time, and linked directly with the CMS to ensure any change made by the Data Principal is immediately reflected across all backend systems.
While the “User Dashboard” is intended to empower Data Principals, it remains unclear to what extent the Data Principal alone enjoys secure autonomy over the same without influence and interference (which is not consented to) from either the Data Fiduciary providing the “User Dashboard” or any third party, including the Data Processor. It further begs the question over who retains ultimate control over the full functionality of the “User Dashboard”. In the absence of explicit guidance, the authority to modify or configure the dashboard and its contents remains ambiguous. This raises important concerns about the extent of true user autonomy.
Grievance Redressal
Beyond consent mechanisms, the BRD highlights the importance of having a structured grievance redressal framework. Users must have access to an effective and responsive mechanism for raising concerns related to misuse of their personal data, unauthorized processing, or consent-related issues. SmartApp, acting as a Data Fiduciary, must designate a Grievance Officer whose contact details are made available through the dashboard or privacy policy. When Aman raises a concern, say, he finds out his data was shared despite withdrawal of consent, the Grievance Officer must acknowledge his complaint promptly and resolve it within the statutory timeline. The CMS should enable seamless complaint logging, generate tracking numbers, and maintain a communication record to demonstrate timely and lawful redressal.
System Logs and Audit
The system must maintain detailed logs of every consent-related action, creation, access, update, or revocation, for auditing purposes. These logs should be immutable and accessible to regulators if required. When Aman’s data is processed based on his consent, SmartApp must have a record of that entire transaction chain.
A PRACTICAL ANALYSIS OF THE BRD:
The BRD marks a pivotal shift in India’s data protection regime, reconfiguring the digital relationship between Data Principals, Data Fiduciaries, and Consent Managers. It provides a structured, enforceable framework for implementing consent that is not just lawful but transparent, auditable, and user-friendly. Rather than treating consent as a static checkbox, the BRD mandates systems that respond dynamically to a user’s evolving preferences. For Data Fiduciaries, it brings accountability; for Consent Managers, it offers clarity; and for businesses, it presents an opportunity to rebuild digital trust.
It is to be noted how the BRD puts the Data Principal at the centre of the overall system design. Consent, in this view, is not a friction point but an empowering tool. The emphasis on multilingual, accessible, and inclusive interfaces ensures that users like Aman are not lost in translation or buried under legalese. At the same time, it avoids overwhelming users by building in Consent Managers who can offer a consolidated, streamlined experience across platforms. However, Data Principals may initially be overwhelmed by granular consent prompts and legal jargons as may be applicable.
To alleviate this, the introduction of a unified “User Dashboard” becomes particularly beneficial. It empowers Data Principals to view, manage, and revoke all their consents in one place, eliminating confusion and creating a more intuitive consent experience. For common users like Aman, it simplifies navigating their data rights without requiring legal or technical expertise, thus making the ecosystem more democratic and inclusive.
As far as Data Fiduciaries are concerned, the BRD also challenges them with a burden to look inward. Implementing the BRD will not be without friction. Data Fiduciaries may struggle to align their systems with new consent artifact structures. Moreover, they will need to establish robust logging, monitoring, and compliance reporting to withstand regulatory audits. The BRD imposes both responsibility and opportunity, and companies like SmartApp will need to overhaul how they design their systems. This involves restructuring consent workflows, establishing consent validation APIs, tracking every Consent Artifact, and integrating real-time revocation mechanisms. These obligations demand a fundamental cultural and technological transformation, backed by investment in infrastructure, design, and compliance. Yet, this “burden” can be a catalyst for differentiation. In an environment where digital trust is increasingly rare, businesses that proactively implement robust CMS can win long-term customer loyalty. By treating consent not as a checkbox but as a relationship of accountability, Data Fiduciaries can shift from being perceived as exploiters of data to trusted stewards of privacy. As the BRD encourages internal transparency through logs, audit trails, purpose-specific records, and user notifications which ultimately benefit both compliance and user trust, implementing these expectations will require a blend of cross-functional collaboration, from engineering and legal to product and customer service.
On the other side of the coin, the BRD’s uniform compliance design, applicable to all types of entities, regardless of their size, data volume or risk, departs from international best practices, which usually allow smaller companies or low-risk players more flexible or scaled-back options. As a result, the uniform approach in the BRD may unintentionally create entry barriers for start-ups or smaller players who lack the resources of larger organisations.
Another concern lies in the fact that the BRD has been issued merely as a guidance document and does not carry any legal binding force. In the absence of formal clarification on its enforceability or a transition roadmap, it remains uncertain what specific compliance measures are expected and by when. This lack of legal clarity has left many industry stakeholders in a state of ambiguity.
CONCLUSION:
Pursuant to our understanding of the BRD, it is evident that the BRD is far more than a technical compliance guide. While currently it issues a non-binding framework, it attempts to bridge legal principles under the DPDP Act with design practicality and does so in a way that respects the Data Principals. What stands out most is the BRD’s layered structure, which balances standardization with adaptability.
A question that inevitably arises in the age of artificial intelligence (AI) is whether AI can play a role in Consent Management Systems. The answer is nuanced. On one hand, AI has the potential to enhance user experience, through intuitive dashboards, predictive consent options, or multilingual prompts based on past interactions, along with helping Data Fiduciaries streamline the data processing through AI generated tools. On the other hand, introducing AI into CMS workflows presents unique risks, including algorithmic opacity, unintended bias, and diminished user control. The use of AI must remain explainable, overridable, and auditable. If implemented carelessly, it could erode the very trust the BRD aims to establish. Thus, AI should be treated as an assistive layer, not a replacement for explicit and informed user choices.
In closing, the BRD is both a challenge and a chance. While it sets a high bar for compliance and seeks a fundamental shift in how consent is handled, it also offers India a path to create a more equitable, transparent, and user empowered data ecosystem. Should the future regulatory developments provide clarity on its formal status and implementation timelines, the BRD could serve as a strong foundational document for empowering Data Principals and guiding Data Fiduciaries in aligning with emerging data governance norms. Only then can the BRD evolve from a guiding framework into a trusted foundation for India’s digital future.
Footnotes
[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf
[2] https://www.dpo-india.com/Resources/privacy_laws_in_India/Business-Requirement-Document-Consent-Management-DPDP-Act.pdf
[3] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679
[4] DPDP Act, 2023 – Section 2(j): Data Principal means the individual to whom the personal data relates and where such individual is – i) a child, includes the parents or lawful guardian of such a child; (ii) a person with disability, includes her lawful guardian, acting on her behalf.
[5] DPDP Act, 2023 – Section 2(i): Data Fiduciary means any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data
[6] DPDP Act, 2023- Section 2(g): Consent Manager means a person registered with the Board, who acts as a single point of contact to enable a Data Principal to give, manage, review and withdraw her consent through an accessible, transparent and interoperable platform.
[7] DPDP Act, 2023 – Section 6(1): The consent given by the Data Principal shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose.
[8] https://www.w3.org/WAI/WCAG20/versions/guidelines/wcag20-guidelines-20081211-a4.pdf
[9] DPDP Act, 2023 – Section 12(3): A Data Principal shall make a request in such manner as may be prescribed to the Data Fiduciary for erasure of her personal data, and upon receipt of such a request, the Data Fiduciary shall erase her personal data unless retention of the same is necessary for the specified purpose or for compliance with any law for the time being in force
