Rule 3 Decoded: How to Write a DPDP-Compliant Consent Notice (That Users Actually Understand)
Rule 3 of the DPDP Rules 2025 sets out exactly what a consent notice must contain. Most existing cookie banners and privacy pop-ups fail it. Here is how to build one that passes.
The Most Underrated Rule in the DPDP Rulebook
Everyone talks about penalties, breach timelines, and consent managers. Far fewer people have actually read Rule 3 of the DPDP Rules 2025 — the rule that defines what a consent notice must look like. And that is a problem, because Rule 3 is where most existing cookie banners and privacy pop-ups quietly fail.
If consent is the foundation of the DPDP Act, the notice is the document that makes that consent valid. Get the notice wrong, and every consent you collect on top of it is built on sand.
What Rule 3 Actually Requires
Rule 3 says the notice a Data Fiduciary gives a Data Principal must be:
- Standalone — understandable on its own, independently of any other document. You cannot bury consent terms inside a 40-page privacy policy and call it a notice.
- Clear and plain — written in language an average person understands without legal or technical help.
- Itemised — it must specifically list each category of personal data being collected. "We collect some information about you" fails. "We collect your name, email address, phone number, and browsing history" passes.
- Purpose-specific — for each item, the notice must state the specified purpose of processing, including a description of the goods, services, or uses that the processing enables.
- Actionable — it must include a specific communication link the Data Principal can use to withdraw consent, exercise their other rights, and make a complaint to the Data Protection Board.
The "As Easy to Withdraw as to Give" Test
Rule 3 carries one principle that breaks a huge number of current consent designs: withdrawing consent must be as easy as giving it.
If a user accepted with a single click, they must be able to withdraw with a single click. The dark-pattern playbook — a giant green "Accept All" button next to a buried grey "Manage preferences" link that leads to a maze of toggles — is not just bad UX under the DPDP Act. It is non-compliant.
Key Insight: Symmetry is the simplest compliance test you can apply to your own banner. Put the "give consent" path and the "withdraw consent" path side by side. If they are not equally fast and equally prominent, you have work to do.
Why Most Cookie Banners Fail Rule 3
Walk through a typical Indian website's cookie banner today and you will usually find:
- A vague single line — "We use cookies to improve your experience" — with no itemised list of what data is collected.
- No mention of specific purposes, let alone the goods or services each purpose enables.
- No link to withdraw consent, exercise rights, or complain to the Board.
- English only — which means it is not "informed" consent for the majority of Indian users.
- An "Accept All" button that is impossible to miss, and a "Reject" option that is impossible to find.
Each of those is a Rule 3 failure. Together, they mean the consent collected is legally fragile.
How to Build a Notice That Passes
- Lead with the itemised list. Show the actual data categories — name, email, phone, location, browsing behaviour — not a euphemism.
- Map each item to a purpose. "Email address — to send your order confirmations and account alerts." Concrete, specific, tied to a real service.
- Separate purposes into granular toggles. Necessary, analytics, advertising, personalisation — each independently acceptable or rejectable. Bundled consent is not specific consent.
- Add the rights link, prominently. One link that leads to withdraw consent, exercise access and correction rights, and reach the Board. Not buried in the footer.
- Make withdrawal symmetric. Same number of clicks, same prominence as acceptance.
- Localise into all 22 languages. A notice the user cannot read is not a notice. Schedule 8 coverage is a legal requirement, not a feature.
- Keep a versioned record. When you change the notice, keep the old version. You must be able to prove which notice a given user actually saw when they consented.
The Notice Is a Product, Not a Legal Afterthought
The biggest mindset shift Rule 3 demands is this: the consent notice is not something legal hands to engineering at the last minute. It is a product surface — designed, localised, versioned, and measured like any other part of your application.
This is exactly what Consently is built to deliver. Our consent widget produces Rule 3-aligned notices out of the box: itemised data categories, purpose-level granular toggles, a built-in rights and withdrawal link, symmetric accept/withdraw flows, and automatic localisation into all 22 Schedule 8 languages. Every notice version is recorded, so you can always prove what a user saw and agreed to.
The substantive consent obligations of the DPDP Act take effect on 13 May 2027. The notice is the first thing every user sees and the first thing the Data Protection Board will scrutinise. Build it right — and build it now.