Knowledge Hub · Notices

Rule 3 notice requirements, in practice.

A privacy notice under the DPDP Rules is not a formality you paste at the foot of a form. It is a standalone, itemised, multilingual document that has to land before consent is collected. Here is what Rule 3 actually demands — and where most notices quietly fail.

What it must say

The itemised notice.

Rule 3 requires the notice to be understandable on its own — clear, plain, and separate from any other document. At a minimum it has to itemise the following.

A compliant notice is a checklist before it is a paragraph. Make sure yours states, in plain language:

  • The personal data being collected — itemised, not gestured at. "Information you provide" is not an itemisation.
  • The specific purposes for which that data will be processed — each purpose named, so consent against it can be specific.
  • How the Data Principal can exercise their rights — access, correction, erasure, grievance, and nomination — with the actual mechanism, not just an assertion that the rights exist.
  • How to withdraw consent — and the route must be as easy to find and use as the route by which consent was given.
  • How to make a complaint to the Data Protection Board of India, including the path to the Board after your own grievance process.
  • Contact details for the person or office able to answer questions about the processing.

The test the Rule sets is comprehension: a Data Principal should be able to read the notice and understand what they are agreeing to without legal help.

The language duty

English plus the Eighth Schedule.

A notice that only the English-literate can read is not a notice to most of India. The Rules make language an obligation, not a courtesy.

The notice must be made available in English and in any of the 22 languages listed in the Eighth Schedule to the Constitution of India — at the Data Principal's option. That is not a translate-on-request afterthought; it is a design requirement. A platform that authors a notice once in English and leaves translation to manual effort has a structural gap: the moment a Data Principal asks for the notice in their language and it does not exist in a controlled, version-locked form, the obligation is unmet.

The operational implication is that notice authoring, translation, versioning, and approval have to be one workflow. When the English source notice changes, every language variant has to move with it — or you are serving an out-of-date notice to a portion of your audience.

Sequence matters

The notice gate before consent.

The single most common structural error is collecting consent and showing the notice in the wrong order — or treating them as the same click.

Consent under Section 6 must be informed, and consent cannot be informed if the notice has not been delivered first. The notice gate is therefore a sequence, not a checkbox: the Data Principal sees the itemised, plain-language notice, in their chosen language, and then gives a clear affirmative consent against the specific purposes it names.

Collapsing the two — a single pre-ticked box next to a link to a notice nobody opened — fails on both counts. It is neither a delivered notice nor a free, specific, informed consent. Build the gate so that the notice is presented and acknowledged before any affirmative consent action is available.

Where notices fail

The common failure patterns.

Inquiries and audits tend to find the same handful of defects. Each is avoidable; none is forgiven by good intentions.

  • English-only. The notice exists, it is itemised, it is clear — and it is unreadable to most of the population it serves. Rule 3 names the Eighth Schedule languages for a reason.
  • Bundled consent. One consent covering a bundle of unrelated purposes — marketing, profiling, third-party sharing, core service — all granted by a single tick. Consent has to be specific to each purpose; a bundle is not specific.
  • Vague purposes. "To improve our services" or "for business purposes" cannot anchor specific consent. If the purpose is not concrete, the consent against it cannot be either, and the notice itemisation requirement is not met.
  • Pre-ticked or implied consent. A box already ticked, or consent inferred from continued use, is not a clear affirmative action. It is invalid under Section 6 no matter how good the surrounding notice is.
  • Stale translations. The English notice is updated; the regional-language variants are not. Part of your audience is now served a notice that no longer matches what you do.

Fix these at the source — itemise purposes, gate the notice before consent, author all languages as one versioned workflow — and the notice stops being a liability and starts being evidence.

Is your notice DPBI-ready? Find out in 20 minutes.

The free Readiness Gap Analyser checks your notice, consent, and language posture against Rule 3 — and flags the gaps an inquiry would find first.