(A practical guide for teams building real DPDP compliance)
If there is one area where implementation goes wrong for most organisations, it is Notice and Consent.
The DPDP Act and the 2025 Rules look simple on paper, but once you start rewriting privacy notices or designing consent flows, the gaps become obvious.
Teams either copy GDPR templates, reuse legacy notices, or depend on UI patterns that simply do not meet India’s requirements.
This guide explains, in plain language, what the law actually expects — and the mistakes you want to avoid.
1. Start with Rule 3 — The Core of India’s Notice Requirements
Rule 3 of the DPDP Rules 2025 lays out the mandatory ingredients of a valid notice.
A DPDP-compliant notice must clearly state:
✔ Identity and contact details of the Data Fiduciary
A generic email or a legal name buried in the footer will not suffice.
Teams must explicitly mention:
- Legal entity name
- Physical or registered address
- Contact of Grievance Officer
✔ Itemised list of personal data collected
This is one of the most important differences from GDPR.
DPDP requires a specific, item-wise list of what you collect.
“Information you provide” or “data such as contact details” is no longer acceptable wording.
✔ Purpose of processing — specific, not broad
You cannot write “improve our services”, “enhance experience”, “product development”, “analytics”, or “marketing” as a combined purpose.
Every purpose must be single, clear, and connected to a specific data element.
✔ Rights of the Data Principal
Not just access or correction — include updating, completion, erasure, withdrawal, and nomination.
✔ Consent withdrawal mechanism
Rule 3 requires that the notice “shall contain the manner for withdrawal of consent”.
This means the UI cannot hide the withdrawal link behind:
- multiple steps
- email requests
- customer support calls
- banners that “acknowledge your choice”
✔ Language accessibility
Every notice must be available in English or any language from the Eighth Schedule of the Constitution.
This is a statutory requirement.
2. The Most Common Mistake: Not Providing an Itemised Data List
Notice statements like:
“We collect information such as your name, contact details and other information you provide.”
…will fail under Rule 3.
DPDP expects itemisation such as:
- Name
- Mobile number
- Email ID
- Address
- Device information (model, OS, IP address)
- Payment confirmation details
- Chat transcripts (if applicable)
If your system collects 15 data points but your notice lists only 4, the notice becomes invalid.
This is the most frequent mistake across HR portals, CRMs, mobile apps, and website signup forms.
3. UX Expectations: DPDP Requires ‘Understandable, Accessible, Human-Readable’ Notices
A notice is not compliant if:
- it is hidden behind a link
- written in dense legal language
- placed below the fold
- delivered only after signup
- includes vague or bundled purposes
- requires clicking through multiple screens
- shows the notice after consent is already taken
A DPDP-compliant notice must appear before data collection, clearly visible, and easy to read.
Small teams often underestimate this.
Large companies often over-engineer it with 700-word legal text.
Both approaches fail.
4. Consent Under DPDP: A Very Different Concept from GDPR
DPDP defines valid consent as:
Free, specific, informed, unconditional, unambiguous and given through clear affirmative action.
Let’s break down the parts companies get wrong.
A. “Unconditional” Consent — Frequently Misunderstood
“Unconditional” does not mean:
- the company cannot deny service if consent is refused
- the user gets full access even if the purpose is essential
It means:
- You cannot force additional, unnecessary consent as a condition for the service.
Example:
A food delivery app can require location access for delivery.
It cannot require access to contacts “to improve experience”.
B. No “Legitimate Interest” — Only “Legitimate Use”
GDPR’s Legitimate Interest does not exist under DPDP.
DPDP uses a closed list of Legitimate Use grounds under Section 7:
- voluntary data given for a specific purpose
- compliance with law
- employment purposes
- medical emergencies
- fraud detection
- court orders
- public interest functions
If your GDPR programme depends heavily on “Legitimate Interest”, you must redesign your legal basis mapping.
C. Consent Withdrawal Must Be “Equal Ease”
Another major mistake.
DPDP requires that withdrawing consent should be as easy as giving it.
Meaning:
- no hidden links
- no “email us to withdraw”
- no multi-step processes
- no mandatory calls with customer support
- no refusal unless service genuinely depends on data
“Equal ease” is a real UX requirement, not an aspirational one.
5. Difference Between DPDP and GDPR Notice Patterns
Clients often assume that GDPR notices can be reused.
This almost always fails.
DPDP vs GDPR — Key Notice Differences
| Requirement | GDPR | DPDP (Stricter) |
|---|---|---|
| Itemised data list | Recommended | Mandatory |
| Notice language | Plain language | English or Eighth Schedule language |
| Purpose | Can be grouped | Must be specific & separate |
| Legal bases | 6 bases including Legitimate Interest | Consent + limited Legitimate Use grounds |
| Consent withdrawal | Reasonable ease | Equal ease required |
| Children | Parental consent + age verification | No tracking, profiling, targeted ads |
| Delivery timing | Before or at data collection | Before collection & accessible anytime |
6. The 10 Most Common Mistakes Organisations Make Under DPDP
Mistake #1 — Using GDPR notices without localisation
DPDP needs specific formats and itemisation.
Mistake #2 — Taking consent before showing notice
Illegal under Rule 3.
Mistake #3 — Bundled consent
E.g., “I agree to the Privacy Policy and Terms”.
This is invalid.
Mistake #4 — Vague purposes
“Improve services”, “marketing and analytics”, “product enhancement”—all invalid.
Mistake #5 — Not offering withdrawal with equal ease
If your UI hides withdrawal behind layers, it fails.
Mistake #6 — Not showing notice in accessible languages
At least English or an Eighth Schedule language is mandatory.
Mistake #7 — No audit trail of consent
Logs need to be retained for at least one year (Schedule VI).
Mistake #8 — No separate notices for children’s data
DPDP’s child-protection rules are stricter than GDPR.
Mistake #9 — Using pre-ticked or implied consent patterns
DPDP requires affirmative action.
Mistake #10 — Not updating notices when purposes change
DPDP requires timely communication of any modifications.
8. Practical Checklist for Teams
DPDP Notice & Consent Checklist
✔ Notice shown before any data collection
✔ Itemised list of every data field collected
✔ Purpose for each data field is specific
✔ Consent is explicit and affirmative
✔ No bundled or vague consent
✔ Withdrawal link provided with equal ease
✔ Notice available in English or Eighth Schedule language
✔ Separate notice for children (if applicable)
✔ Log retention configured for 1 year (Schedule VI)
✔ Notice updated whenever purpose changes
✔ Consent Manager integration documented (if used)
9. Final Takeaways
DPDP’s approach to Notice and Consent is stricter, more structured, and more user-focused than most companies expect.
If there is one area to get absolutely right, it is this — because invalid notices automatically make your processing unlawful.
This is where most compliance failures will happen, and where the DPB is most likely to investigate.