Chapter 16 — Personal-Data Breach Detection and Response

1. The quietest crisis in compliance

There is a moment in every privacy programme that nobody rehearses until it is too late: the moment someone discovers that customer data has leaked, been lost, or become accessible to a party that should never have seen it. In that moment — often at 2 a.m., often caught by an alarm rather than by design — an organisation learns whether everything it built in the preceding months was real or ornamental.

That moment is a personal data breach. And the reason breach response deserves a chapter of its own is not an assertion about incident frequency; it is that the definition of a breach is far wider than most people assume, and the consequences of mishandling the definition are disproportionately severe. A team that treats “breach” as a synonym for “data stolen by a hacker” can miss covered events, and that miss carries its own, separate penalty exposure.

So this chapter begins not with the incident-response playbook you already have in your security team’s drawer, but with the definition — because everything that follows depends on how honestly an organisation answers the first, uncomfortable question: is this an event the law calls a personal data breach?

2. What the law actually means by “personal data breach”

The Digital Personal Data Protection Act defines personal data breach in Section 2(u). The following quotation is transcribed from ACT:115–118, with whitespace normalised.[1]

“personal data breach” means 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.

Let us sit with that definition, because three things about it are counterintuitive and each one reshapes the whole response problem.

First, a breach is not limited to a cyberattack. Accidental loss of access or destruction can compromise availability even without exfiltration. But a routine interruption or an unwiped device is not automatically a concluded breach solely from that label. Record the personal data, processing or accidental event, and how confidentiality, integrity or availability was actually compromised. A failed restoration of the only usable records is a different fact pattern from an alarm during a successful failover. ACT:115–118.[1]

Second, unauthorised processing is wider than theft. An analyst using customer records outside lawful authority may compromise confidentiality. A disclosure to an external recipient may be authorised, however; externality or absence of a recipient’s name on one screen does not alone decide the breach. Review the actual authority and facts. A public object-read policy can compromise confidentiality without proof of a hostile download, while public listing and object reading are separate permissions. The incident specimen records each separately.

Third, classification and notification are separate but not a severity escape. First establish whether Section 2(u) is met, then applicability, awareness and recipients. Within applicable Section 8(6)/Rule 7, awareness of any personal-data breach triggers notice to each affected principal and the Board. Severity determines response priority and content, not a risk-of-harm threshold that the retained rule does not state. ACT:348–350; RULES:1112–1139.[1][5]

Why does this matter so much? Because an organisation that defines “breach” too narrowly will silently talk itself out of reporting events the law expects to be reported — and the law has built a specific, heavy consequence for exactly that silence. We will come to that in §4. But first we have to hold the harder tension: the definition is wide, and getting the classification wrong in either direction is dangerous.

3. The tension in the middle of the room

A breach drill should expose the tension this chapter is about. It is not a tension between “good” and “bad” people. It is a tension built into the law itself, and it sits at the exact point where the organisation must act fastest.

On one side stands the silence failure: a confirmed breach is talked down because no download log or final attribution exists. Missing logs do not prove absence of access. A ₹200 crore notification ceiling is not an automatic bill, but failing a required notice is a separate issue from the underlying safeguard failure. ACT:1019–1025.[1]

On the other side stands the classification-noise failure: every alert is labelled a breach before anyone determines whether personal data or CIA compromise is involved. An authorised test or transient health alert may be a false positive. Prompt triage is necessary; it is not permission to suppress a low-impact confirmed breach. The operational distinction is between unsubstantiated alerts and established in-scope breaches, not between important and unimportant people.

The slogan “when in doubt, report” does not resolve this. It merely hands the doubt to the Board. Resolving the tension requires something more mechanical and more honest: an engineered classification gate — a consistent, evidence-producing routine that makes both errors visible, and that gives a named human the authority and the record to decide. That is the insight at the centre of this chapter, and it is worth stating plainly:

The insight. Detection and investigation need their own engineering. This chapter concentrates on disciplined classification under time pressure — a defensible decision about whether Section 2(u) is met, reached quickly, recorded in a way that can later stand up in an inquiry, and followed by the right notification to the right recipients on the right clocks.

Everything that follows — the obligations, the response model, the tests, the drill — exists to make that classification skill real rather than aspirational.

4. The duties the law places on a fiduciary

Before designing the response model, we fix the legal frame. A personal data breach engages two related but distinct obligations, and keeping them separate matters because they carry different exposures.

4.1 Prevent: reasonable security safeguards (Section 8(5))

A Data Fiduciary must protect personal data in its possession or control — including data processed on its behalf by a Data Processor — by taking reasonable security safeguards to prevent personal data breach. This is the companion to Chapter 15’s security chapter, and it anchors the duty to take reasonable safeguards, informed by actual data and circumstances rather than effort alone. The failure of this duty — a breach suffered because safeguards were not reasonable — is the ₹250 crore exposure in Schedule item 1.

4.2 Intimate: notify the Board and each affected principal (Section 8(6))

In the event of a personal data breach, the Data Fiduciary must give the Board and each affected Data Principal an intimation of the breach, in the form and manner prescribed (Rule 7). The failure of this duty is the ₹200 crore exposure in Schedule item 2.

4.3 Trigger, recipients, content and clocks — Rule 7

These are verified source requirements, not internal SLA choices. The seventy-two-hour clock does not delay either initial notice. A written extension request alone changes no deadline; preserve the Board’s allowance before using a longer deadline. The extension concerns the detailed Board update, not the initial or principal notices. RULES:1112–1139.[5]

The Company’s recommended awareness policy captures occurrence, detector alert, facts then available, when relevant personnel became aware and who recorded the assessment. The clock cannot be postponed until counsel signs a form, a committee meets or forensics closes. Where earlier evidence already establishes awareness, correct the recorded time and deadlines rather than retain a convenient later timestamp. Investigation and recipient resolution proceed in parallel with containment and initial notices.

The packet uses a twenty-minute awareness-to-initial-preparation interval as a hypothetical exercise parameter, not a statutory safe window or proof of “without delay”. The reviewer must assess what could reasonably have been sent earlier, why the interval occurred and which facts were still unknown. A prepared draft is not a transmitted notice, and a mail provider’s acceptance is not proof that every principal received it.

4.4 A parallel obligation the playbook cannot ignore: other clocks

It would be an error to read this chapter as if the Data Protection Board were the only recipient in India. As Chapter 5 argued, an Indian enterprise faces parallel regulators running on their own clocks — CERT-In incident reporting, and for banking, insurance, securities and health, sector reporting windows that do not wait for the DPDP notification. The response model below therefore treats “notify” as plural: the Board, the affected principals, and any sector regulator whose duty is also triggered. Each recipient gets what that recipient is owed, on that recipient’s clock, with its own record. Collapsing them into “one report” is exactly the flattening error Chapter 5 warned against.

5. The response model: a lifecycle, not a procedure

Incident response is often taught as a set of steps. In practice the steps happen almost simultaneously, loop back on each other, and are held together by one thing: an evidence record that survives the panic. The lifecycle below is the shape of that record.

detect
  → assess and classify (the s.2(u) gate)
  → contain and mitigate
  → notify (parallel clocks)
  → record and evidence
  → remediate
  → learn

5.1 Detect

Because Section 2(u) is broad, detection must span more than an intrusion-detection system. It should watch for, at minimum:

• technical intrusion and malware signals, from the network-security estate (Ch.15);
• data-exfiltration signals — bulk exports, unusual egress patterns, a sudden spike in downloads of a restricted dataset;
• misconfiguration and unauthorised-processing signals — a storage bucket changed visibility, a service querying data without a purpose (linking to Ch.8), a contract-less processor accessing data (linking to Ch.17);
• availability signals — a failed restore, a lost encryption key, a storage subsystem that loses access;
• disclosure signals — a mistaken email attachment, a misdirected physical post, a vendor who reports they “may have” been exposed.

Each of these is a thread that may or may not end in a breach; the detection layer’s job is to pull the threads, not to pre-judge them.

5.2 Assess and classify — the gate

This is the heart of the matter, and it deserves its own discipline. The classification gate answers two questions in a fixed order.

Question one: is it a personal data breach under Section 2(u)? Was confidentiality, integrity, or availability compromised for personal data? Answer this from the definition alone, not from convenience. If any of the three was compromised, the first question answers yes.

Question two: is notification required, and to whom, by when? Only after question one is answered does the second question arise. It is governed by Rule 7 (the form, manner and time-window for Board and principal notification) and by any sector parallel clock. Question two establishes applicable tracks and recipients; it does not invent a severity threshold for Rule 7.

The gate’s output is a decision record: the facts found, the definitional reasoning, the person making the call, the timestamp, and the resulting notification decisions. That record is not bureaucracy. It is the mitigation evidence that a Board inquiry will weigh under Section 33(2)(e) — whether action to mitigate effects and consequences was timely and effective, among the specified factors (ACT:834–846).[1] A missing record weakens evidence; this book does not predict how an inquiry will weigh it.

5.3 Contain and mitigate

Stop the bleeding while preserving evidence. The actions taken here — and when they were taken — are the material of Section 33(2)(e). Every containment action (closing a bucket, revoking a key, isolating a segment, notifying an affected vendor) should be logged with a timestamp, without claiming mitigation outranks the other statutory factors.

5.4 Notify — the plural clock

Notify the Board and each affected principal in the Rule 7 form, manner and time-window; notify any sector regulator on its own clock. This step is a produced artifact — a notification that was actually sent, recorded, and timestamped — not a decision that lives on a whiteboard. Transmission and recipient evidence support the account of discharge; a specimen or queued job does not establish it.

5.5 Record and evidence

Every step lands in an incident record that doubles as an audit/evidence pack (the record structure linked to Chapter 22). The record must be retained without over-logging personal data — a real tension the assurance chapters balance — and it should preserve the decision record, the containment log, the notification artifacts, and the post-incident review.

5.6 Remediate and learn

Close the control gap the incident surfaced; re-run the affected obligation→control→test gate (Ch.22); update the response model for the next run. A breach that does not change the estate is a breach suffered twice.

6. INC-001: an incomplete-facts incident pack

The incident record, initial Board specimen, principal specimen and detailed update are populated synthetic teaching artifacts. They use Q01 IDs and preserve uncertainty. Nothing was sent to the Board, customers, CERT-In or a supplier, and no current Board submission endpoint is established by this book.

The concrete hypothetical exposure is a DS-001/DS-002 extract in the Company’s cloud workload. The fixture states both list_public=true and object_read_public=true; it does not derive the latter from the former. One seed record for SUB-001 is known to be affected in the synthetic dataset; the population outside that seed is unresolved, not zero. Object-read permission and the controlled test-object observation are scenario inputs, not a probe of any real bucket. Missing historical download logs mean hostile access and attribution are unknown.

The initial Board specimen includes occurrence location, nature, extent as then understood and likely impact; it does not substitute containment location for occurrence location. The principal specimen describes plausible account/financial-contact misuse, steps to avoid responding to unsolicited payment requests, ongoing mitigation and a business-contact placeholder clearly marked as needing a real monitored channel before use. It does not assert that fraud has occurred or promise compensation that the facts do not establish. The update distinguishes configuration cause from the unidentified person who caused it and reports the failed delivery.

A population workstream maintains a query/version, known IDs, candidate cohorts and unresolved partitions. When scope expands, it queues newly identified people and corrects materially inaccurate earlier notices without treating the first recipient list as immutable truth. An impossible-to-reach person remains in a delivery exception queue with attempted registered modes, timestamps, next action and accountable owner. A “sent to all” metric may not count failed submissions as successful delivery.

DELIVERY-001’s proposed next action is retry on the registered account channel and escalation to the incident communications owner; there is no invented delivered receipt. Retry cadence and a fifteen-minute escalation checkpoint are illustrative internal choices, not Rule 7 numbers. A real system should separate prepared, submitted, provider_accepted, delivered, failed and unknown. The packet’s fixture checks that a failure cannot close the affected-person workstream. It does not test email, SMS or Board infrastructure.

7. Parallel tracks and exception discipline

CERT-In and sector tracks are not derived from Rule 7’s awareness clock. The retained CERT-In directions provide a six-hour notice/being-brought-to-notice clock for covered entities and listed cyber incidents, and a separate 180-day Indian-jurisdiction log requirement (CERT:71–79,98–103).[8] The Company’s sector assessment must identify the exact listed event and entity applicability; a generic DPDP breach is not itself a CERT-In classification. The packet links Chapter 5’s retained source-based track rather than claiming an RBI deadline without its operative instrument. sector_track=needs_applicability_review is an open task with an incident legal owner, not permission to defer triage until the Board update.

For the synthetic INC-001 overlay branch, a covered data-leak cyber incident is stipulated to be brought to notice at 09:10. Its calculated six-hour deadline is therefore 15:10 on 10 June, independent of the 09:20 DPDP awareness record. CERT:71–79,98–103,178–211 (retained research/engineering/evidence/cert-in-directions-2022.txt).[8] This is a conditional teaching application of the retained directions, not a conclusion that every lending incident has that trigger. The clock calculations retain both starting facts and outputs. Entity-specific RBI/insurance-distribution questions remain subject to QL-005; the bounded sector mappings are now delivered in Appendix H; no fabricated regulator submission or clock is supplied here.

Applicability comes before a notice conclusion, but must not become a delaying ritual. Chapter 3’s exemptions are processing-specific. For example, Section 17(1) disapplies Chapter II except Section 8(1)/(5), Chapter III and Section 16 for its qualifying activities; that requires actual conditions, not “we are investigating” stamped on all breached customer records. INC-001 assumes no such exemption for the exposed ordinary customer extract. A separate lawful legal-claim file is not a blanket exemption for the source database. ACT:523–550.[1]

A false-positive counterexample is an authorised test using non-personal canary data with no CIA compromise of personal data: record the facts and close the alert, rather than generating a fictional breach. The opposite counterexample is a small, confirmed personal-data exposure with no demonstrated harm: size and apparent low impact do not remove the applicable Rule 7 trigger. Impact informs the content, mitigation and resourcing, not the existence of the duty. RULES:1112–1139.[5]

8. What this pack actually verifies

The local tests exercise timestamp arithmetic, the no-automatic-extension decision, required notice fields, failed-delivery persistence and small/unknown-population branches. They distinguish expected outputs from actual local execution. The deliberately incomplete principal notice lacks protective steps and is rejected; the corrected specimen includes them. A requested but unallowed extension leaves the original deadline unchanged. A later stipulated allowance is modelled as a separate branch, never as an actual Board order. See test-results.json.

The production specification remains wider: detect availability as well as confidentiality incidents; preserve evidence with restricted access; reconcile clock synchronisation; notify through currently valid channels; exercise actual delivery failure and provider outage; authenticate supplier reports; test off-hours ownership and backups; and document corrections to an earlier awareness decision. No local schema test establishes those capabilities, legal timeliness or universal notice success.

A useful drill asks participants to work from what was known at 09:20, not from the final report. Remove one population partition, fail the registered email, then introduce a written extension request without approval. The initial notices must still proceed without delay, uncertainty must remain visible and the original detailed-update deadline must remain in force. If the team waits for perfect information or turns the request into an extension, the exercise has found a control defect rather than an inconvenient story to omit.

The unresolved items are now genuine: current Board channel and applicable later orders, entity-specific sector instruments, real affected-set evidence, attribution and verified delivery. Rule 7’s recipients, content, trigger, seventy-two-hour update and extension condition are supplied from the retained English text. They are no longer delegated to the reader as unread Rules research.

The question that hands the book its next chapter

There is a reason breach response reaches every corner of an organisation’s estate. But the hardest corners are the ones the organisation does not control directly: the processors and third parties who hold its data and who must meet agreed escalation, restriction and erasure duties while the fiduciary retains its statutory responsibility. If the fiduciary is responsible “irrespective of any agreement to the contrary” for what a processor does (Section 8(1)), then every vendor relationship is a control surface — which is precisely the subject of Chapter 17, Processors, Subprocessors and Third-Party Risk.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E) [8] https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf — CERT-In directions dated 28 April 2022

Contents · Reader guide and citation conventions · Artifact index