DPDP consent notices: what product teams need to ship

What section 5 actually requires in a notice

Section 5(1) is short and it is a list. Every request for consent must be accompanied or preceded by a notice telling the individual three things: the personal data and the purpose for which it is proposed to be processed, the manner in which she may exercise her rights under section 6(4) and section 13, and the manner in which she may complain to the Board. Rule 3 then requires that notice to be standalone, in clear and plain language, and to itemise rather than gesture.

Most consent screens shipping in India today satisfy the first item and quietly skip the other two. A notice that describes what data is collected but never explains how to withdraw consent, how to exercise rights, or how to complain to the Data Protection Board is not a compliant notice - it is a data-collection statement wearing a notice's clothes.

The three items are not decoration. They are the mechanism by which the Act's rights become reachable: a right the individual is never told about is a right she will not exercise.

• The personal data, itemised - not a category label like usage data.
• Each specified purpose, described well enough to distinguish it from another use.
• How to withdraw consent, in the same place the consent is requested.
• How to exercise access, correction, erasure, grievance and nomination rights.
• How to complain to the Data Protection Board.

The notice must stand on its own

Rule 3 requires the notice to be standalone. That word is doing real work: it rules out the pattern where a consent checkbox carries one sentence and a link, and the actual disclosure lives fourteen screens deep in a privacy policy that also covers eight other products.

A link to a fuller policy is fine as additional context. It cannot carry the information section 5 requires the notice itself to communicate. The test to apply in review is simple - if the reader never followed the link, would she still have received everything section 5(1) lists? If not, the notice is incomplete no matter how good the policy is.

This is the single most common gap in consent flows built before the Rules were notified, because pre-Rules practice treated the privacy policy as the disclosure and the checkbox as the consent. The Rules separate them.

Language is a build requirement, not a localisation nice-to-have

Section 5(3) gives the individual the option to access the notice in English or any language specified in the Eighth Schedule to the Constitution. Section 6(3) repeats the requirement for the consent request itself. That is twenty-two scheduled languages plus English.

The Act says option, not automatic translation into all of them - but the option has to be real and reachable at the point of consent. A product that renders its consent notice only in English has a design gap that no amount of back-end compliance work will close, and it is a gap that gets worse the more of India the product actually reaches.

Treat the notice as versioned, translatable content with a content pipeline behind it, not as a hardcoded string in a component. Teams that hardcode it discover the problem when legal asks for the Marathi version two weeks before launch.

Consent has five adjectives, and each is a design constraint

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, signifying agreement to processing for the specified purpose, and limited to such personal data as is necessary for that purpose.

Read as engineering requirements rather than as legal adjectives, they rule out a familiar set of patterns. Pre-ticked boxes fail unambiguous and clear affirmative action. Consent bundled with terms of service fails free and specific. Consent that gates a service on processing unrelated to delivering it fails unconditional. Collecting fields you do not need for the stated purpose fails the necessity limb regardless of what the user agreed to.

Section 6(2) adds a sharp edge: any part of consent that infringes the Act is invalid to the extent of the infringement. Consent is severable. An over-broad bundle does not fail safely as a whole - the compliant parts survive and the over-reaching parts simply are not consent, which usually means the processing that mattered most has no lawful basis.

Bundling is the failure that surfaces months later

Bundled consent rarely causes problems on the day it ships. It causes them the first time somebody withdraws. If one affirmative action covered account creation, marketing, analytics and a partner integration, then a withdrawal request arrives with no way to determine which processing must stop.

The fix is architectural and it has to be in place before launch: a purpose identifier that travels with the consent record and connects three things - the exact wording the individual saw, the systems and processors that wording activated, and the retention rule that applies when it is revoked.

Without that identifier, partial withdrawal is unimplementable, and teams end up either over-deleting (breaking the service) or under-deleting (continuing processing with no lawful basis). Both are worse than the modest cost of modelling purposes properly at the start.

• Give every purpose a stable identifier, not a display name.
• Version the notice and consent copy; store the version with the event.
• Map each purpose to the systems, processors and retention rule it activates.
• Test partial withdrawal and re-consent as first-class flows, not edge cases.

Withdrawal must be as easy as consent - and that is a systems problem

Section 6(4) requires the ease of withdrawing to be comparable to the ease of giving. If consent was one tap at sign-up, withdrawal cannot require an email to support, a phone call during business hours, or navigating four levels of account settings.

But the screen is the easy half. Section 6(6) requires the Data Fiduciary, within a reasonable time, to cease processing and to cause its Data Processors to cease. Withdrawal therefore has to propagate outward to every downstream system and every vendor that received the data under that purpose - which means you need to know who they are, which is the purpose map again.

Section 6(5) provides useful relief in the other direction: the consequences of withdrawal are borne by the Data Principal, and withdrawal does not affect the legality of processing carried out before it. You are not required to unwind history. You are required to stop, and to make everyone acting for you stop.

Section 6(10) puts the burden of proof on you

This provision deserves more attention than it gets. Where consent is the basis of processing and a question arises in a proceeding, the Data Fiduciary is obliged to prove that a notice was given and that consent was given for the processing in accordance with the Act.

The burden does not sit with the individual to show she never consented. It sits with the organisation to show she did. That inverts the evidentiary posture most consent implementations were built around, and it means a consent record is not internal hygiene - it is the thing standing between you and an adverse finding.

A screenshot of the consent screen proves what the screen looked like at the time it was captured. It does not prove what this individual saw, when, in which language, or what the system did as a result. The record has to tie the person, the version, the action and the downstream effect together.

Consent Managers become real on 13 November 2026

Sections 6(7) to 6(9) create a role no other privacy law has: a registered intermediary through which an individual can give, manage, review and withdraw consent, accountable to her rather than to the organisations paying for the ecosystem. Rule 4 and the First Schedule set the registration conditions, including incorporation in India and a net worth of not less than two crore rupees.

Registration opens on 13 November 2026, a full six months before most operational obligations commence on 13 May 2027. That ordering is deliberate and it matters for planning: the ecosystem is meant to exist before organisations must rely on it.

For most Data Fiduciaries the practical question is not whether to become a Consent Manager but whether their consent architecture can accept and honour a consent decision that arrives from one. If your consent state is only ever written by your own front end, that integration will be a rebuild rather than a connector.

Consent obtained before the Act does not lapse - but it needs a notice

Section 5(2) handles the transition, and handles it more gently than many teams expect. Where consent was given before the Act commenced, the Data Fiduciary must, as soon as reasonably practicable, give the individual a notice covering the same three items - the data and purpose, how to exercise rights, how to complain to the Board.

Crucially, section 5(2)(b) allows processing to continue until and unless she withdraws. There is no re-consent requirement and no cliff edge on which historic consent becomes void. What there is, is a notice obligation with no deadline attached other than reasonable practicability.

The planning implication is that the legacy notice campaign is separable from the new-consent build. Teams often conflate the two and conclude they must re-paper their entire user base before May 2027. They must notify it. That is a different and much smaller project.

What to have in place before 13 May 2027

Most operational obligations, including sections 5 and 6, commence on 13 May 2027. The work that takes longest is not writing the notice copy - it is the purpose model underneath, because it touches every system that holds personal data.

Sequence it so the architecture lands first and the copy lands last. Purpose identifiers, the map from purpose to systems and processors, and a withdrawal propagation path are all prerequisites for a notice that can honestly describe what happens. Copy written before that map exists tends to describe an intention rather than a behaviour.

• A purpose register: every purpose, its identifier, its systems, its processors, its retention rule.
• Versioned notice and consent copy, translatable into Eighth Schedule languages.
• A consent event record adequate to discharge the section 6(10) burden.
• A withdrawal path that propagates to processors and is tested against them.
• A legacy notice plan under section 5(2) for consent obtained before commencement.