DPDP privacy policy template

At a glance

This is a free, ready-to-fill privacy policy template covering every section a DPDP-compliant policy needs: who you are, what you collect and why, your legal basis, how long you keep it, who you share it with, people’s rights, and how to raise a grievance. Fill in the bracketed fields, then have the finished policy reviewed against what your business actually does before you publish it. This is your broad, standing document — it doesn’t replace the shorter, purpose-specific notice you still owe someone at the actual point of collection.

Educational resource only. This provides a template for a privacy policy in line with India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice, and you should have it reviewed for your own specific data practices before you use it.

On this page

• What this template is (and when you need it)
• The template — copy and fill in
• How to fill it in
• What this template doesn’t cover
• FAQ

The situation

Search “privacy policy template” and you’ll find hundreds — GDPR-first, generic, or built for a law that isn’t DPDP. Swapping in your company name doesn’t make the underlying structure compliant. This template starts from a complete DPDP section list instead: fill in your specifics, and every section a compliant policy needs is already accounted for.

What this template is (and when you need it)

A privacy policy is the broad, standing document that explains how your business handles personal data generally — this template is a ready-made starting point for writing yours. It covers the fiduciary obligations Section 8 of the DPDP Act and Rule 3 of the DPDP Rules put on any business handling personal data. Use it as your site or app’s standing privacy policy page. It is not the same as the shorter, purpose-specific notice you owe someone at the actual point of collection (see “What a DPDP privacy notice must contain” for that distinction) — a policy explains your practices generally; a notice is shown right when you collect.

The template — copy and fill in

Copy everything below, replace the bracketed fields with your own details, and delete any section that doesn’t apply to you.

How to fill it in

Every bracketed field maps to something Section 8 or Rule 3 actually requires — none of them are optional filler. Have the finished policy reviewed against what your business actually does before you publish it — a policy that doesn’t match your real practices is a bigger risk than an unfinished one.

• [scope]
  • What it means: The surfaces this policy applies to.
  • Examples: Your website, your app, a specific product or feature.
• [Document Name]
  • What it means: The name of any field you collect beyond Name and Email. Pick the one field this row is for — add a separate row for each additional field instead of listing several in one row.
  • Examples: Phone Number, PAN, Aadhaar, or another ID document.
• [purpose]
  • What it means: The specific reason you collect that field, in plain language. Never a vague catch-all like “to improve our services.”
  • Examples: “To personalise your account,” “To send order confirmations,” “To verify your identity by OTP.”
• [legal basis]
  • What it means: Consent, or a specific ground under Section 7 of the DPDP Act (a “legitimate use”) — state which applies for each purpose above.
  • Examples: “Your consent, given at signup.” “Legitimate use under Section 7 — a specified purpose you voluntarily provided data for.”
• [method]
  • What it means: However someone can actually reach you to withdraw consent or exercise a right.
  • Examples: Emailing [email protected], or using a “Manage consent” setting in your account.
• [retention period], [outcome]
  • What it means: How long you keep this data, and what happens when that period ends.
  • Examples: “3 years from your last transaction, then deleted.” “Until you close your account, then anonymised within 30 days.”
• [processors]
  • What it means: Every category of third party you share data with, and whether any of them are located outside India — state plainly if none are.
  • Examples: “Hosting (AWS, Mumbai).” “Analytics (may process data outside India).” “Email and payment providers.”
• [notification method]
  • What it means: How you’ll actually tell people about material changes to this policy.
  • Examples: Posting an updated version here with a new “Last updated” date, emailing registered users.
• [link]
  • What it means: Wherever the current version of this policy always lives.
  • Examples: A URL to this same page, or your app’s settings screen.
• [Name], [email address], [timeframe] — your Grievance Officer
  • What it means: A real person or role handling grievances, not a generic support inbox, plus a real response timeframe you hold yourself to — it’s the clock a complainant can rely on before escalating to the Board.
  • Examples: “Data Protection Officer,” “[email protected],” “30 days.”

What this template doesn’t cover

This is your standing policy, not the point-of-collection notice — and it isn’t legal advice. It doesn’t replace the shorter, purpose-specific notice you still owe someone at or before you collect their data (see “DPDP notice template” for that). It also doesn’t cover consent-flow design, data security controls, or sector-specific requirements, and it doesn’t replace a lawyer’s review of your specific data practices — treat it as a complete starting structure, not a substitute for checking it fits what you actually do.

FAQ

Is this template legally binding as-is? No. It’s a starting structure covering the sections DPDP requires a compliant policy to contain. Fill it in accurately for what you actually do, and have it checked against your own situation before you rely on it.

Is a privacy policy the same as a DPDP notice? No. The policy is your broad, standing document; the notice is shorter and shown at the specific point of collection. You need both — a thorough policy doesn’t discharge the notice duty.

Do I need a separate policy for every product I run? Not necessarily. One policy can cover multiple products if it accurately itemises what each one collects. If two products collect meaningfully different data for different purposes, separate policies are clearer than one policy trying to cover both.

How often should I update this policy? Whenever something it describes changes — a new data field, a new processor, a new retention period. Treat it as a living document, not a one-time file.