How to Draft a DPDP Privacy Notice
- Name an owner, ticket template, and evidence habit before you debate edge-case wording.
- Start from the smallest repeatable path; avoid boiling the ocean.
- Log decisions so rights and complaints do not reopen old debates.
- Pair this with data mapping and retention reality—not policy alone.
- Escalate interpretation questions; do not invent legal certainty here.
See also: Compliance portal · Official resources · Guides index
A useful privacy notice should help users understand what data is collected, why it is used, and how the business actually behaves. It should not read like generic policy theater.
Users need clear information, not vague blanket language.
Map real workflows before writing the notice.
Rewrite notices whenever product or marketing behavior changes.
What to include
These four items are not a stylistic preference — they trace directly to Section 5 and Rule 3, which require the notice to be understandable on its own (not buried in other material) and to cover, at minimum:
- What categories of personal data you collect (itemised, per Rule 3(b)(i))
- Why you collect and use them (the specified purpose, per Rule 3(b)(ii))
- Where collection happens in the user journey
- How users can reach you, withdraw consent, exercise rights, or complain to the Board (Rule 3(c))
Section 5(3) also requires giving users the option to view the notice in English or any language listed in the Eighth Schedule to the Constitution.
Where teams fail
- Copy-pasting a generic policy that nobody internally can explain
- Letting support, CRM, and lifecycle systems drift outside notice language
- Failing to update notices after workflow changes