Data Loss vs Data Breach vs Data Leak: Obligations

Teams argue about whether an incident is a "leak" or a "breach" while the notification clock is already running, because the legal tests do not use those everyday words the way security teams do. Under the GDPR, a ransomware outage with no data stolen and an email sent to the wrong customer can both be personal data breaches; under HIPAA, an impermissible disclosure is presumed to be a breach until a documented risk assessment shows otherwise. This guide separates the three terms, shows how each maps to the legal definitions that create obligations, and sets out the triage and response steps that follow. It is for incident responders, privacy and legal teams, and security leaders who need a shared vocabulary before the next incident. Legal positions are as stated by the official sources on 14 November 2026. For country-by-country rules see the Breach Notification Laws by Country Guide.

Key takeaways

Short answer: "leak" and "loss" describe what happened, "breach" is the legal label. A data leak is unintended exposure, data loss is data that is gone or out of your control, and a breach is whatever a specific law defines it to be. Classify against the law, not the headline.
Under the GDPR, loss and leaks are usually breaches. Article 4(12) covers accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Intent and attackers are not required.
Availability counts. The EDPB treats a temporary loss of availability, such as ransomware encryption restored from backup, as a breach that must be documented, with notification depending on risk.
Every regime has its own trigger. GDPR notifies on risk, HIPAA presumes a breach unless risk is shown to be low, NIS2 reports significant incidents whether or not personal data is involved, and the SEC rule turns on materiality.
Record everything, notify selectively. GDPR Article 33(5) requires a record of every personal data breach, including those not notified, so the decision not to notify needs written reasons.

Three terms, defined for practice

None of the three words has one universal legal meaning, so define them internally and map each to the laws that apply to you.

Data leak: sensitive data exposed to people or places it should not reach, usually without an attacker driving it: a public storage link, a misdirected email, credentials committed to a public repository, source code pasted into an external AI service. A leak describes the path. Whether anyone actually accessed the data is often unknown at first.
Data loss: data that is destroyed, corrupted or out of the organisation's control: a deleted database with no backup, an unencrypted laptop left on a train, files encrypted by ransomware. NIST's glossary, quoting SP 800-137, defines data loss more narrowly as "the exposure of proprietary, sensitive, or classified information through either data theft or data leakage", which is why data loss prevention (DLP) tools focus on exfiltration rather than deletion. Be clear which sense you mean.
Data breach: in security usage, a confirmed compromise of data, often by an attacker. In law, a defined term with conditions, and the conditions differ by regime. A leak or loss becomes a reportable breach when it meets the definition and the risk or materiality threshold of a law that applies.

In short, leak and loss are descriptive, and breach is a legal conclusion. Write your incident classification so that responders record facts (what data, what happened, who could access it, for how long) and privacy or legal colleagues apply the definitions.

How the legal definitions line up

Regime	What counts	Notification trigger	Deadline
EU GDPR and UK GDPR	"a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed" (Art. 4(12))	Authority: unless "unlikely to result in a risk" to individuals (Art. 33). Individuals: "likely to result in a high risk" (Art. 34)	Authority: without undue delay and, where feasible, within 72 hours of awareness. Individuals: without undue delay
HIPAA (US health)	Impermissible use or disclosure of protected health information that compromises its security or privacy; presumed a breach unless a low probability of compromise is shown	Unsecured PHI only; encryption or destruction to HHS guidance exempts	Individuals without unreasonable delay, no later than 60 days after discovery; HHS within 60 days for 500 or more people, annual log for fewer
NIS2 (EU essential and important entities)	"Incident": an event compromising the availability, authenticity, integrity or confidentiality of data or services (Art. 6(6))	Significant incident: severe operational disruption or financial loss, or considerable damage to others	Early warning within 24 hours, notification within 72 hours, final report within one month
SEC (US listed companies)	Cybersecurity incident, personal data or not	Determined to be material	Form 8-K Item 1.05 within four business days of the materiality determination

Two things follow. First, one incident can trigger several regimes with different clocks: a ransomware attack on an EU healthcare provider with US patients can engage GDPR, NIS2 and HIPAA at once. Second, the regimes do not agree on what starts the clock: GDPR runs from awareness, HIPAA from discovery, the SEC rule from the materiality determination. Record each timestamp separately. The Data Breach Notification Checklist covers US state rules alongside GDPR.

Data leaks in depth

Threat model: most leaks are self-inflicted: configuration and sharing decisions that expose data, rather than intrusions. Attackers then find them with scanning, which is why a leak that lasted months must be assumed accessed unless logs prove otherwise. Exposure of cloud storage maps to MITRE ATT&CK Data from Cloud Storage (T1530) once someone collects it.

How it happens, in words: a person or pipeline creates an access path (public bucket, anonymous link, over-scoped signed URL, public repository, external AI tool) and sensitive data flows into it. The Microsoft SAS Token Exposure 2023 is the textbook case: a shared link meant for AI research data granted full control over a storage account holding 38TB, including workstation backups with secrets. The Samsung ChatGPT Source Code Leak 2023 shows the non-malicious path: staff pasted proprietary code into a public AI service, where it could not be retrieved.

Legal treatment: under GDPR a leak of personal data is an unauthorised disclosure or access, so it is a personal data breach whether or not misuse is proven; the notification question is risk. Under HIPAA, a misdirected disclosure is presumed a breach unless the four-factor assessment shows low probability of compromise, and one listed exception covers a good-faith belief that the recipient could not reasonably have retained the information.

Failure modes: treating "no evidence of access" as "no breach" when access logs were never enabled; closing the link without determining how long it was open; forgetting that leaked credentials are a second incident waiting to happen.

Controls: posture scanning for public and external sharing, short-lived and narrowly scoped signed links, secret scanning on repositories, DLP for prompts and uploads, and access logging on every store that holds personal data, so the access question can be answered. See the Data Loss Prevention (DLP) Guide.

Data loss in depth

Threat model: loss covers destruction, corruption and loss of control: ransomware (ATT&CK Data Encrypted for Impact, T1486), malicious deletion (Data Destruction, T1485), failed migrations, lost or stolen devices and media, and misdirected physical post.

How it happens, in words: either the data stops being available to you, or a copy leaves your control without an access path you created. The Codefinger S3 Ransomware 2025 combined both: stolen keys with write access were used to re-encrypt bucket contents with a key only the attacker held, with lifecycle rules set to delete files within seven days.

Legal treatment: the EDPB's Guidelines 9/2022 split personal data breaches into confidentiality, integrity and availability breaches. Permanent loss or destruction is always an availability breach; a temporary loss of availability is also a breach that must be documented, with notification depending on likely impact on individuals. Ransomware restored from backup may be only a temporary availability breach, but if the attacker accessed the data it is also a confidentiality breach. For a lost device, encryption decides a lot: GDPR Article 34(3) removes the duty to tell individuals where measures such as encryption made the data unintelligible, and HIPAA notification applies only to unsecured PHI.

Failure modes: classifying a ransomware event as "IT outage, no data breach" without examining exfiltration; assuming a lost laptop was encrypted without evidence from device management; restoring from backup and closing the ticket without recording the availability breach.

Controls: immutable or offline backups tested for restore time, full disk encryption with compliance reporting, remote wipe, and least-privilege, short-lived credentials on storage so write access cannot be turned into a ransom key. See the What to Do After a Data Breach Guide for the individual's side.

Data breaches in depth

Threat model: the classic attacker-driven compromise: credential theft, exploitation, insider misuse, followed by collection and exfiltration (for example Exfiltration Over Web Service, T1567). Here the "breach" label in security and in law usually coincide.

Legal treatment: the work is in scoping. GDPR Article 33(3) requires the notification to describe the nature of the breach including approximate numbers of individuals and records, the contact point, likely consequences and measures taken; Article 33(4) allows information in phases. The EDPB says a controller becomes aware when it has a reasonable degree of certainty that a security incident has led to personal data being compromised, and allows a short, promptly started investigation first. A processor must tell the controller without undue delay and does not assess risk itself.

Failure modes: waiting for forensic certainty before notifying; not knowing which processors hold the data; under-scoping because the data inventory is incomplete, then issuing a second, larger notification.

Controls: an incident response plan with privacy and legal roles named, pre-approved notification templates, processor contracts with breach notice terms, and a current data inventory so scoping takes hours, not weeks. See the Data Classification vs Data Discovery guide for building that inventory.

Triage: deciding what you have

Run these questions in order at the first incident bridge. Record answers and timestamps; they become the Article 33(5) record or its equivalent.

Is personal data or regulated data involved? If yes, a privacy lead joins now. If unknown, assume yes until shown otherwise.
Which property was affected? Confidentiality (exposed or accessed), integrity (altered) or availability (lost, encrypted, destroyed). More than one can apply.
Was it accidental or deliberate, internal or external? This does not decide whether it is a GDPR breach, but it drives containment and the HIPAA exceptions.
Was the data protected? Encryption with keys not compromised can remove individual notification under GDPR Article 34(3) and HIPAA's unsecured PHI test. Confirm, do not assume.
Who could access it, and for how long? Check access logs for the exposure window. No logs means you cannot show non-access.
What is the likely risk to individuals? Consider data type, volume, identifiability and vulnerability of those affected. This sets authority and individual notification under GDPR.
Which regimes apply and when did each clock start? Record awareness, discovery and any materiality determination separately.

Worked scenario

A UK and EU software company finds, on a Monday, that a support engineer shared a folder of customer exports through an anonymous link eight weeks earlier. The folder held names, email addresses and partial payment details for 12,000 customers. Storage access logging was on.

Label: a leak in everyday terms; under UK GDPR and EU GDPR an unauthorised disclosure, so a personal data breach from the moment the company had reasonable certainty, Monday afternoon.
Facts: logs show the link was opened 31 times, from 4 IP addresses, two of them the intended partner. Two unknown addresses downloaded the full folder.
Risk: contact details plus partial card data enable targeted phishing. Risk is likely, so authorities are notified within 72 hours. Whether risk is high, triggering individual notice, is assessed with the downloads in mind; the company decides to notify individuals with phishing guidance.
Record: the decision, reasoning and timestamps go into the breach register. See the Data Breach Register Template.
Counterfactual: with no access logging, the company could not have shown limited access and would have had to treat all 12,000 as exposed for the full eight weeks.

Response steps by category

Step	Leak	Loss	Attacker breach
Contain	Remove the access path; revoke links and tokens; rotate exposed credentials	Isolate affected systems; stop deletion; wipe lost devices remotely	Evict the attacker; reset compromised identities; block exfiltration routes
Establish facts	Exposure window; access logs; who downloaded	What is gone; backup state; whether data was also taken	Entry point, dwell time, data accessed and exfiltrated
Recover	Request deletion from unintended recipients where possible	Restore from tested backups; verify integrity	Rebuild from known good state; monitor for re-entry
Assess and notify	Risk from what was exposed and to whom	Availability impact plus any confidentiality element	Scope, risk and every applicable regime
Evidence to preserve	Sharing settings, access logs, link creation records	Device management records, backup logs, ransom notes	Endpoint and identity logs, cloud audit trails, forensic images

Decision guidance

Small organisations: adopt the GDPR definition as the internal definition of "breach" even outside the EU and UK: it is the broadest common test, so anything narrower is covered. Keep one register for all incidents involving personal data.
Large or multi-regime organisations: separate the security incident classification from the legal breach determination. Security severity drives response; a privacy and legal panel applies each regime's definition and owns the clocks.
When in doubt about risk: the ICO encourages reporting early and updating later, and GDPR Article 33(4) permits phased information. A short initial notification is usually safer than a late complete one.
Machine identities: a leaked API key or service account credential is a leak of a secret, not of personal data, but it is often the access path to a breach. Treat it as an incident in its own right, rotate first and then investigate what the identity could read. See the Service Account Security Guide.

Detection and measurement

Time from detection to legal determination: hours from first alert to a documented decision on breach status per regime.
Notifications within deadline: share of notifications made within 72 hours (GDPR) or the applicable clock.
Exposure window: median days between a leak path being created and being closed.
Logging coverage: share of stores with personal data that keep access logs long enough to answer "who accessed it".
Register completeness: incidents with a recorded breach decision and reasons, including those not notified.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.AE-04 impact and scope understood; RS.AN-03 analysis of what happened; RS.CO-02 stakeholders notified	Scoping and notification
NIST SP 800-53 Rev 5	IR-4 Incident Handling; IR-6 Incident Reporting; IR-8 Incident Response Plan; CP-9 System Backup	Response, reporting and recovery from loss
NIST SP 800-61 Rev 3	Incident response as a CSF 2.0 community profile	Programme structure
ISO/IEC 27001:2022 Annex A	5.24 to 5.28 information security incident management; 5.34 privacy and protection of PII	Process and evidence
GDPR	Art. 4(12), 33, 34	Definition, authority and individual notification
MITRE ATT&CK	T1530, T1567 (confidentiality); T1486, T1485 (availability)	Mapping incident type to technique

Common failure patterns

"It was a leak, not a breach": using everyday vocabulary to avoid the legal test. Under GDPR, accidental disclosure is a breach.
Ransomware filed as an outage: restoring from backup and closing the incident without recording the availability breach or examining exfiltration.
One clock for everything: tracking only the 72-hour GDPR deadline and missing the NIS2 24-hour early warning or the SEC four-business-day rule.
No logs, no defence: storage without access logging forces worst-case assumptions about who saw the data.
Undocumented decisions not to notify: the Article 33(5) record and HIPAA's burden of proof both require reasons in writing.

Practitioner checklist

Define leak, loss and breach internally and map each to the regimes that apply to you.
Make the GDPR definition, including availability, the default test for personal data.
Add a privacy and legal determination step to the incident process, separate from technical severity.
Track awareness, discovery and materiality timestamps separately for each incident.
Enable and retain access logs on every store holding personal or regulated data.
Confirm encryption status of lost devices from device management records before relying on exemptions.
Keep a breach register covering every personal data breach, notified or not, with reasons.
Pre-agree notification templates and processor breach notice terms.

Standards and references

Related NHI Mgmt Group resources: Breach Notification Laws by Country Guide, Data Breach Register Template, Data Loss Prevention (DLP) Guide, Incident Response Guide. This guide summarises breach definitions and notification rules and is not legal advice.

Data Loss vs Data Breach vs Data Leak: How the Label Changes Your Obligations