How to draft a DPDP notice

Short answer
Drafting a DPDP notice starts before you touch any template: audit every point in your product where you actually collect personal data, list exactly what each point collects and why, then decide where in that flow the notice has to appear — it has to show up at or before collection, not in a policy page nobody visits. Once you know your real fields and purposes, filling in the actual notice text takes minutes; figuring out what belongs in it is the part that takes thought.

Educational resource only. This explains how to work out what belongs in a DPDP notice and where to place it under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

On this page

Why this is a mapping problem, not a writing problem
What goes wrong when notices are drafted from memory
Step by step: from data audit to a live notice
Keeping it accurate as your product changes
FAQ

The situation

You’ve been told you need a “notice” on your signup form, your checkout page, your document upload step — but nobody handed you a list of what actually has to be in it, or how many separate notices you actually need. Before you write a word, you need to know what you’re collecting and where, which is a different job from writing the notice itself.

Why this is a mapping problem, not a writing problem

A DPDP notice fails most often because it’s incomplete or misplaced, not because it’s badly worded. Section 5 of the DPDP Act and Rule 3 of the DPDP Rules require an itemised, purpose-specific notice at or before the point of collection — but “at or before the point of collection” only means something once you know exactly where your collection points are. A single product can have several: a signup form, a checkout step, a document upload, an in-app permission prompt. Each one that collects different data for a different purpose needs its own itemised notice content, even if the visual template is the same.

What goes wrong when notices are drafted from memory

Writing a notice from what you remember collecting, instead of what you actually collect, is the single most common way this goes wrong. Products grow field by field — a phone number added for OTP login, an address added for a delivery feature, a date of birth added for an age gate — and the notice rarely gets revisited each time. The result is a notice that was accurate at launch and silently wrong six months later: it’s missing fields you now collect, or it states a purpose that’s no longer the real one. Because the burden of proving valid, informed consent sits with you, a notice that doesn’t match your actual collection isn’t a paperwork gap — it undercuts the consent itself.

Step by step: from data audit to a live notice

Work through your product before you work through the template.

List every point in your product where you collect personal data. Signup, checkout, document upload, an in-app form, a permission prompt — walk the actual product, not your memory of it.
For each point, list exactly what fields you collect and the specific purpose for each. “To improve our service” isn’t a purpose; “to verify your identity by OTP” is.
Group by purpose, not by screen. If two different screens collect a phone number for the same purpose, one itemised notice content block can cover both. If the same screen collects data for two unrelated purposes, that’s two notice entries, not one.
Decide where the notice actually needs to render — at or before that exact collection point, not buried in a general privacy policy page the person may never open.

Use the template
DPDP privacy notice template — a free, ready-to-fill notice covering every item Section 5 and Rule 3 require. Once you’ve mapped your fields and purposes above, this is where you drop them in.

Fill the template once per distinct purpose group, not once for your whole product — reuse the same structure, different itemised rows.
Wire in the mandatory actions, not just the mandatory text: a working way to withdraw consent, a working way to exercise rights, a named grievance contact, and a route to the Data Protection Board of India. A notice that states these but doesn’t actually connect to a working process isn’t complete.
Get it reviewed against what you actually built, not what you planned to build — the two drift apart more often than teams expect.

Keeping it accurate as your product changes

Treat the notice as something that ships with the feature, not something you write once and forget. Every time a new field gets added to a form, or a feature starts collecting something it didn’t before, that’s a trigger to revisit the relevant notice — the same discipline as updating your changelog. A notice that was correct at launch and never touched again is the most common way this requirement quietly breaks.

FAQ

Do I need a separate notice for every form on my site? Not necessarily every form, but every distinct collection point with a distinct purpose. Two forms collecting the same data for the same purpose can share one notice; different purposes need their own itemised content.

How long should mapping my data collection points take? For a small product, an afternoon of walking through your actual signup, checkout, and account flows. The template itself takes minutes to fill once you know your fields and purposes — the audit is the real work.

Can I just put one notice in my privacy policy and call it done? No. A general privacy policy doesn’t satisfy the point-of-collection requirement — the notice has to appear at or before the specific moment you collect the data, standing on its own.

What if my product collects different data depending on the user’s region or plan? Map each variant separately. If a premium plan collects an extra field a free plan doesn’t, that’s a distinct purpose group needing its own itemised notice content.