Data leak

A data leak, also called a data breach or an information leak, is an incident in which confidential, sensitive or protected information is exposed, disclosed or made reachable to people who were not authorised to see it.

It is worth noting how rarely this begins with an intrusion. Leaks come from misconfigured storage, from mail sent to the wrong recipient, from a laptop left somewhere, from a repository pushed public, and from people inside the organisation as often as from outside it.

The consequences do not scale with how sophisticated the cause was. A bucket left open and a targeted intrusion can produce the same disclosure.

What kinds there are

Classified by what was exposed rather than by how, which is the classification that decides what has to happen next.

Personal data. Names, identifiers, addresses, anything that points at a person. See personal data, whose scope is wider than most people assume.

Financial data. Card details, account numbers, transactions.

Commercial secrets and intellectual property. Designs, source code, pricing, contracts, plans.

Health data. Which carries its own regime almost everywhere, and its own consequences for the individuals concerned.

What it costs

The direct costs are the visible part: investigating, containing, notifying, and fixing whatever allowed it.

The regulatory exposure follows, and depends on what was in the data rather than on how the organisation feels about the incident.

Then the part that lasts longest, which is that customers now know. Trust is slow to rebuild and it is not restored by the technical fix.

And for the people whose data it was, the consequences are theirs to carry: identity theft, fraud, and information about them that cannot be recalled.

A worked example

An employee at a financial services firm copies a file of customer records onto a personal USB stick to finish some work, and loses it in a public place.

The file holds identifiers, banking details and other personal data for thousands of customers.

The firm learns about it when somebody reports finding the device and being able to open the file.

What follows is the same sequence in every case of this kind: work out exactly what was in it, notify who has to be notified within the time allowed, and answer the question of why that file could be copied unencrypted onto removable media at all. The last question is the only one whose answer prevents the next incident.

The incident, the control that prevents it, and the place it ends up

This entry describes the incident. The two glossary entries that always appear beside it are not synonyms for it.

Data loss prevention (DLP) is the control: it classifies sensitive information and watches the routes by which it could leave. It is what you put in place so the leak does not happen. Its problem today is coverage, because the routes have moved: a configuration written for email and USB does not see sync to personal storage, a secret pushed to a public repository, or a paragraph pasted into an AI assistant.

A ransomware leak site is one specific way data becomes public: the place where an extortion group publishes the files of victims who did not pay. It is a channel, not the leak.

The distinction that decides obligations is this: information leaving and information being published are not the same moment. Once a published sample appears there is proof that the data left, and that proof is public, which turns the decision about notification into a very different conversation from the one held when exfiltration is only suspected.

And not every leak comes from outside. The person who takes the information is usually authorised to see it, which is what insider threat is about.