What Is a Data Breach?
LawThe Act defines a personal data breach broadly: any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, that compromises its confidentiality, integrity, or availability. This is wide enough to cover a stolen laptop with unencrypted customer data, a misconfigured database exposed to the public internet, a phishing attack that exfiltrates records, or even an internal employee accessing data well outside their role — not only the "hacker breaks in" scenario people often picture first.
Common Causes
In practice, breaches are more often caused by misconfiguration (an exposed cloud storage bucket, an access-control gap), credential compromise (phishing, reused passwords), or third-party/vendor incidents than by a sophisticated targeted attack — which is exactly why the baseline safeguards covered in Chapter 09 (access control, monitoring, vendor oversight) matter more, in aggregate, than any single advanced security control.
Detection
PracticeThe notification clock (below) starts running from when you become aware of a breach — which means weak detection capability doesn't buy you more time, it just delays when you find out, while the underlying exposure continues. Logging and monitoring (Chapter 09) are what make "aware" happen promptly rather than being triggered by an external report weeks later.
The Notification Timeline
LawRule 7 of the DPDP Rules sets out a two-stage notification requirement once a breach occurs: an initial intimation to the Data Protection Board without delay, followed by a more detailed report within 72 hours of becoming aware of the breach (extendable in specified circumstances). Affected Data Principals must separately be notified without delay, in a manner describing the nature of the breach, its likely consequences, and the safeguards being taken in response.
| Regime | Who's notified | Timeline |
|---|---|---|
| DPDP Rules, Rule 7 | Data Protection Board + affected Data Principals | Without delay (initial); detailed report within 72 hours |
| CERT-In 2022 Directions | CERT-In | Within 6 hours of becoming aware, for specified incident types |
These are two separate, parallel obligations that can both apply to the same incident — meeting one doesn't discharge the other.
Containment
PracticeStopping ongoing exposure — revoking compromised credentials, isolating an affected system, closing an exposed endpoint — is usually the first practical action once a breach is confirmed, running in parallel with (not sequentially before) starting the notification clock. A tested runbook that assigns clear ownership for containment versus notification versus communications avoids the common failure mode of a small team trying to do all three at once with no clear order of operations.
Documentation
Recording what happened, when it was detected, what data was affected (which depends directly on the data inventory from Chapter 07), what containment steps were taken, and when each notification was sent, is both a practical incident-response necessity and the evidence you'd need to show the Data Protection Board that your response met the required timeline.
Breach Management
| Stage | Key action |
|---|---|
| Detect | Monitoring flags or a report surfaces the incident |
| Contain | Stop ongoing exposure immediately |
| Assess scope | Which systems, which data categories, how many individuals — using the data inventory |
| Notify | Board (without delay, then detailed report within 72 hours) and affected individuals (without delay) |
| Review | Post-incident analysis of root cause and what changes as a result |
Post-Incident Review
PracticeA breach that isn't followed by a genuine review of what allowed it to happen tends to recur in a slightly different form. The review should feed back into the safeguards in Chapter 09 and the runbook itself — not as a blame exercise, but as the mechanism that actually improves your position before the next incident, rather than only responding faster to the same kind of failure repeatedly.
Writing a breach-response plan that assumes you'll have time to figure out what data was affected after the notification clock has already started. By the time an incident happens, that assessment needs to be fast — which only works if the data inventory (Chapter 07) already tells you what's in the affected system before you're under time pressure to find out.