What is a data breach? Types, causes and consequences

What counts as a data breach

Under the EU GDPR the formal term is a personal data breach. Article 4(12) defines it as "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".

Read that definition slowly, because most people only hear the last few words. Destruction, loss and alteration sit in it alongside disclosure and access. A ransomware crew that encrypts a customer database without exfiltrating a single record has caused a personal data breach. So has an administrator who deletes the only surviving copy of a table, or a migration script that quietly corrupts a column of addresses. Confidentiality is one of three ways to fail; availability and integrity are the other two.

So "we have no evidence that data left our network" answers one third of the question, not all of it. Nor does a breach need a dramatic intrusion: a database left reachable from the internet, a spreadsheet sent to the wrong recipient and an unencrypted laptop on a train all land inside the same definition.

How breaches actually start

The Verizon 2026 Data Breach Investigations Report puts exploitation of vulnerabilities at 31% of breaches as an initial access vector — the most common route in, up from 20% the year before — with phishing at 16%, credential abuse at 13% as a first action and pretexting at 6%. Read the credential figure carefully: the DBIR added pretexting to its tracked vectors this year and states that credential abuse would have read 16% without that change, and that it still appears somewhere in 39% of breaches. Cutting the same data differently, the human element was present in 62% of breaches, up from 60%: someone clicked, sent, misconfigured or was deceived.

ENISA’s Threat Landscape 2025 analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and counts observed intrusion cases rather than confirmed breaches, which is why its shares run higher. Phishing and its relatives — vishing, malspam, malvertising — appear in roughly 60% of intrusion cases, exploitation of vulnerabilities in 21.3%, botnets in 9.9%, malicious applications in 8% and insiders in 0.8%. ENISA also found that 27% of phishing cases led to an intrusion, while phishing deployed malicious code in only 23% of cases — "suggesting it might be primarily used for malware-less objectives".

That last figure is the useful one: most phishing is not planting malware, it is collecting a password that works — quieter and far harder to detect than an implant.

What leaked, and can you undo it

Severity depends far less on the record count than on which fields were in those records. Answer this before drafting a line of communication:

The final column shapes everything downstream. A credential breach has a finish line — enumerate, rotate, verify. A breach of identity attributes has none, only a permanent change in the victim’s threat model.

The supplier you did not think about

The fastest-moving number in the DBIR is not an attack technique. In the 2026 edition, breaches with third-party involvement rose 60% year on year, reaching 48% of all breaches. Nearly one breached organisation in two was reached through a partner, a vendor, a shared platform or a code dependency rather than through its own perimeter.

The 2025 edition showed why that channel stays open so long: the median time to remediate a leaked secret discovered in a GitHub repository is 94 days. An API key or database credential committed by accident sits there for roughly three months before anyone rotates it. Nobody has to break in during those 94 days; they only have to be looking.

Your exposure is therefore not bounded by your own controls: it includes every integration holding a token for your systems. GDPR Article 33(2) requires a processor to notify its controller without undue delay — agree that path in the contract before you need it.

Why an old breach still hurts

A password leaked from a forum you forgot about years ago still works against you today, because leaked credentials do not expire — they get aggregated into combolists and replayed automatically. The DBIR 2025 describes a mature economy behind this: marketplaces posting logs for sale with the associated domains, paid premium channels, live backend access to infostealer databases, and free samples on Telegram.

The infostealer data makes the corporate angle explicit. 30% of the compromised systems appearing in infostealer credential logs can be identified as enterprise-licensed devices, and 46% of the compromised systems that had corporate logins in the stolen data were non-managed devices holding both personal and business credentials — the BYOD laptop, or the work login saved in a personal browser profile.

So "it was an old account" is not reassurance; it is a description of the attack. For the mechanics of how a leaked pair becomes a hijacked account, read how credential stuffing works.

What the organisation has to do

Once an organisation becomes aware of a personal data breach, GDPR sets both the clock and the content of the response.

• Article 33(1) — notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach is unlikely to result in a risk to people’s rights and freedoms. Later than that, and you must state the reasons for the delay.
• Article 33(3) — describe the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned; give the DPO or other contact point; describe the likely consequences and the measures taken, including mitigation.
• Article 33(4) — where you cannot supply all of that at once, it may be provided in phases without undue further delay.
• Article 33(5) — document any personal data breach: the facts, the effects and the remedial action. This applies to breaches you decide not to notify, and it is how the authority verifies that decision.
• Article 34(1) — where the breach is likely to result in a high risk, communicate it to the affected data subjects without undue delay. Article 34(3)(a) lifts that duty where the data was protected by measures rendering it "unintelligible to any person who is not authorised to access it, such as encryption".

Two details catch organisations out. The 72-hour clock starts at awareness, not at the intrusion, so a long detection gap is your problem rather than your extension. And the Article 33(5) register is the duty people forget, because it covers the quiet incidents nobody escalated.

What to take from this

• Classify by field, not by record count — "can this be rotated?" decides the shape of the whole response.
• Encrypt personal data at rest; Article 34(3)(a) turns that control into a concrete reduction in obligations.
• Inventory who else holds a key to your systems, because nearly half of breaches now involve someone else.
• Rotate on evidence, not on a schedule: NIST SP 800-63B tells verifiers to force a change where there is evidence the authenticator has been compromised.

If you have just learned you are in a leak, the ordered response is set out in what to do after a data breach.