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”.

The malicious-code figure shows why malware detection alone cannot cover phishing. It does not establish that every remaining case involved credential theft: deception can also seek payments, information or other actions.

What leaked, and can you undo it

Assess the data types, number of people affected, exposure conditions and likely consequences together. Identify the affected fields before drafting a notification:

Leaked data types and what recovery actually looks like

What leaked	Why it is dangerous	Can you undo it?
Credentials (email + password)	Replayed automatically against every other service the person uses; the standard opening move in account takeover.	Future password reuse can be blocked by changing affected and reused passwords. Investigate past misuse, revoke affected sessions and enable MFA.
Personal data (name, address, date of birth)	Permanent identifiers that make phishing, SIM-swap attempts and identity fraud sound credible.	You cannot reliably recall disclosed copies. Plan for continuing fraud and social-engineering risks.
Session tokens and API keys	Grant access without a password and can sidestep an MFA prompt entirely.	Revoke suspected compromised sessions and keys; investigate what happened while they were valid.
Financial data (card, account details)	Enables direct fraud and lends authority to social engineering.	Ask the bank about replacement cards, account protection and disputed transactions. Disclosed history cannot be recalled.

The final column helps shape containment, but neither case ends with a single action. After rotating credentials, check sessions, recovery methods, account changes and signs of misuse. Disclosed identity attributes may require continuing vigilance.

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. Third-party involvement can take different forms, including suppliers, shared platforms and dependencies; the figure does not mean every such breach began outside the organisation’s 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 years ago can still work against you today if it remains valid and has been reused – 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.

A large share of that material is corporate rather than consumer, and much of it comes off devices the employer never managed.

So “it was an old account” is not reassurance; it is a description of the attack. For the mechanics – the device split behind those logs, and 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

• Assess affected fields, people, scale and consequences. Whether a secret can be changed is one part of the containment plan.
• Encrypt personal data and protect the keys. Article 34(3)(a) is not an automatic exemption: assess whether the affected data actually remained unintelligible, including whether readable copies or keys were accessed.
• 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. Breach monitoring is one source of that evidence, with known coverage limits.

If you have just learned you are in a leak, the ordered response is set out in what to do after a data breach, and the triage table on the home page sorts the first actions by what was exposed.