That checkbox on your sign-up form is not consent under DPDP. Here’s what actually is.
Most organisations collecting customer data today have some version of a “terms and conditions” tick-box, a pre-ticked marketing opt-in, or a buried consent clause in their privacy policy. Under the Digital Personal Data Protection Act, 2023, none of these will pass scrutiny.
Consent under DPDP is architecturally demanding. It requires technology — not paperwork.
This is Episode 2 of our series on Technology & DPDP Compliance. Today we break down exactly what the law demands from your consent infrastructure, and why a Consent Management Platform is now a compliance necessity, not a product feature.
What does valid consent look like under DPDP?
Section 6(1) of the DPDP Act sets a precise standard: consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It must be limited strictly to the personal data that is necessary for the specified purpose.
The law illustrates this with a pointed example. A telemedicine app that requests consent for providing healthcare services and simultaneously requests access to the user’s mobile contact list — that second element of consent is invalid. Access to a contact list is not necessary for telemedicine. Consent cannot bundle unrelated permissions together and treat the whole as valid.
Every design pattern your product team uses for consent collection — the pre-checked boxes, the accept-all banners, the buried opt-outs — must now be evaluated against this standard. Technology must enforce what the law demands.
Notice must precede consent — and technology must deliver it correctly
Under Section 5 of the Act and Rule 3 of the DPDP Rules, 2025, every request for consent must be preceded or accompanied by a notice. That notice must:
Stand on its own — it must be presented and understandable independently of any other information that has been, is, or may be made available by the Data Fiduciary. It cannot simply point to a 40-page privacy policy.
Be given in clear and plain language — Rule 3(b) requires a fair account of the details necessary for specific and informed consent, including an itemised description of the personal data being collected and the specified purpose or purposes for which it will be processed.
Offer language choice — Section 5(3) and Section 6(3) require the Data Fiduciary to give the Data Principal the option to access the notice and the consent request in English or any language specified in the Eighth Schedule to the Constitution. This has direct implications for the internationalisation and accessibility architecture of your consent platform.
Provide a direct link — Rule 3(c) requires the notice to include the specific communication link to the Data Fiduciary’s website or app through which the Data Principal can withdraw consent, exercise her rights, and make a complaint to the Board.
This is not a notice you can write once and embed as a footer link. It is a structured, purpose-specific, language-aware communication that must be generated and delivered precisely for every consent interaction.
Withdrawal must be as easy as giving consent — your technology must enforce this symmetry
This is one of the most significant technology obligations in the entire Act, and one of the most commonly misunderstood.
Section 6(4) states that where consent is the basis of processing, the Data Principal shall have the right to withdraw her consent at any time, with the ease of doing so being comparable to the ease with which such consent was given.
Read that again carefully. If your onboarding flow allows a user to give consent in two taps on a mobile screen, your withdrawal flow must be equally simple. You cannot put consent on a prominent button and withdrawal behind a support ticket, an email request, or a seven-day processing window. The law explicitly requires parity.
Furthermore, under Section 6(6), once consent is withdrawn, the Data Fiduciary must within a reasonable time cease processing and cause its Data Processors to cease processing the personal data of that Data Principal — unless processing without consent is separately authorised by law.
This cascade — from the Data Principal’s withdrawal click to the cessation of processing across the Data Fiduciary and all its Data Processors — is a technology workflow. It cannot be managed manually at any meaningful scale.
The Data Fiduciary bears the burden of proof
Section 6(10) places a consequential obligation on the Data Fiduciary. Where consent given by the Data Principal is the basis of processing of personal data and a question arises in a proceeding before the Data Protection Board, the Data Fiduciary shall be obliged to prove that a notice was given and consent was given in accordance with the provisions of the Act.
This is the evidentiary burden. Your consent records are not optional audit artefacts — they are legal evidence. If you cannot produce a timestamped, attributable, purpose-specific consent record for every Data Principal whose data you process on the basis of consent, you cannot defend yourself before the Board.
Your Consent Management Platform must therefore be a system of record, not merely a user experience layer.
The Consent Manager — a new regulated entity in India’s data ecosystem
The DPDP Act introduces a distinct regulated category: the Consent Manager. Under Section 6(7), a Data Principal may give, manage, review or withdraw her consent to the Data Fiduciary through a Consent Manager. The Consent Manager is accountable to the Data Principal and acts on her behalf.
Rule 4 of the DPDP Rules, 2025 and the First Schedule set out the full framework. Key technology obligations of a registered Consent Manager include:
A dedicated platform — the Consent Manager must develop and maintain a website or app, or both, as the primary means through which a Data Principal may access its services (Part B, Item 5 of the First Schedule).
An interoperable platform — the platform must enable the Data Principal to give consent to processing by a Data Fiduciary directly, or through another Data Fiduciary that already holds that personal data with the Data Principal’s consent. This interoperability requirement has significant technical architecture implications.
Machine-readable records — the Consent Manager must maintain records of consents given, denied or withdrawn; notices preceding or accompanying consent requests; and sharing of personal data with transferee Data Fiduciaries. These records must be made available to the Data Principal in machine-readable form on request (Part B, Item 4(b)).
Seven-year record retention — the Consent Manager must maintain these records for at least seven years, or such longer period as the Data Principal and Consent Manager may agree upon or as required by law (Part B, Item 4(c)).
Independent technical certification — the platform must be independently certified as consistent with the data protection standards and assurance framework published by the Data Protection Board, with appropriate technical and organisational measures in place (Part A, Item 9 of the First Schedule).
The Consent Manager cannot sub-contract or assign any of its obligations. It must act in a fiduciary capacity in relation to the Data Principal. It must have effective audit mechanisms to review, monitor, evaluate and report its technical and organisational controls, systems, procedures and safeguards to the Board (Part B, Item 12).
What does this mean for your organisation right now?
Whether you are a Data Fiduciary building your own consent infrastructure, or a technology organisation building solutions for DPDP-compliant clients, consent management is no longer a design decision. It is a statutory architecture.
The questions your technology teams must answer include: How does our system generate and serve purpose-specific consent notices, in multiple languages, independently of other platform content? Where do we store consent records, and how do we make them retrievable for evidentiary purposes? How does our withdrawal flow trigger cascaded cessation of processing across our Data Processors? How do we timestamp, attribute, and audit every consent event?
These are engineering problems. Solve them now — before enforcement begins.
Episode 3 of this series will cover Encryption, Masking and Tokenisation — the explicit technical safeguards mandated under Rule 6(1)(a) of the DPDP Rules.
Follow DSK Sustainability Tech LLP for the full series.
In association with our knowledge partners — Karthik & Sunil, Chartered Accountants.
#DPDP #ConsentManagement #DataPrivacy #DataProtection #DPDPCompliance #ITCompliance #ConsentManager #DataFiduciary #DigitalIndia #DSKSustainabilityTech #TechLaw #PrivacyByDesign #CISO #ProductCompliance #DataGovernance
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.