DPDPA Compliance Guide for Businesses (2023)

Key Takeaways

• Every organisation that decides the purpose and means of processing personal data is a Data Fiduciary under DPDPA — including SaaS vendors, fintech platforms, e-commerce operators, and HR technology providers.
• The Act imposes per-contravention financial penalties, not per-record fines. Failing to take reasonable security safeguards to prevent a personal data breach carries a ceiling of ₹250 crore (~USD 26 million) under the Schedule to the Act (Section 33(1)).
• DPDPA has no "sensitive personal data" statutory category — a critical difference from the 2019 PDP Bill and GDPR. Financial, health, and biometric data of adults are governed by the same Section 8(5) obligation as all other personal data.
• Cross-border data transfer under Section 16 is a negative-list model: transfers are permitted by default and are restricted only to countries notified by the Central Government. There is no blanket data localisation requirement.
• Rule 6 of the DPDP Rules 2025 is the operational text for Section 8(5): it sets the minimum safeguards — encryption, obfuscation, masking or tokenisation; access control; logging, monitoring and review; backups; one-year retention of those logs; and security clauses in Data Processor contracts.
• Significant Data Fiduciaries carry additional obligations under Section 10(2): a Data Protection Officer based in India, an independent data auditor, and periodic Data Protection Impact Assessments and audits. Rule 13 makes the DPIA and audit annual and adds algorithmic due diligence and possible localisation of specified data.
• Grievances must be answered within a reasonable period not exceeding 90 days (Rule 14(3): publish that period on your website or app, and meet it), and a Data Principal must exhaust this route before approaching the Data Protection Board (Section 13(3)).

Table of Contents

1. What Is the DPDPA and Who Must Comply?
2. Entity Glossary
3. Core Data Fiduciary Obligations Under Sections 5–9
4. Significant Data Fiduciary: Additional Obligations
5. What Are the DPDPA Penalties for Non-Compliance?
6. Technical Safeguards: Rule 6 and Section 8(5)
7. DPDPA vs. GDPR: Key Structural Differences
8. Six-Step DPDPA Compliance Roadmap
9. FAQ

What Is the DPDPA and Who Must Comply?

The Digital Personal Data Protection Act, 2023 (DPDPA) is India's first comprehensive data protection statute, establishing a legal framework for the processing of digital personal data. It applies to every organisation — Indian or foreign — that processes the personal data of individuals located in India.

Who is a Data Fiduciary? Under Section 2(i), any person who "alone or in conjunction with other persons determines the purpose and means of processing of personal data" is a Data Fiduciary. If your business decides why and how personal data is collected, you are a Data Fiduciary and subject to the full obligation stack under Sections 5–10.

Extraterritorial reach. Section 3(b) extends DPDPA to processing outside India when the processing is in connection with offering goods or services to Data Principals within India. A US SaaS company serving Indian customers is a Data Fiduciary and must comply.

What counts as personal data? Section 2(t) defines personal data as "any data about an individual who is identifiable by or in relation to such data." The Act sets no enumerated list of categories — name, email, device ID, behavioural telemetry, biometric template, and payment record are treated uniformly. This is the DPDPA compliance guide's most important structural point: there is no statutory "sensitive personal data" tier in the 2023 Act (it was removed from the 2019 PDP Bill). Section 9's extra protections apply to children (under 18) and, for verifiable consent, to persons with disability who have a lawful guardian.

Entity Glossary

Data Fiduciary — Any person who determines the purpose and means of processing personal data (S.2(i) DPDPA 2023). Analogous to "Data Controller" under GDPR.



Data Principal — The individual to whom the personal data relates. Where the individual is a child (under 18) or a person with disability, includes their parent or lawful guardian (S.2(j) DPDPA 2023). Analogous to "Data Subject" under GDPR.



Data Processor — Any person who processes personal data on behalf of a Data Fiduciary. Defined in S.2(k) DPDPA 2023; may be engaged only under a valid contract (S.8(2)). Processors cannot determine purpose or means; if they do, they become Fiduciaries for that workload.



Significant Data Fiduciary (SDF) — A Data Fiduciary notified by the Central Government under Section 10(1) based on data volume, sensitivity, risk to Data Principal rights, or national security considerations. Faces additional obligations: India-based DPO, independent data auditor, and an annual DPIA and audit (S.10(2); Rule 13(1)).



Legitimate Use — Processing of personal data without consent, for purposes enumerated in Section 7 (state service delivery, employment, emergency response, voluntary data provision, etc.). Analogous to Article 6 lawful bases under GDPR, excluding consent.

Core Data Fiduciary Obligations Under Sections 5–9

Notice Before or at the Point of Collection (Section 5)

Every request for consent must be accompanied or preceded by a Notice stating: (a) the personal data and the purpose for which it is proposed to be processed; (b) how the Data Principal may withdraw consent (S.6(4)) and seek grievance redressal (S.13); and (c) how she may complain to the Board (S.5(1)). Rule 3 of the DPDP Rules 2025 adds that the Notice must stand on its own, itemise the personal data, and give a link for withdrawing consent and exercising rights.

The Data Principal must be given the option to read the Notice in English or any language in the Eighth Schedule to the Constitution (S.5(3)). This has a direct engineering implication: your consent flow must support multilingual notice delivery — hardcoded English-only notice strings fail Section 5.

Consent Architecture (Section 6)

Section 6 sets the consent standard: free, specific, informed, unconditional, unambiguous, and given by a clear affirmative action. Pre-ticked checkboxes, bundled consents, and consent buried in Terms & Conditions do not meet this standard.

Critically, Section 6(4) requires that consent must be as easy to withdraw as it was to give. An opt-in toggle paired with a buried multi-step withdrawal form is non-compliant. Engineers building consent flows must implement symmetric withdrawal: the same UX depth, the same number of steps.

For technical implementation patterns, see our guide on building a DPDPA-compliant consent management API.

Legitimate Use Without Consent (Section 7)

Consent is not the only lawful basis. Section 7 lists nine "certain legitimate uses" (clauses (a)–(i)) where processing does not require consent:

1. Personal data the Data Principal voluntarily provided for a specified purpose, where she has not indicated that she does not consent (7(a))
2. The State issuing a subsidy, benefit, service, certificate, licence or permit (7(b))
3. The State performing a function under law, or in the interest of sovereignty, integrity or security (7(c))
4. Fulfilling a legal obligation to disclose information to the State (7(d))
5. Compliance with a judgment, decree or order (7(e))
6. Responding to a medical emergency (7(f))
7. Medical treatment or health services during an epidemic or other threat to public health (7(g))
8. Safety measures during a disaster or breakdown of public order (7(h))
9. Employment purposes, or safeguarding the employer from loss or liability (7(i))

There is no general "performance of a contract" ground: commercial processing outside these uses needs consent. The Section 5 Notice attaches to a request for consent, so it is not triggered by a legitimate use, but every Section 8 obligation (security, breach intimation, erasure, grievance redressal) still applies.

Children's Data (Section 9)

Section 9 imposes heightened obligations for processing the personal data of children (persons under 18), and its verifiable-consent requirement also covers persons with disability who have a lawful guardian. A Data Fiduciary must:

• Obtain verifiable consent of the parent (or lawful guardian) before processing (S.9(1); Rules 10 and 11 set the verification steps)
• Not undertake processing likely to cause any detrimental effect on the well-being of a child (S.9(2))
• Not undertake tracking or behavioural monitoring of children (S.9(3))
• Not undertake targeted advertising directed at children (S.9(3))

The DPDP Rules exempt listed classes of Data Fiduciary (health, education, crèche, child transport) and listed purposes from S.9(1) and 9(3), subject to conditions (Fourth Schedule).

This is the only part of the Act that singles out a class of Data Principal for extra protection. It does not create a category for adults' financial, health, or biometric data.

Reasonable Security Safeguards (Section 8(5))

"A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach." — Section 8(5), DPDPA 2023

This is the master security obligation in the Act. Every technical control required by Rule 6 of the DPDP Rules 2025 flows from it. Critically, Section 8(5) extends to data processed by your vendors: if a Data Processor you engage suffers a breach, you remain liable.

Rule 6(1) lists the minimum safeguards: encryption, obfuscation, masking or virtual tokens mapped to the personal data; access control over the computer resources you and your Data Processors use; logs, monitoring and review to detect, investigate and remediate unauthorised access; backups for continued processing; one-year retention of those logs and personal data; security clauses in Data Processor contracts; and technical and organisational measures to make the safeguards effective. It names no algorithm or key length. See our encryption requirements guide for how we translate Rule 6(1)(a) into concrete cryptographic choices.

Breach Notification (Section 8(6))

In the event of a personal data breach (S.2(u)), the Data Fiduciary must give the Board and each affected Data Principal intimation of the breach (S.8(6)). Rule 7 of the DPDP Rules 2025 sets two clocks: (a) without delay, intimate every affected Data Principal (Rule 7(1)) and send the Data Protection Board of India an initial description of the breach, its nature, extent, timing, location and likely impact (Rule 7(2)(a)); and (b) within 72 hours of becoming aware, send the Board a detailed report covering updated details, the facts and reasons behind the breach, mitigation measures, any findings on who caused it, remedial measures, and a report on the intimations given to Data Principals, unless the Board allows longer on a written request (Rule 7(2)(b)). The Data Principal intimation must describe the breach, its likely consequences for her, the mitigation measures taken, the safety steps she can take, and a business contact who can answer her queries (Rule 7(1)(a)–(e)).

For operational automation of this workflow — SIEM integration, Board submission templates, and multi-language notification pipelines — see automating DPDPA breach notification from SIEM to the Board.

Data Erasure (Section 8(7))

Unless retention is necessary for compliance with law, the Data Fiduciary must erase personal data when the Data Principal withdraws consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier, and must cause its Data Processors to erase it too (S.8(7)). This applies to backup copies, staging environments, and analytics snapshots — not just the primary database.

Important retention nuance: Section 8(7) sets no numeric period. The DPDP Rules add two one-year minimums: Rule 6(1)(e) (logs and personal data kept for detecting and investigating unauthorised access) and Rule 8(3) (personal data, traffic data and processing logs kept for at least one year from processing, for the Seventh Schedule purposes). Rule 8(1)–(2) and the Third Schedule add a ceiling for large e-commerce, online-gaming and social-media platforms: erase after three years of inactivity, with at least 48 hours' warning. The commonly cited "7-year retention requirement" comes from SEBI, RBI, and the IT Act — not DPDPA. Always identify the actual sectoral law before configuring retention policies.

Data Processor Accountability (Sections 8(1)–8(2))

The Data Fiduciary is responsible for compliance in respect of any processing undertaken on its behalf by a Data Processor (S.8(1)), and may engage a Data Processor only under a valid contract (S.8(2)); Rule 6(1)(f) requires that contract to provide for reasonable security safeguards. If your cloud provider, analytics vendor, or SaaS platform mishandles personal data, the regulatory consequence falls on you. Every Data Processing Agreement must: name DPDPA S.8(2) explicitly; require breach notification back to you within your Board notification SLA; and grant you the right to audit.

Significant Data Fiduciary: Additional Obligations

The Central Government may classify a Data Fiduciary as a Significant Data Fiduciary (SDF) under Section 10(1) based on: volume and sensitivity of data processed; risk to rights of Data Principals; potential impact on national security, sovereignty, or electoral democracy; or risk to public order.

An SDF must comply with three obligations beyond the standard stack (S.10(2)):

1. Appoint a Data Protection Officer (DPO) based in India — an individual who represents the SDF under the Act, is responsible to its Board of Directors or similar governing body, and is the point of contact for the grievance redressal mechanism (S.10(2)(a)).
2. Appoint an independent data auditor — to carry out a data audit evaluating the SDF's compliance with the Act (S.10(2)(b)).
3. Conduct periodic Data Protection Impact Assessments (DPIAs) and periodic data audits (S.10(2)(c)). Rule 13(1)–(2) makes both annual, counted from the date of notification as an SDF, and requires a report of significant observations to be furnished to the Board.

Rule 13 adds two more: due diligence that algorithmic software used to process personal data is not likely to pose a risk to Data Principals' rights (Rule 13(3)), and keeping personal data specified by the Central Government, with its traffic data, inside India (Rule 13(4)).

No public SDF list has been notified as of October 2026. Classification will occur through official Central Government notification.

What Are the DPDPA Penalties for Non-Compliance?

DPDPA financial penalties are set per contravention — not per affected individual — in the Schedule to the Act (Section 33(1)). The maximum ceiling for failing to take reasonable security safeguards (Section 8(5)) is ₹250 crore (~USD 26 million). Penalties are imposed by the Data Protection Board after an inquiry finds the breach significant and the person has been heard (Section 33(1)); courts do not impose fines directly.

The per-contravention model means a single breach incident can trigger multiple penalty counts: one for failing to prevent it (S.8(5)) and a separate count for failing to notify (S.8(6)).

Technical Safeguards: Rule 6 and Section 8(5)

Section 8(5) requires "reasonable security safeguards to prevent personal data breach" — but it is Rule 6 of the DPDP Rules 2025 that names the minimum controls. Rule 6 is the text that engineering teams should implement against. It names control types, not algorithms or key lengths.

If your organisation already holds ISO 27001:2022 certification, you have significant coverage:

The three DPDPA obligations with no clean framework equivalent that constitute net-new investments for most organisations:

1. Consent-withdrawal parity (S.6(4)) — no ISO or SOC 2 control mandates symmetric withdrawal UX
2. Board and Data Principal breach notification workflow (S.8(6)) — existing IR runbooks notify customers; the Board notification path and Data Principal template are new
3. Cross-border negative-list enforcement (S.16) — neither ISO A.5.14 nor any SOC 2 criterion models a government-maintained country blocklist with default-permissive semantics

For a deep-dive on building Zero Trust Architecture as a DPDPA compliance enabler covering least-privilege at the network, workload, and identity layers — which maps directly to the Rule 6(1)(b) access control requirement.

DPDPA vs. GDPR: Key Structural Differences

Organisations already compliant with GDPR often assume DPDPA is materially similar. The structural differences below are the most consequential.

For a detailed technical comparison of cross-border transfer obligations, see our GDPR SCCs vs. India's DPDPA cross-border transfer rules analysis.

Six-Step DPDPA Compliance Roadmap

Use this ordered checklist as your implementation plan. Each step maps to a specific obligation set and can be assigned to a team owner.

1. Classify — Determine your legal role under Sections 2 and 10. Identify every processing activity and assign it to a legal entity. Determine whether your organisation is a Data Fiduciary, Data Processor, or both. Assess whether any processing workload may trigger Significant Data Fiduciary classification under Section 10(1).
2. Map — Inventory all personal data flows and assign lawful grounds. For every collection point, document: (a) what personal data is collected; (b) the purpose; (c) the lawful ground under Section 4 (consent or a legitimate use under Section 7); and (d) where the data flows to and which Data Processors handle it.
3. Notice and Consent — Implement a compliant consent and Notice mechanism. Redesign consent flows to meet Section 6: per-purpose granularity, affirmative opt-in, no pre-ticked checkboxes, and symmetric withdrawal (as easy to withdraw as to give). Deploy the Section 5 Notice before or with every consent request, with the option to read it in English or any Eighth Schedule language (S.5(3)).
4. Secure — Deploy technical and organisational safeguards under Section 8(5) and Rule 6. Implement encryption at rest (AES-256-GCM minimum) and in transit (TLS 1.2+), least-privilege access controls with MFA, pseudonymisation for non-production data, and a vulnerability assessment and penetration testing (VAPT) cadence. Update ISO 27001 Statement of Applicability or SOC 2 scope to explicitly reference DPDPA S.8(5).
5. Respond — Build breach notification and grievance redressal workflows. Wire your SIEM alert pipeline to a breach intimation workflow (Section 8(6), Rule 7): "without delay" to affected Data Principals and the Board, then the detailed Board report within 72 hours (Rule 7(2)(b)). Implement a Data Subject Request (DSR) portal covering access, correction, erasure, and grievance rights under Sections 11–13. Appoint and publish a Grievance Officer with an SLA inside the Rule 14(3) limit (a reasonable period not exceeding 90 days).
6. Govern — Establish a data retention and erasure policy, and update vendor contracts. Implement retention schedules keyed to "purpose fulfilled" under Section 8(7) (respecting the one-year minimum in Rules 6(1)(e) and 8(3), and checking sectoral floors for finance, healthcare, and telecom). Update every Data Processing Agreement to cite DPDPA S.8(2) and require back-notification within your Board SLA. Periodically review the Section 16 cross-border transfer posture against the Central Government's country notification list (default: all transfers permitted until a restriction is published).

For a comprehensive mapping of DPDPA obligations to ISO 27001:2022 Annex A controls, see our DPDPA to ISO 27001 mapping guide.

FAQ

Does DPDPA apply to foreign companies processing Indian data?

Yes. Section 3(b) extends DPDPA extraterritorially to any entity processing digital personal data outside India in connection with offering goods or services to Data Principals located within India. A US SaaS platform, European analytics vendor, or Singapore-based cloud service with Indian customers is a Data Fiduciary under DPDPA and must implement the full obligation stack — including Section 8(5) safeguards, Section 8(6) breach notification, and Section 11–13 rights fulfilment.

Is there a sensitive personal data category under DPDPA?

No — and this is the most common misconception inherited from the 2019 Personal Data Protection Bill. DPDPA 2023 has no statutory sensitive personal data category. Financial records, health data, and biometric data of adults are governed by the same Section 8(5) obligation as any other personal data. Section 9 applies only to children (persons under 18) and, for verifiable consent, to persons with disability who have a lawful guardian. Compliance programmes modelled on GDPR Article 9 will over-engineer adult personal data protection for the wrong reasons.

What are the DPDPA penalty tiers and how are they calculated?

Penalties are assessed per contravention by the Data Protection Board, not per affected individual, once an inquiry finds a breach significant (S.33(1)). The Schedule to the Act sets these maximums: ₹250 crore for failing to take reasonable security safeguards to prevent a personal data breach (S.8(5)); ₹200 crore for failing to give the Board or affected Data Principals intimation of a breach (S.8(6)); ₹200 crore for breaching the additional obligations for children (S.9); ₹150 crore for breaching the additional obligations of Significant Data Fiduciaries (S.10); ₹10,000 for a Data Principal breaching her duties (S.15); for breaching a voluntary undertaking, up to the penalty for the original breach (S.32); and ₹50 crore for breaching any other provision, which includes Data Principal rights obligations. The Board weighs factors such as the gravity, duration and repetition of the breach and any mitigation (S.33(2)). A single breach incident can trigger multiple contravention counts.

Does DPDPA require data to be stored in India?

No. DPDPA Section 16 imposes no data localisation requirement. Cross-border transfers are permitted by default under a negative-list model: the Central Government may restrict transfers to specific countries by official notification, but no such restriction list has been published as of October 2026. Cloud workloads running on AWS, Azure, or GCP outside India are permissible unless and until the Government restricts a specific jurisdiction. Two caveats: Section 16(2) preserves any other Indian law that provides a higher degree of protection for, or restriction on, transfer of personal data outside India (check your sector regulator), and Rule 13(4) lets the Government require Significant Data Fiduciaries to keep specified personal data inside India. This is the opposite direction from GDPR, which requires a positive adequacy mechanism before transfer.

What is a Significant Data Fiduciary and does my business qualify?

The Central Government classifies Data Fiduciaries as Significant (SDF) under Section 10(1) based on volume and sensitivity of data processed, risk to the rights of Data Principals, and potential impact on sovereignty, security, or electoral democracy. No public SDF classification list has been notified as of October 2026. Classification is expected via official Government notification. Organisations that process data at scale in regulated sectors (fintech, healthtech, large e-commerce) should prepare for possible SDF designation by documenting processing scope and conducting a preliminary DPIA readiness assessment.

When does DPDPA enforcement begin?

The DPDPA was enacted and received Presidential assent in August 2023. The DPDP Rules 2025 were notified on 13 November 2025 (G.S.R. 846(E); the January 2025 text was only a draft), and the Act's commencement was notified the same day (G.S.R. 843(E)). Commencement is phased in three stages:

• 13 November 2025: definitions and the Data Protection Board provisions (Act S.2, S.18–26; Rules 1, 2, 17–21).
• 13 November 2026: Consent Manager registration (Act S.6(9); Rule 4).
• 13 May 2027: the core obligations — notice, consent, legitimate uses, security safeguards, breach intimation, retention and erasure, children's data, SDF duties, Data Principal rights, cross-border transfer and penalties (Act S.3–5, S.6(1)–(8) and (10), S.7–17, S.27 except 27(1)(d), S.28–34; Rules 3, 5–16, 22, 23).

Organisations should treat the period until 13 May 2027 as an active compliance build window rather than a waiting period.

Start Your DPDPA Compliance Readiness Assessment

The six-step roadmap above covers the obligation architecture. Translating it into a gap assessment for your specific technology stack — AWS workloads, SaaS vendor inventory, consent API, SIEM pipeline — requires mapping your current controls against DPDPA Section 8(5) and Rule 6 specifically.

StateCheck Security's DPDPA Readiness Assessment benchmarks your current state across all six obligation areas, identifies net-new controls versus ISO/SOC 2 gaps, and produces an actionable remediation plan with owner assignments and SLAs.

Book your DPDPA Readiness Assessment →