DPDP Act, 2023 (India)

Introduction: The Digital Personal Data Protection Act, 2023

The Digital Personal Data Protection Act, 2023 (the 'DPDP Act' or 'the Act') is India's first comprehensive, horizontal data protection legislation. Enacted by Parliament and notified in the Gazette of India on 11 August 2023, it establishes a rights-based framework governing the processing of digital personal data within India, and — in defined circumstances — the processing of Indian residents' personal data outside India. The Act repeals Section 43A of the Information Technology Act, 2000 and its subordinate SPDI Rules (2011), replacing a narrow reasonable-security-practices regime with a principles-driven consent and accountability model broadly comparable to the EU General Data Protection Regulation (GDPR), though materially lighter in obligations and simpler in structure.

This Knowledge Center guide is written for boards, Data Protection Officers, privacy programme leads, legal counsel and security auditors who must operationalise DPDP compliance. It provides an auditor-grade decomposition of every obligation in the Act, a master assessment checklist mapping each duty to verifiable evidence, a phased implementation roadmap, a maturity model, and cross-mappings to GDPR, ISO/IEC 27701, ISO/IEC 27001 and the SPDI Rules. Because the Act is intentionally concise (44 sections across nine chapters) and delegates operational detail to the Digital Personal Data Protection Rules, this guide reflects both the primary legislation and the substance of the Draft DPDP Rules published for consultation by MeitY on 3 January 2025. Where an obligation depends on subordinate rule-making not yet finally notified, this is flagged explicitly.

What is the DPDP Act?

The DPDP Act, 2023 regulates the processing of 'digital personal data' — personal data in digital form, or personal data that is digitised after collection in non-digital form. 'Personal data' means any data about an individual who is identifiable by or in relation to such data. The Act adopts an omnibus, technology-neutral approach: unlike the SPDI Rules, it does not create a special category of 'sensitive personal data', treating all personal data under a single regime (with heightened obligations for children's and persons-with-disability data).

The Act's architecture rests on a small number of defined actors and a core set of principles:

• Data Principal — the individual to whom the personal data relates (includes, for a child, the parent/lawful guardian, and for a person with disability, the lawful guardian).
• Data Fiduciary — any person who, alone or with others, determines the purpose and means of processing personal data (analogous to a GDPR 'controller').
• Significant Data Fiduciary (SDF) — a Data Fiduciary or class notified by the Central Government based on volume/sensitivity of data, risk to rights, sovereignty, electoral democracy, security of the State and public order; subject to enhanced obligations.
• Data Processor — any person who processes personal data on behalf of a Data Fiduciary (analogous to a GDPR 'processor').
• Consent Manager — a registered, accountable entity through which a Data Principal can give, manage, review and withdraw consent via an accessible, interoperable platform.
• Data Protection Board of India (the 'Board') — the adjudicatory body that determines non-compliance and imposes monetary penalties.

Processing must rest on a lawful basis: either the free, specific, informed, unconditional and unambiguous consent of the Data Principal (signalled by a clear affirmative action), or one of the enumerated 'legitimate uses' (formerly styled 'deemed consent'). Every consent-based collection must be preceded or accompanied by a clear notice. The Act confers rights on Data Principals (access, correction, erasure, grievance redressal, nomination) and imposes duties on them (not to file false or frivolous complaints, not to impersonate, not to suppress material information). Penalties are significant — up to INR 250 crore per instance for failure to implement reasonable security safeguards resulting in a personal data breach.

Who must comply with the DPDP Act?

The Act's material and territorial scope is broad. Any organisation that determines the purpose and means of processing digital personal data of individuals in India is a Data Fiduciary and is in scope, regardless of sector, size or whether it charges a fee. The following table summarises applicability by actor and scenario.

Note that the Act does not distinguish sensitive from ordinary personal data for scoping purposes; the single trigger is whether digital personal data of an individual is being processed. Children's data (individuals under 18) carries additional obligations: verifiable parental/guardian consent, and a prohibition on tracking, behavioural monitoring and targeted advertising directed at children (subject to notified exemptions).

Structure of the DPDP Act (chapters, duties and controls)

The Act comprises nine chapters and 44 sections. For assessment purposes it is more useful to organise obligations into control domains that map to how a privacy programme is actually built and audited. The following table maps the statutory chapters to auditable control domains and representative section references.

Master assessment checklist — every domain, control and requirement

This is the core of the guide. Each control domain (D1-D16) is decomposed into specific, testable requirements. For every domain there is a table of 'What to verify' against 'Typical evidence'. An assessor should be able to score each line as Compliant, Partially Compliant, Non-Compliant or Not Applicable, and attach the evidence artefact referenced. Do not skip domains marked as conditional (e.g., SDF, Consent Manager) — record them as Not Applicable with justification if they do not apply.

D1 — Lawful basis and consent (s.6, s.7)

D2 — Notice and transparency (s.5)

D3 — Data Principal rights (s.11-14)

D4 — Data Principal duties (s.15)

D5 — General obligations of the Data Fiduciary (s.8)

D6 — Security safeguards (s.8(5))

D7 — Personal data breach management (s.8(6))

D8 — Data retention and erasure (s.8(7)-(8))

D9 — Processor governance (s.8(2))

D10 — Children and persons with disability (s.9)

D11 — Significant Data Fiduciary obligations (s.10)

D12 — Cross-border data transfer (s.16)

D13 — Exemptions (s.17)

D14 — Consent Manager (s.6(7)-(9))

D15 — Grievance and Data Protection Board interface (s.13, s.18-28)

D16 — Penalties and accountability (Schedule)

The Act's Schedule prescribes maximum monetary penalties. Assessors should quantify exposure per obligation:

Scoping the assessment

Accurate scoping determines audit effort and defensibility. Because the Act applies to all digital personal data (not a sensitive subset), scoping is driven by data flows, systems and legal entities rather than by data category alone.

1. Enumerate legal entities and territories: identify every entity processing personal data of individuals in India, including foreign entities offering goods/services into India.
2. Build the data inventory: catalogue personal data elements, systems, applications and repositories (structured and unstructured).
3. Map data flows: document collection points, internal processing, third-party sharing, Processors, sub-processors and cross-border transfers.
4. Identify the role for each flow: Data Fiduciary, joint Fiduciary, or Processor — and record the lawful basis.
5. Determine SDF likelihood: assess volume, sensitivity, and risk factors that could trigger Significant Data Fiduciary notification, and pre-emptively adopt SDF-grade controls if borderline.
6. Assess children's/guardian data exposure: flag any service reasonably accessed by under-18s.
7. Identify exemptions: record any s.17 exemptions and their precise scope.
8. Define the assessment boundary: in-scope systems, entities, processors and geographies, with documented exclusions and rationale.

Implementation approach (phased)

A defensible DPDP programme is best delivered in five phases. Each phase lists key activities and deliverables. Timelines assume a mid-sized enterprise and should be compressed for SDFs given the enforcement runway following final Rule notification.

Phase 1 — Mobilise and discover (Weeks 1-4)

• Activities: appoint programme sponsor and (for likely SDFs) DPO; establish governance and RACI; conduct DPDP awareness for leadership; launch data-discovery across systems.
• Deliverables: programme charter; RACI matrix; preliminary data inventory; entity/role register; gap-assessment plan.

Phase 2 — Assess and design (Weeks 4-10)

• Activities: complete the master assessment checklist (D1-D16); build RoPA and data-flow maps; perform DPIAs on high-risk processing; design consent, notice and rights-handling architecture.
• Deliverables: gap-assessment report with risk-rated findings; RoPA; DPIA reports; target operating model; remediation roadmap.

Phase 3 — Remediate and build (Weeks 10-20)

• Activities: deploy consent-capture and consent-management (or integrate a registered Consent Manager); publish multilingual notices; implement rights-fulfilment workflows; harden security safeguards; execute retention and erasure automation; renegotiate Processor contracts.
• Deliverables: consent platform; published notices in required languages; DSAR/rights tooling; updated DPAs; retention automation; security control uplift evidence.

Phase 4 — Operationalise and assure (Weeks 20-28)

• Activities: stand up breach-response and Board-notification runbooks; run breach tabletop; establish grievance SLA operations; (for SDFs) appoint independent data auditor and schedule periodic audit and algorithmic-risk assessments; train staff.
• Deliverables: incident-response and breach-notification playbooks; grievance operating procedure; audit schedule; training completion records; KPI dashboard.

Phase 5 — Monitor and improve (Continuous)

• Activities: monitor KPIs; track Rule notifications and Board directions; conduct periodic re-assessment; manage change (new products, vendors, transfers); maintain evidence repository.
• Deliverables: quarterly compliance report to board; updated RoPA and DPIAs; continuous-improvement register; regulatory-change log.

Maturity and capability model

To measure programme maturity, CyberSigma applies a five-level capability model across each control domain. Scoring each domain on this scale produces a heat-map that prioritises remediation and evidences trajectory to the board and (for SDFs) the independent auditor.

Assessment and audit approach

CyberSigma conducts DPDP assessments using a structured, evidence-based methodology aligned to the master checklist. For Significant Data Fiduciaries, the same methodology underpins the statutory independent audit under s.10.

1. Initiation and scoping: confirm entities, systems, geographies and roles; agree assessment boundary and success criteria.
2. Documentation review: examine policies, RoPA, notices, consent records, DPAs, DPIAs, retention schedules and incident logs.
3. Data-flow validation: trace representative personal-data journeys end-to-end, including cross-border and processor legs.
4. Control testing: test each D1-D16 requirement against 'What to verify', sampling live records (consent artefacts, DSAR fulfilment, deletion logs).
5. Technical assessment: review security safeguards — encryption, access control, logging, backups — and, for SDFs, algorithmic-risk exposure.
6. Interviews and walkthroughs: corroborate operating effectiveness with process owners across privacy, security, legal and product.
7. Gap analysis and risk rating: rate each finding by likelihood and impact, mapped to penalty exposure.
8. Reporting: deliver a findings report with a prioritised, costed remediation roadmap and maturity heat-map.
9. Remediation validation: re-test remediated controls and confirm closure.
10. Ongoing assurance: agree the periodic re-assessment / audit cadence and regulatory-change monitoring.

Evidence request list

The following categorised list is the standard evidence pack an assessor will request. Assemble it before the assessment to compress timelines.

• Governance: privacy governance charter; RACI; board/committee minutes; DPO appointment (if applicable); privacy policy suite.
• Inventory and mapping: Record of Processing Activities (RoPA); data inventory; data-flow diagrams; systems catalogue; cross-border transfer register.
• Lawful basis and consent: consent-capture screenshots and copy; consent logs; withdrawal logs; legitimate-use justification memos.
• Notice: published privacy notices; layered/just-in-time notices; language versions (Eighth Schedule); version history.
• Data Principal rights: DSAR/rights procedures; sample fulfilled requests (access, correction, erasure); nomination facility; grievance SLA metrics.
• Security: information security policy; ISO 27001 SoA (if held); encryption and key-management standards; IAM and access-review logs; SIEM/logging configuration; backup and DR test reports.
• Breach management: incident-response plan; breach register; RCA reports; Board and Data Principal notification templates; tabletop reports.
• Retention and erasure: retention schedule; deletion job logs; legal-hold register; pre-erasure notification records.
• Processors and third parties: executed DPAs; sub-processor list; vendor risk assessments; deletion/return certificates.
• Children and disability: age-verification and parental-consent design; ad-targeting suppression evidence; guardian-verification records.
• SDF-specific: DPIA reports; independent auditor engagement and reports; algorithmic-risk assessments; periodic audit reports.
• Training and awareness: training materials; completion records; phishing/breach-drill results.

Roles and responsibilities

Clear accountability is a statutory and practical necessity. The following RACI-style table sets out typical roles in a DPDP programme.

KPIs to track

Measuring the programme demonstrates operating effectiveness and supports the accountability principle. Track at minimum:

• Percentage of processing activities with a documented lawful basis in the RoPA.
• Consent capture rate and consent-withdrawal fulfilment time.
• Data Subject / Principal rights requests: volume, and percentage fulfilled within the prescribed timeline.
• Grievance resolution rate and mean time to resolution against SLA.
• Percentage of Processors under a compliant DPA; sub-processor approval coverage.
• Number of personal data breaches; mean time to detect, contain and notify (Board and Data Principals).
• Percentage of data assets covered by the retention schedule and automated erasure.
• Percentage of records erased on schedule / on consent withdrawal.
• Multilingual notice coverage (Eighth Schedule languages) across customer-facing surfaces.
• DPIA coverage of high-risk processing; number of open high-risk DPIA findings.
• Security-control coverage (encryption, access review completion, log coverage).
• Training completion rate and time-to-completion for new joiners.
• Maturity score per control domain (D1-D16) trend over time.

Readiness checklist

Use this checklist as a go/no-go gate before asserting DPDP readiness.

• Entity and role register complete; every processing flow classified as Fiduciary or Processor.
• RoPA and data-flow maps complete and current.
• Lawful basis documented for every processing purpose; no reliance on pre-ticked or bundled consent.
• Privacy notices published, layered and available in English and required Eighth Schedule languages.
• Consent capture, management and withdrawal mechanisms operational (in-house or via registered Consent Manager).
• Data Principal rights (access, correction, erasure, nomination) fulfilled through documented workflows within SLA.
• Grievance redressal mechanism live, published and meeting the prescribed timeline.
• Reasonable security safeguards implemented and evidenced (encryption, access control, logging, backups).
• Breach-response and Board/Data Principal notification runbooks tested via tabletop.
• Retention schedule enforced with automated erasure and legal-hold controls.
• All Processors under compliant DPAs; sub-processors authorised and bound.
• Children's and guardian consent controls in place where services reach under-18s; harmful/targeted processing suppressed.
• SDF obligations addressed (DPO, independent auditor, DPIA, audit, algorithmic-risk) where applicable, else Not Applicable justified.
• Cross-border transfers screened against the restricted-country list and sectoral localisation rules.
• Accountability evidence repository maintained; board briefed on penalty exposure.

Common gaps observed

• Carrying over SPDI-era thinking and treating only 'sensitive' data as in scope, leaving ordinary personal data ungoverned.
• Consent that is bundled with terms of service, pre-ticked, or lacking a clear affirmative action — invalid under s.6.
• No easy withdrawal mechanism, and no downstream cessation of processing when consent is withdrawn.
• Privacy notices available only in English, missing the Eighth Schedule multilingual requirement.
• No Record of Processing Activities, making lawful-basis mapping and accountability impossible to evidence.
• Absent or untested breach-notification capability to the Board and to affected Data Principals within prescribed timelines.
• Retention 'forever by default' — no schedule, no erasure automation, no pre-erasure notification.
• Processor contracts lacking DPDP flow-down clauses (purpose limitation, security, breach reporting, sub-processing, deletion).
• No age-assurance or parental-consent design in services reachably used by children; continued behavioural ad-targeting.
• Under-preparation for Significant Data Fiduciary status — no India-based DPO, no independent auditor, no DPIA cadence.
• Cross-border transfers assumed compliant without monitoring the restricted-country list or sectoral localisation rules.
• Treating exemptions as blanket carve-outs rather than narrow, documented and scope-limited.
• No demonstrable accountability evidence, weakening the ability to mitigate penalties before the Board.

DPDP Act mapped to other frameworks

Organisations rarely implement DPDP in isolation. The following mapping helps leverage existing GDPR, ISO/IEC 27701, ISO/IEC 27001 and legacy SPDI programmes, and highlights where DPDP diverges.

Key divergences to note: DPDP uses a negative-list (blacklist) model for cross-border transfers rather than GDPR adequacy; it has no separate sensitive-data category; it introduces the unique Consent Manager construct; and its enforcement is via the Data Protection Board rather than a network of supervisory authorities. An ISO/IEC 27701 privacy information management system provides an excellent operational backbone for DPDP, but does not by itself satisfy statutory obligations such as multilingual notice, Board breach notification, or SDF-specific duties.

Frequently asked questions

Need help with DPDP Act?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.