Why India's DPDP Act 2023 Matters: Data Breach Management and Customer Trust

Key Takeaways

• The DPDP Act 2023 imposes up to ₹250 crore in penalties for failure to implement security safeguards under Section 8(5) — the highest single ceiling in the Act — and a separate ₹200 crore ceiling for failure to notify the Data Protection Board and affected Data Principals of a breach.
• Breach intimation under Rule 7 of the DPDP Rules 2025 runs on two clocks: each affected Data Principal and the Board must be told "without delay" (Rule 7(1), Rule 7(2)(a)), and a detailed report must reach the Board within 72 hours of becoming aware (Rule 7(2)(b)), extendable only if the Board allows on a written request. Rule 7 applies from 13 May 2027.
• Every Data Fiduciary remains liable for breaches caused by its Data Processors. Section 8(5) explicitly extends the security obligation to "any processing undertaken by it or on its behalf by a Data Processor."
• DPDPA has no "sensitive personal data" statutory category. Financial, health, and biometric data of adults are governed by the same Section 8(5) obligation as any other personal data. Section 9 applies exclusively to children under 18.
• Customer trust is not a soft output — Rule 14(3) requires you to publish a grievance response period of no more than 90 days, and to meet it. A Data Principal who has exhausted that mechanism can complain to the Board (Section 13(3), Section 27(1)(b)), independently of any breach.
• A breach intimation under Section 8(6) is itself a trigger: the Board can direct remedial measures, inquire and impose penalty on receipt of it (Section 27(1)(a)), with no complaint needed. Audit log retention, SIEM evidence packaging, and a Board escalation runbook are engineering deliverables — not governance afterthoughts.

Table of Contents

1. What Does the DPDP Act 2023 Require of Indian Businesses?
2. Key Terms
3. What is a Personal Data Breach Under DPDPA?
4. Security Safeguards Under Section 8(5): What Data Fiduciaries Must Implement
5. Personal Data Breach Intimation Under Rule 7
6. What Are the Financial Penalties Under the DPDP Act 2023?
7. Vendor Accountability: Data Processor Contracts Under Section 8(2)
8. Data Principal Rights and Customer Trust
9. Board Inquiry Readiness: What Engineering Teams Must Prepare
10. FAQ

What Does the DPDP Act 2023 Require of Indian Businesses?

India's Digital Personal Data Protection Act, 2023 (DPDPA) establishes a legally enforceable framework for the protection of digital personal data. Before the DPDPA, data protection in India was governed by Section 43A of the Information Technology Act, 2000 and the 2011 SPDI Rules — a patchwork that imposed compensation liability without criminal penalties and relied on voluntary ISO 27001 adoption. The DPDPA replaces that with an obligation-and-penalty architecture that covers every organisation that processes the digital personal data of individuals located in India.

Who must comply with the DPDP Act 2023? Section 3 sets the scope:

• Any organisation processing digital personal data within India (whether collected digitally or paper-collected and later digitised)
• Any foreign organisation processing digital personal data outside India in connection with offering goods or services to Data Principals within India — extraterritorial reach under Section 3(b)

The entity bearing primary compliance obligations is the Data Fiduciary: any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data (Section 2(i)). If your business decides why personal data is collected and how it is processed, you are a Data Fiduciary.

For the full DPDPA compliance roadmap for businesses — including consent obligations, Data Principal rights, and the complete penalty schedule — start with the executive compliance guide.

Key Terms

Data Fiduciary — Any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data (Section 2(i)). Equivalent to "Data Controller" under GDPR. Bears the primary liability stack.



Data Processor — Any person who processes personal data on behalf of a Data Fiduciary; the engagement must be under a valid contract (Section 8(2)), and the definition is in Section 2(k). Regulatory liability for breaches remains with the Fiduciary, not the Processor (Section 8(1)).



Personal Data Breach — Any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data that compromises confidentiality, integrity, or availability (Section 2(u)).



Data Protection Board of India — The adjudicatory body established under Section 18 to inquire into contraventions (Section 27), impose penalties (Section 33 and the Schedule), and direct remedial measures.



Significant Data Fiduciary (SDF) — A Data Fiduciary notified by the Central Government under Section 10(1). Faces additional obligations under Section 10(2) and Rule 13: an India-based DPO, an independent data auditor, and a DPIA and audit every 12 months.

What is a Personal Data Breach Under DPDPA?

Section 2(u) defines a personal data breach as:

"any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data" — Section 2(u), DPDPA 2023

Three things make this definition broader than most organisations expect.

First, the CIA triad is the trigger. Any event that undermines confidentiality, integrity, or availability of personal data is a breach — not just confirmed exfiltration. A ransomware event that encrypts personal data (loss of availability) is a breach under Section 2(u) even if no data left your network. A misconfigured S3 bucket that exposes personal data to the internet is a breach even if you catch it before any attacker reads it. An accidental email to the wrong recipient that contains personal data is a breach.

Second, "unauthorised processing" is broad. Section 2(x) defines "processing" to include collection, recording, organisation, structuring, storage, retrieval, use, sharing, disclosure, erasure, and destruction. Processing personal data without a lawful ground is arguably itself unauthorised — a shadow database of user data collected without consent can fall within Section 2(u) before a security incident occurs.

Third, there is no severity threshold — in the definition or in the intimation duty. Section 8(6) requires intimation "in the event of a personal data breach", and Rule 7 requires it "on becoming aware of any personal data breach". Neither sets a materiality or risk threshold of the kind GDPR Article 33 has. As written, the Rules set no threshold, so design the pipeline to intimate every confirmed personal data breach. Impact assessment shapes the content of the intimation, not whether one is sent.

Security Safeguards Under Section 8(5): What Data Fiduciaries Must Implement

Section 8(5) is the master security obligation of the DPDPA:

"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

Two clauses require attention. First, "reasonable security safeguards to prevent personal data breach" — the duty is preventive, and Rule 6 makes clear it is both a technical and a governance obligation (its last clause requires "appropriate technical and organisational measures"), not just an IT control requirement. Second, "including in respect of any processing undertaken by it or on its behalf by a Data Processor" — Section 8(5)'s security obligation explicitly extends to your vendors. If a Data Processor you engage suffers a breach, you remain liable under Section 8(5).

Rule 6(1) of the DPDP Rules 2025 (in force from 13 May 2027) operationalises Section 8(5) with seven minimum safeguards:

Organisations already holding ISO 27001:2022 certification can map DPDPA Section 8(5) to ISO 27001 Annex A controls to identify the residual gaps. For encryption and the other data security measures listed in Rule 6(1)(a) — AES-256-GCM, TLS 1.3, and key rotation as implementation choices — see the technical deep-dive.

What Rule 6 does NOT do: It does not mandate a specific cipher suite by name, or even encryption specifically (encryption is one of four listed examples). It does not mention ISO 27001. It does not set a VAPT frequency. It sets minimums ("at the minimum") and leaves the choice of controls to what is "reasonable" and "appropriate". In practice, a defensible 2026 benchmark is AES-256 and TLS 1.3 for encryption, RBAC/ABAC with MFA for access control, and structured access event logging — these are our engineering recommendations, not Rule text.

Personal Data Breach Intimation Under Rule 7

When a personal data breach occurs, Section 8(6) triggers a mandatory dual intimation obligation: the Data Fiduciary "shall give the Board and each affected Data Principal, intimation of such breach in such form and manner as may be prescribed." Rule 7 of the DPDP Rules 2025 prescribes that form and manner. It applies from 13 May 2027.

Rule 7 sets three requirements on two clocks:

1. Data Principal intimation — "without delay" (Rule 7(1)). On becoming aware of any personal data breach, the Data Fiduciary must, to the best of its knowledge, intimate each affected Data Principal "in a concise, clear and plain manner and without delay", through her user account or any mode of communication she has registered with the Data Fiduciary. The intimation must cover:

• (a) a description of the breach, including its nature, extent and the timing of its occurrence
• (b) the consequences relevant to her that are likely to arise from the breach
• (c) the measures implemented and being implemented by the Data Fiduciary, if any, to mitigate risk
• (d) the safety measures she may take to protect her interests
• (e) business contact information of a person who can respond to her queries on behalf of the Data Fiduciary

2. Initial Board intimation — "without delay" (Rule 7(2)(a)). A description of the breach, including its nature, extent, timing and location of occurrence and the likely impact.

3. Detailed Board report — within 72 hours (Rule 7(2)(b)). Within seventy-two hours of becoming aware of the breach, or such longer period as the Board may allow on a request made in writing:

• (i) updated and detailed information in respect of the initial description
• (ii) the broad facts related to the events, circumstances and reasons leading to the breach
• (iii) measures implemented or proposed, if any, to mitigate risk
• (iv) any findings regarding the person who caused the breach
• (v) remedial measures taken to prevent recurrence
• (vi) a report regarding the intimations given to affected Data Principals

What this means operationally: both "without delay" clocks start when you become aware, and the detailed report clock is a hard 72 hours unless the Board grants an extension you asked for in writing. Note the wording: the notified Rules say "without delay"; the "undue" qualifier is GDPR's. The Rules provide no public-communication substitute for individual intimation — every affected Data Principal must be told.

Engineering the Notification Pipeline

The gap between "the law says intimate without delay" and "the intimation actually goes out in time" is an engineering problem:

Incident detected in SIEM
  → Correlation rule classifies event as Section 2(u) breach candidate
  → Incident ticket auto-created with Rule 7(2)(a) fields pre-populated (nature, extent, timing, location, likely impact)
  → Legal/DPO review gate (hard 4-hour internal SLA)
  → Initial Board intimation submitted (Rule 7(2)(a), without delay)
  → Data Principal intimations queued per Rule 7(1) template (via user account / registered channel)
  → Detailed Board report filed within 72 hours (Rule 7(2)(b)), or written extension request
  → Breach records kept with the security logs retained for one year (Rule 6(1)(e))

For the full automation architecture — SIEM integration, Board submission template, and multilingual Data Principal notification — see our guide to automating your SIEM-to-Board notification pipeline.

What Are the Financial Penalties Under the DPDP Act 2023?

DPDPA financial penalties are set per contravention — not per affected individual — under Section 33(1) and the Schedule to the Act. A single breach incident can attract multiple contravention counts: one for the underlying safeguard failure (Section 8(5)) and a separate count for the notification failure (Section 8(6)).

These are separate ceilings, one per provision breached. Whether a single incident can attract both the Section 8(5) and the Section 8(6) penalty has not been tested; the Board sets the amount within each ceiling under Section 33(2).

Before DPDPA: Section 43A of the IT Act imposed unlimited civil compensation liability. The 2011 SPDI Rules had no criminal penalty and were typically enforced through civil suits. The DPDPA replaces this with fixed administrative penalty ceilings enforced by a dedicated adjudicatory body.

Penalty quantum factors (Section 33(2)): The Board does not automatically impose the maximum. Section 33(2) lists seven matters it must have regard to, including the nature, gravity and duration of the breach; the type and nature of the personal data affected; whether the breach is repetitive; and whether the person took action to mitigate its effects, and "the timeliness and effectiveness of such action" (Section 33(2)(e)). A well-documented incident response — timestamped detection, Board intimation, containment steps — is the evidence you would put before the Board on Section 33(2)(e). Your SIEM audit trail is a penalty-mitigation artefact.

Vendor Accountability: Data Processor Contracts Under Section 8(2)

Section 8(1) makes the Data Fiduciary responsible for compliance "in respect of any processing undertaken by it or on its behalf by a Data Processor", and Section 8(2) allows a Data Processor to be engaged "only under a valid contract". Section 8(5) reinforces this by extending the security obligation to "any processing undertaken by it or on its behalf by a Data Processor."

The implication is unambiguous: if your cloud storage provider, SaaS analytics vendor, or offshore development partner causes a personal data breach, you — the Data Fiduciary — notify the Board and affected Data Principals. You face the Section 8(5) penalty exposure. The vendor's contractual breach gives you a civil claim against them, but it does not transfer regulatory liability.

Every Data Processing Agreement must therefore specify: (a) processing purpose and instruction scope; (b) the contractor's obligation to take reasonable security safeguards, which Rule 6(1)(f) requires the contract to provide for; (c) breach back-notification to the Fiduciary fast enough for it to meet Rule 7's "without delay" intimations and the 72-hour detailed report to the Board (Rule 7(2)(b)); (d) cooperation with Data Principal rights requests; and (e) the Fiduciary's right to audit compliance.

Data Principal Rights and Customer Trust

DPDPA's customer trust contribution is structural, not aspirational. The Act creates four enforceable Data Principal rights:

Section 11 — Right to access and information: A Data Principal can request a summary of the personal data being processed about them and the processing activities undertaken, plus the identities of other Data Fiduciaries and Data Processors it has been shared with. Rule 14(1)–(2) requires you to publish the means for making such requests and the identifiers needed; the notified Rules set no separate acknowledgment or fulfilment deadline for access requests.

Section 12 — Right to correction and erasure: A Data Principal can request correction, completion, updating, and erasure of her personal data. On an erasure request the Data Fiduciary must erase unless retention is necessary for the specified purpose or for compliance with law (Section 12(3)), and Section 8(7)(b) requires it to cause its Data Processors to erase data it made available to them.

Section 13 — Right to grievance redressal: Every Data Fiduciary must provide readily available means of grievance redressal (Section 13(1), Section 8(10)). Rule 14(3) requires you to publish, on your website or app, a reasonable grievance response period not exceeding 90 days, and to meet it. The Data Principal must exhaust this mechanism before approaching the Data Protection Board (Section 13(3)).

Section 14 — Right of nomination: A Data Principal may nominate another individual to exercise these rights on their behalf in the event of death or incapacity (Rule 14(4) covers the means).

Customer trust as a compliance metric: The grievance mechanism is not a "nice to have" — breach of the grievance and rights obligations falls under the Schedule's residual entry ("any other provision"), with penalties of up to ₹50 crore. Organisations that instrument their grievance portal with SLA tracking, automated acknowledgment, and escalation triggers have a measurable compliance posture. Those that rely on a static "contact us" email do not.

Board Inquiry Readiness: What Engineering Teams Must Prepare

The Data Protection Board's powers and procedure are set out in Sections 27–28. It acts on receipt of a breach intimation under Section 8(6), on a complaint by a Data Principal, on a reference from the Central or a State Government, or in compliance with a court's directions (Section 27(1)); it has civil-court powers to summon people and inspect data and documents (Section 28(7)); and it must complete an inquiry within six months, extendable by up to three months at a time (Rule 19(9)). Your own breach intimation is enough to open the file. When an inquiry opens, expect it to look for: evidence of the breach timeline, proof that the Rule 7 intimations went out without delay and the detailed report within 72 hours, documentation of the Section 8(5) and Rule 6 controls in place, and demonstration that affected Data Principals were intimated per Rule 7(1).

The gap most organisations have today: Incident response runbooks that produce the right internal artefacts (executive briefings, customer comms) but not the right regulatory artefacts (Rule 7(2)-structured Board intimation and detailed report, Data Principal intimation with Rule 7(1) content, logs retained under Rule 6(1)(e)). These are engineering-deliverable requirements.

Board inquiry readiness means:

1. Breach incident log: A structured record of every detected breach including nature, scope, affected data categories, timeline, notification status, and mitigation measures. Keep it with the logs and personal data that Rule 6(1)(e) requires you to retain for one year (longer where another law requires).
2. Rule 7(2) Board templates: Pre-approved templates for the initial intimation (Rule 7(2)(a): nature, extent, timing, location, likely impact) and the detailed report (the six items in Rule 7(2)(b)), reviewed by legal counsel before an incident occurs — not drafted during a breach response.
3. Data Principal notification pipeline: An automated dispatch system that reaches each user through her user account or registered communication mode (Rule 7(1)), pre-loaded with a template covering the five Rule 7(1) items, in English and, where you offer it, the user's chosen Eighth Schedule language.
4. SIEM evidence export: The ability to produce a structured timeline — first detection signal, confirmed breach classification, initial Board intimation timestamp, detailed report timestamp — as an inquiry submission artefact.

For the full SIEM-to-Board automation pipeline, see automating DPDPA breach notification from SIEM to the Data Protection Board.

FAQ

Does the DPDP Act 2023 require breach notification within 72 hours?

Partly — there are two clocks, and the 72-hour one is the later of the two. The Act itself sets no hour count; Rule 7 of the DPDP Rules 2025 does. On becoming aware of a breach, the Data Fiduciary must intimate each affected Data Principal and give the Board an initial description "without delay" (Rule 7(1) and Rule 7(2)(a)). It must then file a detailed report with the Board within 72 hours of becoming aware (Rule 7(2)(b)), unless the Board allows a longer period on a written request. So 72 hours is the outer limit for the detailed report, not a grace period for the first intimation. Rule 7 applies from 13 May 2027.

Does the DPDP Act 2023 treat financial and health data as "sensitive personal data" with stricter rules?

No — this is a persistent misconception inherited from the 2019 PDP Bill, which did contain a "sensitive personal data or information" (SPDI) category. The enacted DPDPA 2023 removed it entirely. Financial records, health data, and biometric data of adults are governed by the same Section 8(5) obligation as any other personal data. The only category-based elevation in the 2023 Act is Section 9, which applies exclusively to persons under 18 (and persons with disabilities who have a lawful guardian).

Is there a data localisation requirement under the DPDP Act 2023?

Not a blanket one. Section 16 uses a negative-list model: cross-border data transfers are permitted by default. The Central Government may restrict transfers to specific countries by official notification, but no country restrictions have been published as of October 2026. Rule 15 adds that transfers are subject to any requirements the Government specifies by order about making personal data available to a foreign State or its agencies.

The one localisation rule is for Significant Data Fiduciaries: Rule 13(4) requires them to keep personal data specified by the Central Government (on a committee's recommendation) in India. For other Data Fiduciaries, cloud workloads running outside India on AWS, Azure, or GCP are permissible unless and until the Government restricts the relevant jurisdiction.

Who is liable when a Data Processor causes a personal data breach?

The Data Fiduciary. Section 8(5) extends the security obligation to "any processing undertaken by it or on its behalf by a Data Processor" — a vendor-caused breach is still the Fiduciary's regulatory liability. The Fiduciary notifies the Board and affected Data Principals; the Fiduciary faces the penalty exposure under the Schedule to the Act. A contractual claim against the Processor may exist under the Data Processing Agreement, but it does not transfer regulatory accountability to the Processor.

What must a breach notification to the Data Protection Board contain?

Two submissions, under Rule 7(2). The initial intimation, sent without delay, is a description of the breach including its nature, extent, timing and location of occurrence and the likely impact (Rule 7(2)(a)). The detailed report, due within 72 hours of becoming aware unless the Board allows longer on a written request, adds six items (Rule 7(2)(b)): updated and detailed information on that description; the broad facts on the events, circumstances and reasons leading to the breach; mitigation measures implemented or proposed; any findings about the person who caused the breach; remedial measures to prevent recurrence; and a report on the intimations given to affected Data Principals. Organisations without pre-approved Rule 7(2) templates will draft them under breach-response pressure — a significant operational risk.

What is the maximum financial penalty for a personal data breach under the DPDPA?

Two separate penalty ceilings apply. Under the Schedule to the Act (Section 33(1)): Section 8(5) failure (inadequate security safeguards) carries a maximum of ₹250 crore per contravention; Section 8(6) failure (failing to notify the Board and Data Principals) carries a maximum of ₹200 crore per contravention. Whether both can be imposed for the same incident is untested. Penalties are per contravention, not per affected individual. The Data Protection Board determines the quantum within the ceiling by applying the Section 33(2) factors.

Make DPDPA Compliance an Operational Advantage

The DPDP Act 2023 transforms data protection from a cost centre into a customer trust driver — but only for organisations that implement it operationally, not bureaucratically. The Section 8(5) safeguards, the Rule 7 breach intimation pipeline, and the Section 13 grievance mechanism are engineering deliverables that directly reduce breach probability, regulatory exposure, and customer churn.

StateCheck Security works with Data Fiduciaries across India to translate DPDPA obligations into engineering-ready specifications — Section 8(5) and Rule 6 control architecture, Rule 7 breach intimation automation, Data Principal rights portal design, and Board inquiry readiness assessments.

Contact StateCheck Security → to discuss your DPDPA implementation posture.