DPDP compliance checklist for companies in India

Audience: founders, operations, product, compliance-minded teams · Last reviewed: March 2026

This checklist is a structured first-pass review for practical DPDP readiness. It mirrors major statutory themes (notice, consent and lawful processing, rights of data principals, duties of data fiduciaries, children where relevant, retention, security posture, and governance)—in operational language. It is not exhaustive of every edge case; validate final positions against the published Act, notified rules, and qualified counsel for your facts.

How to use this checklist

1. Use this as a cross-functional review, not a legal-only exercise.
2. Document real systems, real forms, real vendors, and real owners.
3. Mark each item as complete, partial, unclear, or not started.
4. Turn the weak areas into named action items with owners and dates.
5. Validate sensitive interpretations against official materials and qualified legal advice where needed.

1. Scope, roles, and inventory

1. Confirm applicability. Review whether your processing of digital personal data in India, and your role (e.g. fiduciary, processor, or mixed relationships), falls within the practical scope of the regime you are assessing—see who the Act applies to.
2. Map personal data end‑to‑end. Inventory collection points across product, web and app forms, CRM, support, HR, sales, marketing, payments, analytics, logs, and vendor-connected systems (mapping guide).
3. Document purposes per category. Tie each material category to a concrete business purpose; avoid “we might use it someday” defaults.
4. Clarify fiduciary vs processor. For each major vendor or internal unit, document who determines purpose and means vs who processes on instructions (fiduciary, processor).

2. Lawful processing (consent and other grounds)

1. Identify the legal basis. For each processing activity, record whether reliance is on consent, legitimate uses applicable to your facts, or other permitted routes described in law—see lawful uses and consent; escalate grey areas.
2. Consent quality. Confirm notices are available in English or scheduled languages as required, requests are specific and informed where consent is used, and users can access notices separately from consent capture.
3. Consent logs and change history. Ensure you can demonstrate what was shown, when, and how preferences or consent changed (recordkeeping).
4. Voluntary and separable. Review bundling, dark patterns, and whether “consent” is masquerading as a non-consensual gate—especially in growth and onboarding flows.

3. Transparency, notices, and fair processing

1. Privacy notice accuracy. Public notices must match real behaviour (collection, purposes, retention disclosures, rights, grievance contact)—use privacy notice checklist.
2. Point-of-collection clarity. Users should not need insider knowledge to understand what is collected at signup, checkout, support, or device permissions.
3. Marketing and communications alignment. Align lifecycle email/SMS/push programmes with consent and preferences; document unsubscribe and preference centres.
4. Accuracy and correction hooks. Processes exist to correct inaccurate or misleading personal data that you store or display.

4. Rights of data principals (workflows)

1. Access requests. Intake, identity checks, scope, timeline, and export formats are owned and tested (access & correction).
2. Correction requests. Routing to systems of record and customer-visible surfaces is defined.
3. Erasure / deletion. Product, backups, CRM, analytics, and vendors are covered; exceptions are documented (deletion).
4. Grievance redressal. A visible channel, escalation path, and internal playbook exist (grievance).
5. Withdrawal of consent. Users can withdraw as easily as giving consent where consent is the basis; downstream processing stops or lawful bases are revalidated (withdrawal).
6. Nomination. You can explain how nomination requests are handled where they arise (nominate).
7. Complaint rehearsal. Run a tabletop before regulators or angry customers force it (complaints).

5. Children and age-sensitive processing

1. Identify child-facing flows. If minors are in scope, review parental or guardian verification, notice, consent mechanics, and advertising restrictions per statute—children’s data rules.

6. Security safeguards and incidents

1. Reasonable security. Map technical and organisational measures proportionate to risk; align with engineering and InfoSec, not only legal PDFs (fiduciary duties).
2. Incident and breach readiness. Know who declares an incident, how personal data impact is assessed, how evidence is preserved, and how user or authority communications are routed—tie to operational workflows and penalties context.

7. Retention and erasure

1. Retention schedule by category. No infinite retention “by default”; triggers for deletion or anonymisation are defined (retention checklist).
2. Backup and archive reality. Document whether restores re‑introduce “deleted” data and how long that persists.

8. Cross-border transfers (if applicable)

1. Transfer inventory. List jurisdictions and mechanisms permitted at the time of review; revalidate when rules or whitelist/blacklist notifications change.
2. Contracts and assessments. Ensure processor/fiduciary agreements reflect access, sub-processing, deletion, and assist obligations.

9. Significant data fiduciary and enterprise posture (if applicable)

1. Threshold analysis. If volume, sensitivity, or risk could trigger heightened obligations, document your position and board-level accountability plans—significant data fiduciary, enterprise questions.
2. Diligence artefacts. Maintain evidence packs customers and investors can inspect without last-minute panic.

10. Vendors and processors

1. Sub-processor visibility. Maintain a living list of vendors, data categories, purposes, and exit/delete expectations (vendor checklist).
2. DPA and privacy terms review. Role fit, security commitments, audit assistance, and subprocessors match operational risk.

11. Governance, ownership, training, cadence

1. Named owners. Notices, DSARs, inventory, vendor reviews, and incidents each have a DRI and backup.
2. Training. Support, product, ops, marketing, and engineering complete role-relevant training (awareness training).
3. Periodic review. Re-run this checklist when product surfaces, vendors, marketing channels, or corporate structure change materially.

What this usually reveals

Most teams discover gaps in form design, notice language, deletion logic, vendor visibility, internal ownership, and support-team readiness long before they discover exotic legal issues. That is normal. The point of a first-pass compliance review is not to look polished. It is to identify the obvious weak points before customers, enterprise buyers, or complaints do it for you.

Common weak spots

• Forms ask for data nobody can justify later
• Privacy notices describe an older version of the product or process
• Marketing and product teams assume consent mechanics are someone else’s job
• Deletion is promised externally but not operationally verified internally
• Support teams receive requests without clear escalation instructions
• Vendor access expands over time without fresh review

Best next moves after this page