The DPDP consent notice requirements come from rule 3 of India's Digital Personal Data Protection Rules, and they ask for three things most notices do not have. The notice must stand on its own, understandable independently of anything else you have published. It must give, in clear and plain language, an itemised description of the personal data and the specific purposes and the goods, services or uses enabled by the processing. And it must tell the Data Principal how to withdraw consent, exercise rights and complain to the Board.
Two words in that list do the damage: itemised and standalone. A privacy policy that says you collect "contact and usage information" itemises nothing, and a notice buried as section four of that policy does not stand on its own.
Rule 3 commences eighteen months after the Rules were published in the Gazette on 14 November 2025, so mid-May 2027. That sounds distant until you work out that the fix is a change to your signup flow and your consent records, not a change to a document.
What the DPDP Consent Notice Requirements Actually Say
The DPDP consent notice requirements set a floor, not a template. Rule 3 says the notice must be presented separately from anything else, written in clear and plain language, and must give at minimum an itemised description of the personal data being collected, the specific purposes for which it is processed, and the goods, services or uses that the processing enables.
That last element is the one teams skip. Naming the purpose is not enough; the notice has to connect the purpose to something the Data Principal actually gets. "Fraud prevention" is a purpose. "So we can place a hold on your account when a login looks like it came from someone else" is the enabled use.
Rule 3 also requires the notice to give the communication link for the Data Fiduciary's website or app and to describe the other means by which the Data Principal can withdraw consent, exercise their rights under the Act, and make a complaint to the Data Protection Board.
Nothing in rule 3 has a size threshold attached to it. The notice duty lands on a twelve-person startup on the same terms as a bank, which is covered alongside the other eleven duties in our DPDP compliance checklist.
What an Itemised Notice Looks Like Next to a Generic One
An itemised notice under DPDP names the field, not the family. The table below contrasts a typical generic notice line with the itemised version, using an illustrative consumer lending app — the data categories are invented to show the shape of the work, not to state anything about what any particular product must collect.
| Generic line in today's policy | Itemised description | Specific purpose | Goods, services or uses enabled |
|---|---|---|---|
| "Contact information" | Mobile number and email address | Sending one-time passcodes and transaction alerts | Logging in to your account and confirming each payment |
| "Identity details" | PAN, date of birth, and a selfie matched against your ID photo | Verifying that you are who you say you are before money moves | Being approved for a loan and having it disbursed |
| "Financial information" | Ninety days of bank statement transaction lines, fetched through an account aggregator with your approval | Assessing repayment capacity | The credit limit you are offered and the interest rate attached to it |
| "Usage information" | In-app screen views and button taps, with device model and OS version | Diagnosing crashes and failed payment journeys | A working app; this data is not used in any credit decision |
| "Device data" | Approximate location derived from the IP address at each login | Detecting logins from places inconsistent with your history | A fraud hold placed on your account before funds leave it |
| "Marketing preferences" | Mobile number used for promotional SMS about other products | Telling you about products you have not bought | Offers you can turn off without affecting your existing loan |
Three things change when you write the right-hand columns. Fields nobody can justify surface immediately, because the purpose column stays blank. Purposes that were doing double duty surface too — analytics data that had quietly become a credit signal. And six itemised lines read faster than four generic ones, because each line tells the reader something.
The left column is not a strawman. It is roughly what most Indian consumer apps published before 14 November 2025, and it was adequate under the regime DPDP replaces.
Why a DPDP Privacy Notice Has to Stand Alone
A DPDP privacy notice has to be understandable on its own, which means it cannot lean on definitions that live somewhere else. If your notice says "we process your data as described in our Privacy Policy," or defines "Personal Information" by cross-reference, the notice does not stand on its own and no amount of rewording inside it fixes that.
This is a structural problem rather than a wording one, and it is the part product teams most often misdiagnose. The usual attempt adds a heading called "Consent" to the existing privacy policy, itemises the data underneath it, and treats the duty as discharged. But that notice is now section 4 of a 12-section document, reached by tapping a link below a signup button, and its meaning depends on the sections around it.
The workable shape is a separate artefact, presented at the moment consent is requested, versioned on its own, and complete on its own terms. Your privacy policy continues to do its broader job. The consent notice is a distinct surface, rendered in the flow, that a reader can understand without leaving it.
Want your current notice read against rule 3 line by line?
Share your work email and we'll mark which lines in your existing notice are itemised, which are generic, and where your signup flow would fail the withdrawal-ease test.
The Withdrawal-Ease Standard in Rule 3(c)(i)
Rule 3(c)(i) is the sentence that turns the DPDP notice duty into engineering work. It requires that withdrawal be available "with the ease of doing so being comparable to that with which such consent was given." One-click in, one-click out.
Read that against a real product and it stops being abstract. Consent is given with a checkbox and a tap during a thirty-second signup. Withdrawal, in almost every app shipping today, requires finding a privacy page, writing to a support address, waiting for a human to pick it up, and possibly answering a verification question. Those are not comparable, and the gap is not closed by promising a faster SLA.
What closes it is a withdrawal control that sits at the same depth as the capture control and executes without a human in the loop. In practice that means four things exist:
- A per-purpose toggle, not one global opt-out, because consent was itemised per purpose and withdrawal has to match that granularity.
- A machine-executed downstream effect, so turning off marketing consent actually suppresses the next SMS batch rather than filing a ticket.
- A record of the withdrawal event with its timestamp and the notice version it applied to, which is what you would produce if the withdrawal were ever disputed.
- A defined behaviour for data already processed, since withdrawal stops future processing and does not by itself erase what retention rules require you to keep.
The fourth point catches teams out. DPDP's own security and retention rules impose a minimum one-year retention floor on personal data, associated traffic data and processing logs, so "withdraw consent" and "delete everything" are not the same instruction and your flow should not pretend they are.
The Communication Link and the Other Means to Withdraw
Rule 3 requires the notice to give a communication link and to describe the other means available, which covers three distinct things the Data Principal might want to do: withdraw consent, exercise their rights under the Act, and complain to the Data Protection Board. Each needs a real route, and the notice has to say what the routes are.
The in-product toggle handles withdrawal for a user who is logged in. It does nothing for a user who has lost access to the account, or who never had one because their data arrived through a third party. The "other means" language is asking you to have a channel that works when the primary one does not, and to name it.
For the complaint route, the notice points to the Board rather than resolving the complaint for you. The grievance machinery sits elsewhere in the Rules, which require you to publish the means by which rights requests are made and your grievance-response period — a period that cannot exceed ninety days and that you have to actually meet.
Write these as specific destinations. "Contact us to exercise your rights" names nothing. The in-app screen, the email address, and the Board as the escalation path are means a reader could use.
Why Consent You Already Hold May Not Carry Over
Consent collected before rule 3 binds was collected against a different notice, and if that notice was not itemised and not standalone, the consent resting on it probably does not meet the standard. Nobody will hand you a ruling on your old flow; you have to judge each consent you hold and decide whether you would defend it.
The test is mechanical enough to run. Pull the notice version that was live when the consent was captured. Does it itemise the data and tie each item to a purpose and an enabled use? Could someone have understood it without opening another document? If either answer is no, you need fresh consent against a compliant notice.
A re-consent exercise is a project with a lead time, which is why mid-May 2027 is closer than it looks. You need the new notice shipped and versioned first. Then a decision per user cohort about whether to re-prompt in-flow, by email, or at next login. Then a plan for the users who do not respond, because an unanswered re-consent prompt is a withdrawal in substance and your processing has to stop accordingly. Then the records to show which consent version each user is on.
Teams that have run cookie-consent migrations under GDPR will recognise the shape of this; the mechanics of reconciling old and new consent records are much the same as the GDPR compliance checklist work many of them have already done. The DPDP difference is that consent carries more weight. GDPR spreads commercial processing across six lawful bases, and a great deal of it runs on legitimate interests rather than consent; DPDP is built around consent and a defined set of legitimate uses, so there is far less to fall back on when a consent record turns out to be weak.
Why This Is a Product Workstream, Not a Policy Refresh
Treat the DPDP consent notice as a product workstream and the plan falls out; treat it as a policy refresh and mid-May 2027 arrives with a beautifully worded document and a non-compliant signup flow. Your lawyer can tell you whether a notice line is adequate. Your lawyer cannot build a per-purpose toggle, instrument a withdrawal event, or decide what happens downstream when marketing consent flips off.
Four of the five pieces of this project sit with engineering and product rather than legal:
- The data map. You cannot itemise what you have not inventoried. The field-level inventory behind the notice is the same artefact as a data asset inventory, and building it is usually the longest task in the project.
- The consent capture surface. A standalone notice rendered at the point of consent, versioned, with the version recorded against each capture.
- The withdrawal path. Per-purpose, self-service, and wired to the systems that act on the consent rather than to an inbox.
- The records. Consent and withdrawal events with timestamps and notice versions, which is logging and monitoring work and benefits from the same retention discipline.
Note what is not on that list: integrating a Consent Manager. The Rules create a registered class of Consent Managers that Data Principals may use, but they do not compel an ordinary Data Fiduciary to route consent through one. Build your own records so they could interoperate with one later, and do not let a vendor convince you the integration is mandatory.
DPDP Consent Notice Questions Teams Ask
These are the DPDP consent notice questions teams ask most often once they have read rule 3 and looked at their own signup flow.
No, and this is the most common structural mistake. Rule 3 requires the notice to be presented separately and to be understandable independently of anything else the Data Fiduciary has published. A section inside a longer policy depends on the document around it for its definitions and its context, so it fails that test even if the section's own wording is excellent. Keep the privacy policy for its broader job and build the consent notice as a separate, versioned surface rendered at the moment consent is requested.
Itemised enough that each item names the data, the specific purpose it is processed for, and the goods, services or uses that processing enables. "Contact information" is a family of fields, not an item. "Mobile number, used to send one-time passcodes so you can log in" is an item. The practical test is whether a reader could tell, for any single field you hold, why you have it and what it does for them. If a field has no purpose you can write down, the itemising exercise has just found something to stop collecting.
No. Withdrawal stops future processing on that consent; it does not override retention duties that other rules or other laws impose. The DPDP Rules themselves set a minimum one-year retention floor for personal data, associated traffic data and processing logs, so a withdrawal flow that deletes everything immediately can put you in breach of a different rule. Define, per purpose, what withdrawal stops and what it does not, and say so in the notice rather than leaving the reader to assume erasure.
Not necessarily separate documents, but the notice has to itemise per purpose, and withdrawal has to be available at the same granularity consent was given. In practice that pushes most teams towards one notice surface that lists the items and purposes, with an individually withdrawable control for each purpose that is not strictly necessary to deliver the service. Bundling six purposes behind one checkbox gives you a consent you cannot unpick when the Data Principal withdraws from one of them.
Rule 3 is in the tranche that commences eighteen months after the Rules were published in the Gazette on 14 November 2025, which puts it in mid-May 2027. That tranche is a single cliff rather than a phased ramp, and it carries the notice, consent, security, breach, retention and rights duties together. Work backwards from it: the data map, then the notice, then the capture and withdrawal flow, then the re-consent exercise for users whose consent rests on the old notice.
Keep notice versions and consent records audit-ready
Book a demo and we'll show how Konfirmity tracks consent notice versions, withdrawal events and the records behind them alongside your ISO 27001 and SOC 2 evidence.
Book a demo
Put the Data Map Before the Wording
Start with the data map, not the wording. Every hour spent drafting notice language before you have a field-level inventory is an hour spent writing about data you have not confirmed you hold, and the itemised description is only as good as the inventory under it. Walk each system, list the fields, and write the purpose and the enabled use next to each one. The blank cells are your findings.
Then build the two surfaces: a standalone notice at the point of consent, and a withdrawal control that matches it purpose for purpose. The notified text of the Rules and the Act is published by the Ministry of Electronics and Information Technology at meity.gov.in, and it is worth reading rule 3 directly rather than through a summary, because the specific words — itemised, independently, comparable ease — are what you will be measured against.
Once the notice and the flow exist, the rest of the DPDP programme has somewhere to attach. Our DPDP compliance checklist sets out the remaining duties and which commencement date each one runs on, so you can sequence the consent work against everything else landing in the same tranche.
