DPDPA Rule 3 Decoded: Consent Notice Requirements

Every consent is only as strong as the notice behind it. Under DPDPA Rule 3, a consent notice can no longer be a buried paragraph inside a privacy policy or terms page. It must be standalone, clear, itemised, purpose-specific, multilingual, and linked to easy withdrawal and rights workflows. For Indian enterprises, this is not a copywriting exercise. It is a product, legal, compliance, and engineering project.

Rule 3 of the DPDP Rules 2025 governs one thing: the notice you give to a data principal before processing their personal data. It decides whether the consent you collect is valid. Get the notice wrong, and every consent built on it is exposed.

Rule 3 directly affects whether consent can be treated as specific, informed, and provable: the three conditions a data fiduciary needs to demonstrate to the Data Protection Board if a complaint or audit arises.

The rule was notified on 13 November 2025 and comes into force 18 months later, on 13 May 2027. A MeitY stakeholder consultation in January 2026 discussed the possibility of compressing timelines for some obligations, but no amended gazette has changed the Rule 3 commencement date. 13 May 2027 remains the legal deadline. Enterprises should still plan as if the window can shorten, because the underlying work, rebuilding notices across every journey, does not get faster.

That timeline looks comfortable on a slide. It stops looking comfortable once you count how many notices a typical Indian enterprise actually runs: web signup forms, mobile app permission screens, call centre scripts, in-branch forms, partner and aggregator journeys. Each one has to satisfy Rule 3. Rebuilding all of them, in 22 languages, with working withdrawal flows behind each, is not a one-sprint project.

What Rule 3 Actually Says

Strip out the legal phrasing, and Rule 3 imposes three obligations on the notice a data fiduciary gives a data principal.

1. The notice must stand on its own.

Rule 3(a) says the notice must be presented and understandable independently of any other information the fiduciary makes available. In practice, that ends the common habit of folding privacy disclosures into a 40-page terms of service document. The notice has to be a standalone communication that a person can read and understand without cross-referencing anything else. If a data principal needs to open three other documents to work out what they are agreeing to, the notice fails.

2. It must be itemised and purpose-specific.

Rule 3(b) requires the notice to give, in clear and plain language, a fair account of what is needed for the person to give specific and informed consent. At a minimum, that means two things:

• An itemised description of the personal data being collected. Not "we collect your information." A list: name, mobile number, email, PAN, transaction history, location, and so on.
• The specific purpose of processing, with a specific description of the goods, services, or uses each category enables.

Vague purpose statements do not survive this rule. "To improve our services" is not a purpose. "To verify your identity at onboarding using your PAN and Aadhaar" is. The granularity is the point. A person cannot give specific consent to something described in general terms.

3. It must make withdrawal, rights, and complaints easy to find.

Rule 3(c) requires the notice to carry a communication link to the fiduciary's website or app, and a description of any other means through which the data principal can:

• Withdraw consent, with the ease of withdrawal comparable to the ease with which consent was given;
• Exercise their rights under the Act; and
• Make a complaint to the Data Protection Board of India.

The comparable-ease standard is the part that teams underestimate. If a customer gave consent with one tap inside your app, you cannot route the withdrawal through a support email and a three-day wait. The exit has to be as frictionless as the entry. This is where notice design and data principal rights handling stop being separate workstreams and become one.

The Language Requirement

This is the part the slide title points at, and it sits in the Act rather than in Rule 3 itself. Section 5 of the DPDP Act requires the fiduciary to give the data principal the option to access the notice in English or in any language listed in the Eighth Schedule to the Constitution of India.

The Eighth Schedule has 22 languages. For a consumer business operating across India, that is not a translation nicety. It is a structural requirement. A consent notice presented only in English to a user transacting in Marathi or Tamil does not meet the bar, and the consent collected on it is weak. A notice experience that does not offer the option to access the notice in Eighth Schedule languages creates avoidable compliance risk, especially for consumer businesses operating across India.

For most enterprises, this means a notice library that holds every notice variant in every required language, version-controlled, with a record of which language version each data principal actually saw at the point of consent. That last part matters for evidence later.

The Format Requirement

Beyond standalone and multilingual, Rule 3 and the surrounding provisions push toward genuinely readable notices. Plain language means an average person understands without legal or technical knowledge. A layered presentation means a short top layer links to fuller detail. An accessible form for persons with disabilities is also required.

The format is not cosmetic here. A notice that is technically complete but unreadable defeats the informed part of informed consent, and a regulator assessing a complaint will look at whether a normal user could actually have understood what they agreed to.

What Happens To Consent Collected Before Rule 3 Comes Into Force?

Rule 3 readiness is not only about new journeys. Enterprises collecting personal data today are doing so under consent frameworks that predate the DPDP Rules. When Rule 3 comes into force on 13 May 2027, those existing consent records do not automatically become compliant. The practical question for every DPO is: what was the data principal actually shown, and does that notice meet the Rule 3 standard for ongoing processing?

This matters for three reasons:

Ongoing processing on pre-DPDP consent. If you are continuing to process personal data based on consent collected before Rule 3 came into force, the lawfulness of that ongoing processing depends on whether the original notice was sufficient. A notice that did not itemise data categories, did not specify purposes, or did not offer withdrawal at comparable ease may not support continued processing once the Rules are live.

Identifying gaps in legacy notice inventory. Most enterprises do not have a clean record of which notice version was shown to which user, at which point in time, and in which language. Building that record retroactively is difficult. Building it prospectively, as part of Rule 3 remediation, is the practical path.

Deciding whether re-consent is needed. Where the original consent was collected on a notice that falls short of Rule 3 requirements, the options are to stop processing, restructure the processing basis, or re-collect consent on a compliant notice. Each path has operational implications, and the DPO needs to be able to audit the existing inventory to make that call with evidence rather than assumption.

This is one of the most consequential and underplanned aspects of DPDP readiness. Most organisations are treating Rule 3 as a forward-looking build project. It is also a backwards-looking audit project, and the two need to happen in parallel. Privy's consent governance platform supports both notice management for new journeys and an audit trail structure that helps surface gaps in existing consent records.

Where Most Consent Notices Will Fail Rule 3

From what is live across Indian enterprise sites and apps today, the recurring gaps are predictable:

• Bundled notices. Privacy terms embedded inside general T&Cs, failing the standalone test in Rule 3(a).
• Generic purposes. "For business and operational purposes" instead of itemised, specific purposes tied to specific data.
• Withdrawal friction. One click to consent, a buried form or email to withdraw. Fails the comparable-ease standard.
• English only. No Eighth Schedule language options, weakening consent for a large share of users.
• No proof of what was shown. No record of which notice version and language a given user saw and accepted, which makes the consent unprovable if challenged.

Any one of these is a problem. Most enterprises have several at once, across dozens of journeys. This is also why consent alone does not equal DPDPA compliance: a clean notice on a journey where you cannot prove what was shown, or cannot honour withdrawal downstream, still leaves you exposed.

How To Operationalise Rule 3 Before The Deadline

The work splits into four practical steps.

First, inventory every consent touchpoint. You cannot fix notices you have not located. List every form, screen, and script that collects personal data, and the data and purpose behind each. Include legacy journeys: any touchpoint still running on pre-DPDP consent needs to be in this inventory too.

Second, rewrite each notice to the Rule 3 structure: standalone, itemised data, specific purpose, and a working link to withdrawal, rights, and Board complaints. The DPO's guide to consent governance under DPDP covers the workflow and audit trail side of this in depth. Cookie banners follow the same logic, covered in cookie laws, cookie policies, and cookie manager compliance.

Third, build the language layer. Every notice in English plus the Eighth Schedule languages your user base requires, version-controlled, with the served version logged against each consent.

Fourth, wire the back end. A notice is only as good as the withdrawal and rights flow behind it. Withdrawal has to actually stop downstream processing, and you have to be able to show, on request, exactly what a data principal saw and agreed to. This applies to new consents going forward and to any legacy records where processing continues.

This is the layer that Privy's consent governance is built for: notice management across web and app, multilingual notice libraries, comparable-ease withdrawal, and a tamper-evident record of every notice version, language, and consent event. The Privy consent governance platform handles the inventory, the notice library, and the audit trail in one place, so Rule 3 readiness is a configuration exercise rather than a manual rebuild across every journey. The Privy solutions overview shows how consent governance connects to data principal rights, PIA, and incident management as a single programme.

Conclusion

Rule 3 is short. Compliance with it is not, because it touches every place you collect data, in every language your users speak, with a provable trail behind each consent. The legacy consent question adds another dimension: it is not enough to get new journeys right. Existing consent records also need to be audited, and ongoing processing reviewed against the Rule 3 standard, before the deadline.

May 2027 is the deadline. The enterprises that treat the next few quarters as the build and audit window, rather than the planning window, are the ones that will be able to answer the only question that matters when the Board asks: Can we prove our consent is valid?

From privacy notices and consent management to audit trails and governance, Privy by IDfy helps enterprises build a strong foundation for DPDPA compliance and stay ahead of evolving regulatory requirements. To learn more or schedule a demo, contact shivani@idfy.com

FAQ

When does DPDPA Rule 3 come into force?

Rule 3 was notified on 13 November 2025 and came into force 18 months later, on 13 May 2027. A January 2026 MeitY consultation discussed compressing some timelines, but no amended gazette has changed the Rule 3 commencement date. 13 May 2027 stands. Enterprises should still plan as if the window can shorten, since the remediation work does not get faster.

What must a consent notice contain under Rule 3?

A standalone notice in clear, plain language with an itemised description of the personal data collected, the specific purpose for each category, and a communication link through which the data principal can withdraw consent, exercise their rights, and complain to the Data Protection Board.

In what languages must the notice be available?

Under Section 5 of the DPDP Act, the data principal must be able to access the notice in English or in any of the 22 languages listed in the Eighth Schedule to the Constitution of India.

Does the consent notice need to be separate from the terms and conditions?

Yes. Rule 3(a) requires that the notice be understandable independently of any other information, which rules out burying it in the terms of service or other documents.

What does "comparable ease" of withdrawal mean?

Withdrawing consent must be as easy as giving it. If consent were a single tap, withdrawal cannot require a support ticket or a multi-day process.

What happens to consent collected before Rule 3 comes into force?

Consent collected before Rule 3 is operative is not automatically compliant with its requirements. Enterprises need to audit whether notices used on legacy journeys meet the Rule 3 standard, assess whether ongoing processing on that consent remains lawful, and decide whether re-consent is required for any category of data and purpose. This is a parallel workstream to building new compliant journeys, not a later task.