DPDPA audit checklist: a practitioner reference for May 2027 enforcement

Indian privacy practitioner reference · 2026-05-19 · Reflects the DPDP Rules 2025 notification of 13 November 2025

TL;DR

India's Digital Personal Data Protection regime is now live in three phases:

• 13 November 2025 — Rules 1, 2, 17–21 in force. Data Protection Board of India (DPBI) operational. Complaint mechanisms accept filings. The four-person Board is constituted; preliminary investigations have begun.
• 13 November 2026 (in ~6 months) — Consent Manager registration framework (Rule 4) activates. The Consent Manager ecosystem is the structural prerequisite for the full consent regime.
• 13 May 2027 (in ~12 months) — Full operational enforcement. Rules 3 and 5–16 plus Sections 3–17 of the DPDPA become applicable. Penalties up to ₹250 crore (₹2.5 billion) for severe violations begin to bite. Section 43A of the IT Act, 2000 stays in force until this date (the overlap window).

If you process the digital personal data of any Data Principal located in India — whether your entity is in India or anywhere else — DPDPA applies extraterritorially. By May 13, 2027, you need: working consent flows, granular notices, working Data Principal rights mechanisms, breach notification capability with 72-hour detailed notification, retention discipline, and (if you're a Significant Data Fiduciary) an India-based DPO reporting to your Board and independent data audits.

This guide is an audit checklist organised by the lifecycle of personal-data processing under DPDPA. It includes auditor evidence requirements, auditee preparation, common findings, and penalty exposure. Treat it as a working scope document for either internal compliance assurance or for engaging a third-party assessor.

Scope: who needs to comply

DPDPA defines four actors. Know which one you are before you start:

• Data Principal — the individual whose personal data is processed. Your customers, employees, candidates, end-users.
• Data Fiduciary — anyone who, alone or with others, determines the purpose and means of processing personal data. Direct compliance obligations under DPDPA. Equivalent to "controller" under GDPR.
• Significant Data Fiduciary (SDF) — a class of Data Fiduciary designated by the Central Government based on volume/sensitivity of personal data processed, risk to Data Principals, risk to sovereignty/integrity of India, risk to electoral democracy, security of state, public order. SDFs carry additional obligations (Section 10): DPO India-based and reporting to the Board of Directors, independent Data Auditor, periodic data protection impact assessments, periodic data audits.
• Consent Manager — a registered intermediary providing Data Principals with a centralised consent-management platform. Rule 4 framework activates 13 November 2026. Net-new role in the Indian privacy architecture.
• Data Processor — anyone processing personal data on behalf of a Data Fiduciary. Unlike GDPR, Data Processors have no direct statutory obligations under DPDPA. Liability is channelled through the Data Fiduciary's contractual arrangements. Practical effect: tighten your processor contracts now (Rule 6(f) on mandatory security safeguards in the contract).

Extraterritorial reach. DPDPA Section 3(b) applies to processing of digital personal data outside India "in connection with any activity related to offering of goods or services" to Data Principals within India. There is no establishment-or-targeting test; any offering to Indian Data Principals brings the processing in scope.

Sectoral exemptions. Section 17 carves out processing for certain notified state functions, judicial functions, research/archiving subject to standards, certain employment-related processing where adequate. The carve-outs are narrow; assume DPDPA applies unless legal review confirms an exemption.

The IT Act overlap. Section 43A of the IT Act, 2000 and the Reasonable Security Practices Rules, 2011 remain in force until 13 May 2027. During this overlap window, the older regime continues to govern sensitive-personal-data security. After May 2027, Section 43A is repealed and DPDPA fully replaces it. Section 72-A of the IT Act (wrongful disclosure breaching consent or lawful contract) survives and continues to apply alongside DPDPA permanently.

The audit checklist

Each section below has: what the law requires, what the auditor checks, what evidence to produce, and common findings. The structure follows the personal-data lifecycle rather than the section order of the Act, because that is how audits actually work.

1. Personal data inventory and processing-activity mapping

Requirement. Although DPDPA does not explicitly mandate a Record of Processing Activities (ROPA, GDPR Article 30), every other obligation depends on knowing what personal data you process, why, where, by whom, and for how long. Without it, you cannot draft notices, manage consent withdrawal, respond to Data Principal rights requests, or meet breach notification.

Auditor checks. - A current personal-data inventory exists, covering all systems and processing activities. - Each activity is mapped to: data categories, data subject categories, purposes, legal basis, retention period, security measures, third-party processors and recipients, and cross-border flows. - Inventory is refreshed on material change (new product, new vendor, new geography, new processing activity) — not just annually.

Evidence. - Personal data inventory artefact (spreadsheet, GRC tool, or equivalent). - Update log showing material-change-triggered refreshes. - Sample 3 systems and trace from inventory → live system to confirm currency.

Common findings. - Inventory exists for legal/HR/customer data but excludes engineering, telemetry, support tooling. - Vendor flows incomplete — no record of which third-party processors actually receive what. - Material-change refresh dependent on individual memory rather than process trigger.

2. Notice (Section 5 + Rule 3)

Requirement. Before processing personal data with consent, the Data Fiduciary shall give the Data Principal a notice containing: the personal data and the purpose, the manner in which to exercise rights, the manner in which to make a complaint to the DPBI. Rule 3 specifies further detail on notice content. Notice must be in the Data Principal's preferred language from the schedule under Article 348(2)(b) of the Constitution.

Auditor checks. - Notice is given before collection or before processing for a new purpose. - Notice content satisfies Section 5(1) elements: data, purpose, rights mechanism, complaint mechanism. - Notice is plain-language and not buried in long terms-of-service. - Translation to schedule languages is available. - Standalone notices exist for separate processing activities (not blanket umbrella notices).

Evidence. - Notice templates per processing activity. - UX screenshots showing notice delivery at the collection point. - Translation evidence. - Sample 3 notices and verify the four content elements.

Common findings. - Single umbrella notice covering all processing activities — too vague to be informed consent for any specific purpose. - Notice delivered after collection (e.g., on first login rather than at signup). - Translation absent or limited to Hindi/English when other schedule languages are relevant. - "Manner to exercise rights" referenced but the actual mechanism is non-functional.

3. Consent (Section 6 + Rule 5)

Requirement. Consent must be free, specific, informed, unconditional, unambiguous, with clear affirmative action — the classical four-plus-one consent standard. Consent must be capable of being withdrawn at any time, with withdrawal as simple as providing the consent originally. Consent given before DPDPA's commencement is grandfathered subject to giving a fresh notice.

Auditor checks. - Consent capture mechanism produces auditable consent records per Data Principal per purpose. - Withdrawal mechanism exists, is reachable from a "specific communication link" per Rule 3, and is operationally as simple as the consent capture. - Granularity is real: separate consent for separate purposes, not bundled. - No conditional consent: refusing consent does not deny the underlying service unless the service is genuinely impossible without the data. - Consent records are retained as evidence and accessible to DPBI on inquiry.

Evidence. - Consent UX screenshots (capture + withdrawal). - Consent record schema with sample records. - Withdrawal SLA dashboard. - Granularity matrix (purposes × consent toggles).

Common findings. - Consent withdrawal buried under multiple support-ticket layers — fails the "as simple as" test. - Single bundled consent for "service improvement, analytics, marketing, partner sharing" — too coarse to be specific. - Withdrawal accepted but downstream systems (analytics, ad networks, partner shares) not signalled. - Conditional consent: refusing analytics consent denies the core service.

4. Consent Manager registration and use (Rule 4)

Requirement. Rule 4 activates 13 November 2026. Consent Managers are intermediaries registered with the DPBI that provide Data Principals with a centralised consent-management platform. Consent obtained, denied, withdrawn through a registered Consent Manager is verifiable through that Consent Manager's records.

Auditor checks. Pre-Nov 2026, this is forward-looking. Post-Nov 2026: - If using a Consent Manager: verify the chosen Consent Manager is DPBI-registered (the register will be public). - Integration with the Consent Manager's APIs is operational and tested. - Internal consent records reconcile to Consent Manager records.

Evidence. Pre-Nov 2026: documented strategy for the Consent Manager ecosystem and identified candidate providers. Post-Nov 2026: integration evidence and reconciliation logs.

Common findings. Pre-Nov 2026: no strategy at all — Consent Managers treated as somebody else's problem.

5. Purpose limitation and data minimisation (Sections 7–8)

Requirement. Personal data shall be processed only for the purpose for which consent was given or for the legitimate uses defined in Section 7. Personal data shall be limited to what is necessary. Personal data shall be accurate and complete; reasonable steps must be taken to keep it so.

Auditor checks. - Each processing activity has a specified purpose tied to a consent record. - Data minimisation is documented: what data is collected, why each field is necessary, and what was rejected as unnecessary. - Accuracy mechanism: Data Principal can correct, or there is automated correction from authoritative sources. - Section 7 legitimate uses (voluntarily provided personal data, employment, medical emergency, etc.) are documented per use case where invoked.

Evidence. - Purpose register linked to consent records. - Data minimisation analysis per system. - Correction workflow evidence. - Section 7 invocation log with grounds per use case.

Common findings. - Purpose stated as "service improvement" — too vague to bound the processing. - Data minimisation analysis absent; collection driven by "we might need it later." - Section 7 invoked broadly without per-use-case grounds analysis.

6. Data Principal rights (Sections 11–14)

Requirement. Data Principals have rights to: access information about processing (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), nomination (Section 14, on death/incapacity). Each right must have an operational mechanism with reasonable timelines.

Auditor checks. - Per-right mechanism exists, is reachable from the Rule 3 specific communication link, and is operational. - SLA for each right (within reasonable time; the Rules will likely set specifics). - Identity verification of the Data Principal is proportionate — heavy enough to prevent impersonation, light enough not to chill rights exercise. - Grievance redressal under Section 13 is internal first; the Data Principal can escalate to DPBI only after exhausting the Data Fiduciary's mechanism.

Evidence. - Per-right workflow documentation. - Sample rights requests with response evidence. - SLA compliance metrics. - Grievance officer designation and contact details (likely the same as the DPO where one exists).

Common findings. - Access requests handled via generic support without proper identification or documented response. - Correction limited to certain fields (e.g., name yes, but not transaction history corrections). - Erasure not propagated to backups and downstream systems. - Grievance redressal channel exists but no SLA tracking.

7. Children's data (Section 9 + Rule 10)

Requirement. Verifiable parental consent before processing personal data of a child (under 18). Tracking or behavioural monitoring of children and targeted advertising to children is prohibited, with narrow exemptions. Equivalent protection for persons with disabilities, through their lawful guardian.

Auditor checks. - Age-gating at collection to identify children. - Verifiable parental consent mechanism. "Verifiable" sets the bar above click-through confirmations — typically government-ID-tied or credit-card-tied verification or equivalent. - Tracking/behavioural-monitoring/targeted-advertising controls for child users: technically disabled or logically suppressed. - Disability-equivalence: where the Data Principal has a lawful guardian, processes are equivalent.

Evidence. - Age-gate UX evidence. - Verifiable parental consent technical design. - Tracking/advertising suppression evidence for child users. - Disability-equivalence procedure.

Common findings. - Age self-declaration without verification. - "Verifiable parental consent" is parent clicking the same button. - Targeted advertising disabled in the UI but data still flowing to ad networks. - Disability handling completely absent.

8. Cross-border data transfers (Section 16 + Rule 14)

Requirement. The Central Government may by notification restrict transfer of personal data to specified countries or territories. Until such notifications are made, cross-border transfer is permitted subject to Section 16 conditions and Rule 14 specifics (still emerging). This is a negative-list regime: transfers permitted unless restricted, contrasted with GDPR's positive-list adequacy regime.

Auditor checks. - Cross-border flow inventory by destination country, data category, volume, purpose. - Monitoring mechanism for Central Government notifications restricting transfer. - Sectoral-regulator restrictions (e.g., RBI data localisation for payment data, IRDAI for insurance) are layered on top — not overridden by DPDPA's permissive regime. - Contractual safeguards in third-party processor agreements with cross-border processing.

Evidence. - Cross-border flow register. - Notification-monitoring procedure. - Sectoral-regulator restriction mapping. - Sample 2 processor contracts and verify cross-border clauses.

Common findings. - Cross-border flow register incomplete; SaaS-default routings unanalysed. - Sectoral-regulator restrictions not layered (e.g., RBI payment-data localisation missed). - Contracts with cross-border processors silent on data-handling locations.

9. Personal data breach notification (Section 8(6) + Rule 7)

Requirement. Data Fiduciaries shall notify the DPBI and the affected Data Principals in the event of a personal data breach. Rule 7 sets a tiered notification process: an initial notification to the DPBI without undue delay upon becoming aware, and a detailed notification within 72 hours (longer if the DPBI permits on written request). The detailed notification must include: events and circumstances leading to the breach, measures taken or proposed to mitigate, findings on the persons responsible, remedial measures, intimation to Data Principals.

Auditor checks. - Breach response procedure is documented, tested, and owners are named. - Awareness-to-notification time is measurable (the 72-hour clock starts from awareness, not from external public disclosure). - DPBI submission mechanism is identified and pre-staged. - Data Principal notification template exists. - Coordination with sectoral regulators (RBI 6-hour, CERT-In 6-hour, SEBI, IRDAI) is documented — one breach can trigger four notifications simultaneously.

Evidence. - Breach response procedure. - Tabletop exercise records. - Pre-staged DPBI submission template. - Data Principal notification template. - Multi-regulator coordination matrix.

Common findings. - "Without undue delay" interpreted as up to 72 hours — collapsing the tier. - 72-hour clock measured from public disclosure rather than internal awareness. - DPBI submission channel not pre-identified — discovery happens mid-incident. - Sectoral regulators not coordinated; CERT-In 6-hour deadline missed while DPBI focus dominates.

10. Retention and erasure (Section 8(7) + Rule 8)

Requirement. Personal data shall be retained only as long as necessary for the purpose. On expiry of necessity or on consent withdrawal, the data must be erased unless retention is legally required (taxation, regulatory record-keeping, etc.). Rule 8 sets a 3-year retention cap for personal data processed by specific classes of Data Fiduciaries: e-commerce intermediaries with 2 crore (20 million) or more registered users in India; social media intermediaries with the same threshold; online gaming intermediaries with 50 lakh (5 million) or more users. From the later of (a) the Data Principal's last request to perform the specified purpose or (b) Rules commencement. 48 hours prior notice to the Data Principal before deletion.

Auditor checks. - Retention schedule per data category, with legal-basis citation for retention beyond the immediate necessity. - Automated erasure on consent withdrawal where consent is the legal basis. - For special-class Data Fiduciaries: 3-year clock, 48-hour pre-deletion notice, and a procedure to handle re-engagement attempts. - Erasure propagation to backups, logs, third-party processors, and downstream caches.

Evidence. - Retention schedule. - Erasure workflow with downstream propagation. - 48-hour notice template (for special-class Data Fiduciaries). - Sample erasure event traced through all downstream systems.

Common findings. - Retention defaults to "as long as possible" with no schedule. - Erasure happens in primary database only; backups and logs retain. - 48-hour notice missed because the deletion clock is not tracked. - Cross-border processors not signalled on erasure.

11. Significant Data Fiduciary (SDF) obligations (Section 10 + Rules 11, 12, 13)

Requirement. Where designated as an SDF, the Data Fiduciary must: - Appoint a DPO who is an Indian resident and reports directly to the Board of Directors (Rule 11). - Appoint an independent Data Auditor to evaluate compliance (Rule 13). - Conduct periodic Data Protection Impact Assessments (DPIAs) and periodic data audits (Rule 12). - Observe additional measures the Central Government may notify.

Auditor checks. For SDFs (or organisations approaching designation thresholds): - DPO appointment in writing; reports to Board with no intervening layer. - Independent Data Auditor engaged and operating; reports to Board. - DPIA programme operating with frequency-on-trigger (significant change, new processing, new geography). - Data audit cycle operating.

Evidence. DPO appointment letter; Board reporting line documentation; Data Auditor engagement letter; DPIA records; data audit reports.

Common findings. DPO appointed but reports to General Counsel rather than Board; Data Auditor is the same firm as the financial auditor (independence questionable); DPIA performed once and not refreshed.

12. Processor management (Section 8(5))

Requirement. A Data Fiduciary may engage a Data Processor only under a valid contract and shall ensure compliance through that contract. Rule 6(f) requires security safeguards in the contract.

Auditor checks. - Processor inventory with classification (critical / non-critical). - Contracts include DPDPA-compliant clauses: purpose limitation, security safeguards, data return/destruction on termination, sub-processor notification, breach notification flowback, audit rights. - Risk-based due diligence on critical processors.

Evidence. Processor register; sample 3 contracts and verify DPDPA-compliant clauses; due diligence records for critical processors.

Common findings. Existing contracts not updated to DPDPA standard; security safeguards generic ("reasonable security") rather than specified; no audit rights.

Three views: auditor / auditee / CISO+DPO

The same checklist serves three audiences with different priorities.

External auditor view. Auditor focus is on evidence sufficiency and operational consistency. Build the evidence trail to be standalone-defensible: every claim in your compliance posture should have a documented source that the auditor can trace independently. Sampling depth: at minimum two systems per processing activity category; one historic incident or simulated event for breach notification; one historic Data Principal rights request per right type.

Auditee (DPO / privacy team) view. Priorities: get the inventory and Rule 3 notices right early (everything else depends on these); pre-stage the DPBI submission channel and Data Principal notification templates before you need them; build the consent withdrawal flow with the same UX investment as the consent capture; integrate the SDF readiness check into your growth metrics.

CISO+DPO joint view. DPDPA is not just a privacy compliance project; it is a security project too. Section 8(5) security safeguards and Rule 6(f) processor contracts intersect directly with the CISO function. Breach notification (Section 8(6) + Rule 7) merges privacy and security incident response. Practical move: a joint privacy-and-security incident response procedure with the DPO and CISO co-leading, and a joint reporting calendar covering DPBI, CERT-In, sectoral regulators, and Board.

Common audit findings — the recurring pattern

Across early DPDPA audit engagements, the same five findings recur:

1. Notice and consent are decoupled from the data inventory. The notice template promises one thing; the inventory shows another. This is the highest-frequency finding.
2. Erasure is one-database deep. Primary stores cleared; backups, analytics, ad networks, and offshore processors retain.
3. 72-hour breach clock is measured from public disclosure. Internal awareness is the actual trigger; many organisations have no mechanism to mark the "awareness" timestamp objectively.
4. Processor contracts use generic "reasonable security" rather than Rule 6(f) specifics. The contracts are old, drafted for the pre-DPDPA regime, and need re-papering.
5. SDF readiness ignored until designation is imminent. The DPO independence, India-residency, and Board-reporting line cannot be created overnight; build pre-designation.

Penalty exposure under DPDPA

The DPDPA Schedule sets penalties up to ₹250 crore (₹2.5 billion) for failures of significant duties, with lower tiers for specific defaults:

The DPBI determines penalties after inquiry; factors include the nature/gravity/duration of the breach, type of personal data, repetitive nature, gain/loss, and Data Fiduciary's conduct in mitigating the breach. The DPBI may also mediate disputes, which Indian DPOs are reading as an indirect path to settling Data Principal grievances financially even though DPDPA itself does not create a statutory right to damages.

Cross-references to adjacent frameworks

DPDPA does not exist in isolation. Map your DPDPA controls to:

• ISO/IEC 27701:2025 — PIMS standalone certification. Strong alignment with DPDPA at the management-system level (Clauses 4–10 and Annex A controls). Recommended baseline for an audit-defensible privacy programme.
• ISO/IEC 27018:2019 — Cloud PII processor. Layered on top of ISO 27001 for cloud-based processing. Aligns with DPDPA Section 8(5) security safeguards and processor obligations.
• GDPR — DPDPA borrows controller/processor/data-subject concepts and the 72-hour notification structure. If you already comply with GDPR, ~70% of the framework transfers. Watch for the differences: DPDPA's Data Processors have no direct obligations; DPDPA has no sensitive-data tier; cross-border is negative-list not positive-list; Data Principal rights are narrower (no portability, no automated decision-making right yet).
• IT (Intermediary Guidelines) Amendment Rules 2026 — for AI-generated content and SGI handling. Intersects DPDPA when AI processes personal data.
• Sectoral regulators — RBI for banks/NBFCs/payment companies (6-hour CIMS reporting), SEBI for capital markets (CSCRF), IRDAI for insurance (2026 Guidelines), TRAI for telecom. Sectoral rules override DPDPA where stricter (Section 38 conflict-of-laws rule).
• CERT-In Direction 70B — 6-hour incident reporting for any cyber incident. Always parallel to DPDPA breach notification; not substituted by it.

What to do this quarter

If you have not yet started, the sequence that works backward from May 13, 2027:

Q2 2026 (now) — Personal data inventory + processing-activity mapping. Notice templates per processing activity. Initial DPDPA gap analysis.

Q3 2026 — Consent UX redesign with granular capture and withdrawal-as-simple-as-consent. Data Principal rights workflows. Processor contract re-papering (Rule 6(f)).

Q4 2026 — Consent Manager ecosystem strategy (Rule 4 activates 13 Nov 2026). Cross-border flow analysis. Children's-data controls.

Q1 2027 — Breach notification end-to-end test. Erasure propagation testing. SDF readiness check (DPO, Data Auditor, DPIA programme).

Q2 2027 — Full operational readiness. Board sign-off. Mock audit by external counsel.

May 13, 2027 — Enforcement live. The DPBI has been operating since November 2025; enforcement does not start fresh — it scales up against everyone who failed to use the 18-month runway.

A note on what this guide does not cover

Three areas that need separate treatment:

1. Sectoral overlays. RBI for banks (CIMS reporting in 6 hours), SEBI for capital markets, IRDAI for insurance, TRAI for telecom. Sectoral rules can be stricter than DPDPA; layer them, do not assume DPDPA preempts.
2. DPDPA Rules amendments. Some Rule 6 specifics (security safeguards), Rule 12 (DPIA content), Rule 14 (cross-border) remain subject to government clarification through forthcoming FAQs and guidance. Watch DPBI announcements.
3. Litigation under DPDPA. Mediation by the DPBI is novel; the indirect-damages-via-mediation pathway is being tested by early complaints. Indian privacy litigation will surface new operational requirements in 2027–28.

This guide is a practitioner reference, not legal advice. It reflects the DPDP Rules 2025 as notified 13 November 2025 and publicly available DPBI guidance as of 19 May 2026. Compliance teams should validate specific obligations against current MeitY notifications, the DPBI's published procedures, and counsel review.

ControlForge curates DPDPA + Rules 2025 controls integrated with ISO 27701, GDPR, ISO 27018, and sectoral regulators (RBI, SEBI, IRDAI). The synthesis engine surfaces strictest-clause patterns across these frameworks for organisations operating across jurisdictions. Available at controlforge.[domain-tbd].