DPDP Act 2023 Compliance Checklist: 47 Controls Every Indian Business Must Implement

The Enforcement Clock Is Running

The Digital Personal Data Protection (DPDP) Act 2023 is no longer a future obligation. The Data Protection Board (DPB) is operational, the Rules are notified, and the first show-cause notices are being issued. If your business collects, stores, or processes any digital personal data about Indian residents — employees, customers, prospects — you are a Data Fiduciary and these rules apply to you now.

This checklist maps all 47 controls to the 7 principal obligations in Schedule I of the Act, shows the penalty exposure per gap, and closes with a 14-day quick-start plan.

Obligation 1: Lawful Basis and Consent Management (Controls 1–9)

Every act of personal data processing must rest on a valid legal basis. For most private businesses, that basis is consent — and the Act is precise about what valid consent looks like.

Controls

1. Consent notice is written in plain language — no legalese, no buried clauses. Must state the purpose of processing and the data being collected. (Penalty if missing: up to ₹50 Cr for non-compliant notice under Section 33(b))
2. Consent is granular — one checkbox per purpose, not a single "I agree to everything." Marketing, analytics, and functional use must be separately toggled.
3. Consent is freely given — you cannot withhold a core service because the user declined a marketing opt-in. Gate only the data processing actually needed for the service.
4. Consent withdrawal is as easy as giving it — a user who opts in via one click must be able to opt out via one click. No "email us to unsubscribe."
5. Consent records are stored and auditable — timestamp, version of notice shown, IP or device identifier. Minimum retention: the life of the data + 3 years.
6. Re-consent triggers are defined — any material change to purpose or data categories must re-trigger the consent flow, not assume prior consent extends.
7. Legitimate use basis is documented — if you rely on legitimate use (employees, national security exceptions), you have written rationale on file.
8. Children's data safeguards are in place — if you serve users under 18, you have verifiable parental consent and no behavioural tracking or targeted advertising.
9. Consent management platform (CMP) is integrated — developer-only workarounds are not acceptable; consent state must be programmatically accessible to all downstream systems.

Obligation 2: Purpose Limitation and Data Minimisation (Controls 10–15)

Data collected for one purpose cannot silently migrate to another. This obligation is violated more often by architecture decisions than by policy — analytics pipelines, CRM imports, and ML training datasets are the usual culprits.

1. Data inventory is complete — every personal data field in every database, SaaS tool, and third-party integration is documented with: what, why, retention period, and who has access.
2. Purpose binding is enforced in code — data labelled "support ticket" cannot be read by the marketing pipeline. Role-based access controls (RBAC) enforce purpose at the API level.
3. Data minimisation is reviewed annually — any field you collect but cannot demonstrate a live business need for must be deleted.
4. Third-party SaaS sharing is mapped — every SaaS tool that receives personal data is listed, with the data processor agreement (DPA) status noted.
5. Analytics anonymisation is verified — if you claim aggregated analytics don't count as personal data, you have a re-identification risk assessment on file.
6. CRM segmentation does not infer sensitive categories — inferring religion, caste, or health status from purchase behaviour is considered processing sensitive data even if the raw field is not present.

Obligation 3: Data Quality and Accuracy (Controls 16–19)

1. Data correction mechanism is available — users can submit corrections; corrections are processed within 30 days (suggested SLA, not yet mandated but expected by DPB).
2. Data correction propagates to downstream systems — a correction in the CRM must flow to the data warehouse, backup systems, and any third-party processors within the same window.
3. Stale data review schedule exists — personal data older than your stated retention period is flagged for deletion or re-validation on an automated schedule.
4. PII in logs is masked or excluded — application logs, error tracking tools, and analytics do not contain raw names, phone numbers, Aadhaar numbers, or email addresses.

Obligation 4: Reasonable Security Safeguards (Controls 20–32)

This is the obligation most directly mapped to technical security. Section 8(5) requires Data Fiduciaries to implement "reasonable security safeguards to prevent personal data breach." The DPB has indicated it will use ISO 27001 and OWASP as benchmarks.

1. Annual VAPT scan is conducted — covering web applications, APIs, and network perimeter. Report must be from a qualified CERT-In empanelled vendor.
2. Critical vulnerabilities are remediated within 30 days — evidenced by a re-scan or patch confirmation, not just a ticket.
3. Encryption at rest is implemented — personal data in databases and backups uses AES-256 or equivalent. Encryption keys are stored separately from the data.
4. Encryption in transit is enforced — TLS 1.2 minimum on all endpoints handling personal data. TLS 1.0/1.1 is disabled. HSTS is enabled.
5. Access control is least-privilege — no shared admin credentials, no production access for developers by default, all privileged access via PAM or equivalent.
6. Multi-factor authentication (MFA) on all admin access — not optional for any system that stores personal data.
7. Database credentials are not hardcoded — environment variable management or secrets manager (AWS Secrets Manager, Vault, etc.).
8. Personal data backup is encrypted — backups are treated as equal-sensitivity to production data.
9. Data masking in non-production environments — QA and staging environments use anonymised or synthetic data, never production PII.
10. Security logging and monitoring is active — failed login attempts, privilege escalation, and bulk data exports trigger alerts within 15 minutes.
11. Incident response plan is documented and tested — tabletop exercise at minimum once per year.
12. Patch management policy is in place — OS, framework, and dependency patches are applied within defined SLAs based on CVSS score.
13. Third-party vendor security is assessed — every data processor has completed a security questionnaire or provided an equivalent certification (ISO 27001, SOC 2) before access is granted.

Obligation 5: Data Principal Rights (Controls 33–38)

Data Principals (your users) have six statutory rights under the Act. You must build the infrastructure to honour them.

1. Right to access: a self-service data export is available — users can download all personal data held about them within 30 days of request.
2. Right to correction: a correction request form or flow exists — in-app or via a documented email process with confirmed SLA.
3. Right to erasure: a deletion workflow is implemented — deletion must be complete across primary databases, backups, and third-party processors. A deletion certificate is recommended.
4. Right to grievance redressal: a Data Protection Officer (DPO) is nominated — name, email, and response SLA published on your website privacy page.
5. Right to nominate: a nominee designation flow exists — allows a user to designate another person to exercise rights in case of death or incapacity.
6. Rights requests are tracked and SLA-monitored — not handled ad hoc via inbox. A ticketing system or dedicated module with escalation paths.

Obligation 6: Data Retention and Deletion (Controls 39–43)

1. Retention schedule is documented per data category — customer PII, employee data, transaction records, and support tickets each have a defined retention period tied to business or legal need.
2. Automated deletion pipelines exist — retention enforcement is not a manual task. Cron jobs or data lifecycle policies in cloud storage handle deletion automatically.
3. Right-to-be-forgotten requests are processed within 30 days — including removal from email lists, analytics platforms, and third-party processors.
4. Deletion is verified and logged — a deletion log entry is created for each erasure, noting what was deleted, when, and from which systems.
5. Backups respect deletion obligations — incremental or differential backups that capture deleted records are purged on the next backup cycle.

Obligation 7: Breach Notification (Controls 44–47)

This is the most operationally intense obligation — you have a narrow window when a breach occurs.

1. Breach detection capability exists — SIEM, WAF alerts, or equivalent that can identify a breach event in real time or near-real time.
2. Internal escalation runbook is in place — who gets called at 2 AM, who makes the call to legal, who drafts the DPB notification. Roles, numbers, and a decision tree on paper before an incident.
3. DPB notification template is drafted — the form requires: nature of the breach, categories of data affected, number of individuals affected, likely consequences, and measures taken. Pre-drafting the template under calm conditions saves hours under pressure.
4. CERT-In parallel obligation is covered — CERT-In's 2022 Direction requires incident reports within 6 hours of detection. Your runbook must handle both DPB and CERT-In simultaneously.

14-Day DPDP Quick-Start Plan

Get your free DPDP gap assessment at bachao.ai/dpdp-compliance. We'll review your consent flows, run a VAPT scan, and give you a prioritised remediation list — mapped to the exact controls above.

Written by Shouvik Mukherjee, Founder, Bachao.AI. 15+ years in software engineering, now building AI-powered security products. Fourth-time founder. DPIIT Recognised Startup.