DPDP privacy notice checklist

Audience: founders, product, ops, marketing · Last reviewed: March 2026

Privacy notices are a fast signal of whether you understand real data practices. This checklist ties notice content to transparency, fair processing, and rights-handling expectations you must be able to operationalise—not generic policy prose.

Identity and contact

1. Who is speaking. Users can identify the data fiduciary (and, where relevant, representatives) without corporate archaeologists.
2. Grievance contact. A clear channel for questions and complaints matches what you publish elsewhere and is monitored (grievance).
3. Language and accessibility. Notices required in English or scheduled languages are actually available in those forms where the law applies to your audience.

What you collect and why

1. Categories of personal data. Describe what you collect in plain terms (not only legal labels) across product, support, billing, marketing, and HR-facing flows if user data overlaps.
2. Purposes. Each material category maps to a specific purpose; “operations” or “improvements” alone are insufficient if they hide real uses.
3. Lawful basis signalling. Where you rely on consent vs other permitted grounds, the notice reflects that distinction accurately (lawful uses).

Sharing and processors

1. Recipients. Users understand categories of recipients or named classes (affiliates, payment, analytics, cloud) consistent with contracts and subprocessors.
2. Transfers. If data leaves India, the notice reflects the fact and points to mechanisms your teams can defend when notified rules require disclosure.
3. Subprocessor lists. If you publish subprocessor pages, they match vendor reality and update cadence (subprocessor page).

Retention

1. Duration or criteria. You state retention in time ranges or clear criteria that engineering and ops can implement—not infinite “as long as needed.”
2. Deletion alignment. Retention claims are compatible with your deletion and rights workflows (retention checklist).

Rights and remedies

1. Rights summary. Access, correction, erasure, grievance, consent withdrawal, and nomination (as applicable) are described in language support teams can honour.
2. How to exercise. Methods match actual intake (email, in-app, web form) and SLAs you can meet.

Children (if applicable)

1. Verifiable parental or guardian context. Notice explains handling of children’s data consistent with your flow and statutory requirements (children’s rules).

Accuracy against reality

1. Product and marketing parity. Support macros, CRM fields, campaign pixels, and “optional” forms do not contradict the notice.
2. Change control. Shipping checklists require notice updates when flows materially change; owners are named.
3. Evidence trail. You can show which notice version was live when a user consented or signed up (recordkeeping).

What teams usually miss

Shadow analytics, partner integrations, legacy databases, support exports, and “temporary” campaign tools often drift outside what the notice implies. Treat drift as a product and ops bug, not a footnote.