Skip to content

Glossary · Privacy & regulation

Data breach

Also called: Security incident, Personal data breach, Unauthorized disclosure

A data breach is unauthorised access to, or acquisition of, protected information. Whether a given incident is legally a breach is a definitional question that varies by statute and by data type — and the same facts can be reportable under one regime, exempt under another, and subject to different deadlines under a third.

Organisations use the word loosely for any security incident. The statutes do not. Most notification regimes are triggered by unauthorised acquisition of specified categories of personal information, and several provide that unauthorised access alone — without acquisition — may not qualify.

That distinction is doing enormous work. An attacker who reached a database server but for whom no exfiltration can be demonstrated may or may not trigger obligations, and the answer is a forensic question dressed as a legal one: what evidence exists that data was actually taken, rather than merely reachable?

This is exactly why establishing scope is the deliverable of an investigation, and why an inconclusive investigation is expensive.

The regimes rarely align

A single incident affecting a national customer base can implicate every US state's notification statute, sector regulators, and foreign regimes simultaneously. They differ on nearly every axis: what data is covered, whether encryption creates a safe harbour, what the deadline is, who must be notified, and whether a risk-of-harm assessment can excuse notification.

The deadlines are the sharpest edge. Several regimes now run on very short clocks — some measured in days from determination or awareness rather than from completion of the investigation. Waiting for a complete forensic picture before starting the notification analysis is a common and costly sequencing mistake.

Encryption safe harbours are narrower than assumed

Many statutes exempt encrypted data from notification. The exemptions generally assume the encryption keys were not also compromised, and in a network intrusion where the attacker held administrative credentials that assumption frequently fails.

Similar caution applies to hashed credentials: whether hashing is protective depends on the algorithm and whether it was salted, and a fast unsalted hash of a common password provides very little protection in practice. "It was encrypted" is the beginning of the analysis rather than the end of it.

Personal exposure

Regulators and plaintiffs have increasingly looked past the entity to named individuals — security officers and executives — on theories of misrepresentation about the organisation's security posture, or failure to escalate known deficiencies. The pattern in the cases that have gone badly is not usually the incident itself; it is a gap between what the organisation said publicly about its controls and what the internal record showed people knew.

The practical implication for anyone in that role is unglamorous: document what you escalated, to whom, and what was decided.

What preparation actually helps

A notification analysis is much faster when the organisation already knows what personal data it holds, where, and for which jurisdictions' residents. Most organisations discover during an incident that they cannot answer this, and the resulting delay consumes the notification clock. A current data map is the least exciting and most useful piece of breach preparation there is.

From our work

Dealing with data breach in a live matter?

Our examiners and testifying experts work these questions for a living. Tell us what you're facing.

Reviewed by Law & Forensics. See our editorial standards.