Research Library
Research Library
Case studies of reported data breaches and cyber incidents, threat-intelligence fundamentals, and industry developments — held to one rule above all: confirmed facts only, with the source named and the date on the page.
How we cover incidents. Nothing here is based on rumour, screenshots from unknown accounts, or claims no one will stand behind. If a fact is not confirmed, we say so — and we never publish leaked data, live indicators, or personal details from a breach. See our Research Methodology and Fact-Checking Policy for the full standards.
What the library is
This is the part of the site where real incidents are studied, slowly and carefully, instead of chased as breaking news. Each case study will take one reported breach or cyber incident and explain what happened, how it happened, what the organisation and the people affected did next, and what a reader can learn from it. Alongside the case studies, the library carries explainers on threat intelligence and short notes on industry developments — changes in the law, new guidance from public bodies, and shifts in how attacks work.
The rules for incident coverage
Four rules govern every case study we will publish. First, confirmed facts only: a fact goes in when the affected organisation, a court, a regulator, or at least two independent reliable sources state it, and we link to the source. Second, allegations are labelled as allegations: if something is claimed but not confirmed — who did it, how many people were affected, whether a ransom was paid — the page says "alleged", "reported" or "unconfirmed", never presenting it as settled. Third, sources are named: no anonymous claims, no "sources say" without a link you can follow. Fourth, dates on every case: when the incident happened, when it was disclosed, and when our page was last checked.
Two further lines are absolute. We never name a private individual as a criminal without a charge or conviction on the public record, and we never attribute an attack to a person, group or country on unproven claims. Attribution is the most common way incident coverage goes wrong, and it is where our bar is highest.
What threat intelligence is, in plain English
Threat intelligence is organised knowledge about the threats that actually exist — a checked, dated answer to a practical question: what should we patch, watch or change now? It starts with facts — a vulnerability with a CVE number, a phishing technique being used against a particular sector, a ransomware group changing its methods — and adds context: who is affected, how serious it is, and what evidence supports the claim. News tells you something happened; intelligence tells you what to do about it.
You do not need to work in security to benefit from it. The explainers here are written for readers who want to understand the reports they see in the news — what a CVE means, and how security teams decide what to patch first.
What readers will find here
Three kinds of pages live in this library now. Breach case studies work through one reported incident at a time, with a timeline, the confirmed facts, and the lessons for ordinary readers. Incident analysis explains the techniques behind the headlines — how a phishing campaign worked, or how a supply-chain compromise spread — without publishing instructions that could be used to repeat the attack. Industry developments will cover changes that matter to readers: new laws, new official guidance, and honest corrections when earlier reporting turns out to have been wrong.
How to read breach news critically
Breach reporting is often wrong in the first hours, and the corrections rarely travel as far as the original story. Three checks will catch most of the errors:
- Who is saying it? The affected organisation, a regulator or a court is a primary source; a single anonymous account or a screenshot with no link is not. If the only source is a post you cannot verify, treat the story as unconfirmed.
- What is actually confirmed? Separate the three different claims that get mixed together: that a breach happened, what data was taken, and who did it. Often the first is confirmed while the second and third are still speculation — and the headline will not say so.
- When was this written? Check the date, and check whether the page has been updated since. Early figures for the number of people affected are almost always revised, and a story from the first day is not the final picture.
Where to go next
While the case studies are being written, the background is already here: the guides explain the attacks, the glossary defines the terms, and our policies show how every claim is checked.
Background reading
Every page below is live now. Start here to understand the attacks and terms the case studies will refer to.
-
Cybersecurity
Threats, simply explained
Phishing, malware, ransomware, breaches and passwords — the attacks behind the incidents this library will study.
-
Glossary
Terms the reports use
CVE, SOC, OSINT, breach, ransomware — plain-English definitions for the vocabulary of incident reporting.
-
Online Safety
What to do if it happens to you
Practical safety steps for scams and breaches, and how to protect kids, seniors and the whole household.
-
How we work
Research Methodology
Primary sources first, two independent sources for contested claims, and dated verification on every page.
-
How we work
Fact-Checking Policy
How every factual claim on this site is checked before publication — and corrected afterwards if it is wrong.
-
Learning Paths
Threat Intelligence Introduction
A structured path into threat intelligence, from CVEs to reading incident reports critically.
Case studies in this library
Confirmed-only case studies of reported incidents.
-
Guide
Change Healthcare Ransomware Attack 2024
The Change Healthcare ransomware attack of February 2024 explained: the Citrix portal without MFA, 190 million people affected, and the $22 million ransom.
-
Guide
Colonial Pipeline Ransomware Attack 2021
The Colonial Pipeline ransomware attack of May 2021 explained: how DarkSide got in, why the pipeline shut down, the ransom and what changed after.
-
Guide
Equifax Data Breach 2017: What Happened
The Equifax data breach of 2017 explained: what happened, the unpatched flaw behind it, the 147.9 million people affected, and the lessons confirmed since.
-
Guide
National Public Data Breach 2024 Explained
The National Public Data breach of 2024 explained: 272 million Social Security numbers exposed, and why a data broker you never heard of held your data.
Frequently asked questions
What case studies are in the library?
Four confirmed-only case studies are live now: Equifax (2017), Colonial Pipeline (2021), Change Healthcare (2024) and National Public Data (2024). Each one separates confirmed facts from allegations, names its sources, and carries a date.
What counts as a confirmed fact in your coverage?
A fact that is stated by the affected organisation, a court, a regulator, or at least two independent reliable sources — and that we can link to. Anything short of that is labelled as an allegation, a report, or unconfirmed, and never presented as settled.
Will you publish leaked data or indicators from a breach?
No. We never publish leaked credentials, breach dumps, live indicators of compromise, or personal data from a breach. Case studies describe what happened and what can be learned from it — they do not reproduce the stolen material.
What is threat intelligence, in plain English?
It is organised knowledge about the threats an organisation actually faces: which vulnerabilities are being used, which groups are active, and what to do about it. The difference from news is that intelligence is checked, dated, and tied to a decision — what to patch, what to watch, what to change.