Data Breach vs Data Leak: What's the Difference?

In May 2023, a vulnerability in MOVEit Transfer let attackers pull data from hundreds of organizations in a matter of days. MOVEit is a widely used managed file transfer product. The Cl0p ransomware group exploited CVE-2023-34362, a SQL injection flaw, and walked out with records from government agencies, pension funds, banks, and universities across more than a dozen countries. That’s a data breach: someone exploited a system, gained unauthorized access, and exfiltrated data that was never meant to leave.

Six months earlier, researchers at Cybernews discovered a database of 3.8 billion records exposed on an unsecured Elasticsearch instance. No attacker needed a vulnerability. No one broke in. The server simply had no password. Anyone who found it — including automated scanners that hunt these things around the clock — could read every record. That’s a data leak.

Both incidents end the same way for the people whose information was involved: their data is out. But how it got out, how widely it has spread, and what legal and practical options they have are quite different. The press uses these terms interchangeably. That habit hides a real distinction.

The short answer: A data breach is an access event. Someone breaks in (a hacker, phishing, or a misusing insider) and takes data that was never meant to leave. A data leak is an exposure event. Data becomes public because it was misconfigured, with no attacker required. The difference matters for your legal rights: breaches usually trigger notification duties, while leaks fall into a gap where companies may never tell you. Either way, if your data was exposed, the practical response is the same.

In this article:

What is a data breach?

A breach is an access event. Someone who should not have had access to a system — or a piece of data within that system — obtained it anyway. That usually means an external attacker exploiting a software vulnerability, compromising credentials, or using phishing to get a foothold. It can also mean a malicious insider: an employee who legitimately has access to systems but uses that access in ways they’re not authorized to.

The Equifax breach in 2017 is the standard textbook case. Attackers exploited an unpatched Apache Struts vulnerability (CVE-2017-5638) and spent roughly 78 days inside Equifax’s systems before anyone noticed. They extracted 147 million Social Security numbers, birth dates, addresses, and driver’s license numbers. Equifax had known about the vulnerability for months. They just hadn’t patched it.

The Marriott breach that came to light in 2018 is more disturbing in a different way. Attackers had been inside the Starwood guest reservation database since 2014 — four years before Marriott discovered it. Marriott acquired Starwood in 2016 and inherited the compromise along with the hotel chain. Up to 500 million guest records were exposed, including passport numbers for some guests. The attacker had time to be methodical and selective. Marriott faced roughly $124 million in fines from UK and US regulators.

Morgan Stanley’s 2022 SEC fine illustrates the insider variant. The SEC fined Morgan Stanley $35 million after a wealth management employee sold thousands of client records to a data broker. The employee had legitimate access to the data as part of their job. The breach wasn’t a hack. It was a trusted person misusing their access for personal profit. From a legal standpoint, it’s still unauthorized use. From a practical standpoint, the client data ended up in the same place it would after an external attack: with someone who wanted to profit from it.

What is a data leak?

A leak is an exposure event. The data becomes accessible to unauthorized parties not because someone broke in, but because it was misconfigured to be accessible in the first place. No attacker was required. The data was simply — to use the legal phrasing that will matter later — technically available.

The most instructive example from recent years is the Microsoft Power Apps incident in 2021. Power Apps, Microsoft’s low-code application platform, had default settings that made data tables publicly accessible unless administrators explicitly changed them. Most administrators didn’t know this. Security researchers at UpGuard found 47 organizations had left their Power Apps portals open to the internet. Those included American Airlines, Ford, the Indiana Department of Health, and New York City’s Department of Education. The exposed records numbered 38 million, covering vaccine appointment schedules, COVID-19 contact tracing data, employee records, and Social Security numbers. Microsoft eventually changed the default settings to private, but the data had already been publicly accessible for months.

The same pattern repeats constantly with cloud storage. An Amazon S3 bucket, an Azure Blob container, a Google Cloud Storage bucket — all are private by default, but a single misconfigured permission setting makes them publicly readable. UpGuard’s research in 2021 documented more than 3,000 AWS S3 buckets containing sensitive data that had been publicly accessible, in some cases for years. In 2021, the Twitch source code and creator payment data — 125 gigabytes of it — became publicly accessible via a misconfigured server. Twitch confirmed it; they attributed it to an error in a server configuration change.

Elasticsearch and MongoDB instances left open without authentication have become almost a genre of security incident on their own. Researchers at Comparitech regularly publish reports of healthcare records, financial data, and personal information sitting in password-free database instances. These are discoverable via Shodan or Censys, tools that scan the entire internet and index everything they find. A healthcare database in Thailand, a voter database in Indonesia, hundreds of millions of Facebook records sitting in an unprotected Amazon S3 bucket (discovered in 2019 by UpGuard). The discoverers are usually researchers. The first discoverer isn’t always.

Why does the distinction matter in law?

Most breach notification laws were written with the unauthorized access model in mind. In the United States, a patchwork of state breach notification laws began with California’s SB 1386 in 2003. They define a reportable breach as unauthorized access to personal information. The GDPR’s Article 33 requires notification to supervisory authorities of “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.”

Leaks fall into an uncomfortable gap. If data was misconfigured to be publicly accessible, has anyone actually accessed it without authorization? The company’s lawyers sometimes argue: our data was technically public, so no one “accessed” it in the legal sense. Therefore, no breach. Therefore, no notification obligation.

This argument has been tried in court and in front of regulators, with mixed results. Some regulators have found that publicly exposing data is itself an unlawful disclosure, regardless of whether anyone provably accessed it. The UK’s ICO and several EU data protection authorities have taken this position. Some US courts have ruled that misconfiguration-caused exposure is actionable. But the legal landscape is inconsistent. The argument creates real space for companies to avoid notifying affected individuals after a leak, even when the exposure was just as serious as a conventional breach.

The practical result: if your data was in a leaky S3 bucket, you may never receive a notification at all. The company may genuinely not know anyone accessed the data, or they may know but believe they have no legal obligation to tell you. Either way, you’re in the dark.

How does your data spread differently?

Here is the practical difference that matters most.

A breach produces a discrete dataset. The attacker exfiltrated some set of records — whatever they had time and bandwidth to pull before they were detected or before they left. That dataset circulates in the underground economy: sold on forums, traded between groups, eventually posted publicly. The spread happens through human transactions. It’s traceable in aggregate, even if you can’t follow your specific record.

A leak is different because the exposure is continuous for as long as the misconfiguration persists — and because automated systems find and archive open data almost immediately. Shodan indexes internet-connected services in near real-time. GrayhatWarfare, a searchable database of open S3 buckets, catalogs publicly accessible cloud storage continuously. Security researchers find open databases and report them responsibly (usually), but not always before others have found them too. By the time the owning company discovers a misconfigured database, it has often already been crawled, indexed, or downloaded by whatever automated system found it first.

The interval between exposure and discovery is often measured in months. The 2021 Microsoft Power Apps exposure had been publicly accessible for an unknown period before researchers found it. The Bangladesh Bank SWIFT data exposure was accessible long enough that the question of who saw it first was never fully answered. A database that was open for two weeks before being secured may have been indexed within hours.

The result: when a leak is finally fixed, the answer to “did anyone access this data?” is genuinely unknowable. What you do know is that automated scanners found it. You just don’t know what they did with it afterward.

The gray zone: when a breach and a leak meet

The MOVEit breach and the Power Apps leak sit at opposite ends of a clear spectrum. But real incidents often land somewhere in the middle.

Consider the scenario where an employee misconfigures an internal system and a competitor or attacker finds the opening and downloads data. That starts as a leak — misconfiguration, no attacker required — and becomes a breach the moment someone with bad intent accesses it. From the affected individuals’ perspective, it looks identical to a purely external breach. The company may still try to argue that the initial exposure was a misconfiguration, not a breach, limiting their notification obligations.

Or consider the Bangladesh Bank case: the SWIFT system exposure involved both inadequate access controls (leak-like in origin) and deliberate actors exploiting those controls (breach-like in execution). Most regulatory actions treat these hybrid incidents as breaches because unauthorized access occurred, regardless of how the door was left open.

What does this mean for you practically?

Whether your data was breached or leaked, it may now be in circulation. The severity isn’t determined by which category the incident falls into — it’s determined by what type of data was exposed. A leaked database of Social Security numbers is more dangerous than a breached database of usernames only.

For the immediate response, the actions are the same regardless of how your data got out:

After a breach, the notification window gives you a rough timeline. The attacker exfiltrated data at some known point; you’re dealing with a known exposure. After a leak, there’s no such anchor. Your data may have been accessible for months before discovery. The uncertainty is worse, not better.

The other practical difference: after a breach, you can ask legal questions about unauthorized access and, in some jurisdictions, pursue compensation claims based on that unauthorized access. After a leak, the legal route is harder. You need to demonstrate harm rather than simply that the access was unauthorized. Courts are increasingly willing to hear misconfiguration cases, but it remains harder to establish standing than in a clear unauthorized-access breach.

Checking whether you were affected

HaveIBeenPwned (haveibeenpwned.com) aggregates breach data from confirmed incidents and lets you search by email address. It covers conventional breaches well. Its coverage of leaks is patchier — some major leak datasets have been added, but not all.

Some security researchers maintain separate indexes of leaked databases (Dehashed, LeakCheck, and others). These tend to have broader coverage of leak data, but they also have less rigorous verification. Treat hits from these sources as signals worth investigating rather than confirmed exposures.

For cloud leak data specifically, GrayhatWarfare lets you search open S3 buckets. This is useful if you’re trying to determine whether a specific company’s cloud storage was — or is — misconfigured.

The response checklist

Whether you’re responding to a breach notification, a news report about a company you use, or a hit on HaveIBeenPwned, the response is the same:

Immediately:

Change the password on the affected service. Use a password manager to generate something unique — not a variation of your old password.
Check every other account where you used the same password. Change those too. All of them.
Enable two-factor authentication on the affected service and on every account where you just changed a duplicate password. Use an authenticator app — not SMS — where the option exists.

Within 24 hours:

If the exposed data included payment card numbers: contact your bank or card issuer, ask them to reissue the card, and review your recent transactions.
If the exposed data included national ID numbers (Social Security number, National Insurance number, Aadhaar): place a credit freeze at all three major credit bureaus (in the US: Equifax, Experian, TransUnion). A freeze is free and prevents new credit lines from being opened in your name without your explicit approval. This is also the right step if the breach included financial account numbers.
If the exposed data included medical records: review your explanation of benefits statements for procedures you didn’t receive. Medical identity theft — using someone’s insurance to bill for fraudulent care — is difficult to detect and slow to resolve.

Ongoing:

Set up monitoring for your email address at HaveIBeenPwned. Free alerts notify you when your email appears in newly added breach datasets.
Check your credit reports. In the US, annualcreditreport.com gives you free reports from all three bureaus. In the UK, Experian and Equifax offer free tiers. Look for accounts you didn’t open, inquiries you didn’t authorize, or addresses you don’t recognize.
If you received an official breach notification: read it for the specific data types involved. The company’s notification is your best source for what was exposed, not the press coverage, which is often incomplete.
Watch where your exposed details resurface. Breach and leak data feeds people-search sites that build searchable profiles from it.

If you believe harm resulted:

In the EU and UK: you have a right to file a complaint with your data protection authority (your national DPA under GDPR; the ICO in the UK). This is free and requires no lawyer.
In the US: the FTC (ftc.gov/idtheft) has resources for identity theft victims. For financial fraud, your state attorney general’s office is often a better starting point than federal agencies.
For significant breaches involving UK or EU residents, specialist no-win-no-fee solicitors handle data breach compensation claims. Our guides to UK compensation claims and GDPR non-material damage claims cover what you need to show.

One more thing worth knowing: the distinction between breach and leak, while real and legally significant, does not determine whether you were harmed. A misconfigured database containing your home address, health records, or financial details is just as dangerous as the same data extracted by an attacker. The only question that ultimately matters is what was exposed and who might have seen it.

The MOVEit breach was discovered because Cl0p announced it. The Power Apps leak was discovered because researchers were looking. In neither case did the affected individuals find out through any mechanism they controlled. That’s the state of things. The checklist above is what you have.

Frequently asked questions

What’s the difference between a data breach and a data leak? A breach is unauthorized access: someone breaks in and takes data. A leak is accidental exposure: data sits open because of a misconfiguration, with no attacker needed. Both end with your data out.

Is a data leak less serious than a breach? Not necessarily. Severity depends on what data was exposed, not how. A leaked database of Social Security numbers is more dangerous than a breached list of usernames.

Do companies have to tell me about a data leak? Often no. Notification laws focus on unauthorized access. Companies sometimes argue that misconfigured, publicly available data was never “accessed,” so no breach occurred and no notice is owed.

What should I do if my data was breached or leaked? The steps are the same either way. Change reused passwords, enable two-factor authentication, freeze your credit if ID numbers leaked, and set up Have I Been Pwned alerts. See our guide on what to do after a data breach.

What you can do right now

Want to see what data brokers expose about you? See what a scan finds → shows an example report: the kinds of sites that list your name, phone, and address. Once KnytX Shield launches it will find and remove these listings automatically. Join the waitlist to get in early.