Methodology

What counts as a data incident

A specific, publicly reported event in which personal data was, or may have been, accessed, disclosed, lost, altered or made available without authorisation, at a named or identifiable organization. Fines, enforcement notices, lawsuits and court cases that follow such an event, or that concern a failure to protect personal data, count too. That covers:

• ransomware and extortion attacks that reached personal data
• hacking, intrusion and account takeover
• malware, skimming and credential theft
• phishing and social engineering
• databases, storage and documents exposed by mistake
• misuse or error by employees and contractors
• breaches at vendors, processors and suppliers
• lost or stolen devices and paper records
• regulatory action and litigation about personal data protection

What does not qualify

Reports that describe no specific event are held back. That covers:

• commentary, analysis and opinion pieces
• legislation, proposed laws and policy debate with no specific case
• general warnings, forecasts and surveys about breaches as a whole
• reports that the classification rules cannot place in any of the categories
• duplicate reporting of the same event, once it is found

Sources

The current dataset is built from posts on DataBreaches.net, an independent site that reports breaches, leaks and related enforcement. Each record links the post it came from and up to five of the outside sources that post links to, such as the organization's own notice, a regulator's publication, a court filing or other press coverage.

Regulator sources, such as data protection authority decisions and breach notification portals, are the next sources to be added. A link to another breach database is a cross-reference, never evidence.

Post text is not republished. A record carries the report's title, its date, its sources and a short opening excerpt, and links to the original for everything else.

How a record is made

A script reads each report and keeps it when it describes a qualifying event. The script tidies the title, takes the publication date, links the sources, and assigns one of the 9 categories using fixed keyword rules applied to the report's title, tags and section. Where the report's section names a sector, such as health, education, government, business or finance, the record carries that industry.

Nothing in that step checks the facts. The category comes from keywords and can be wrong, the organization and country are not yet extracted, and the date on a record is the date of the report it was built from, which can be later than the breach itself.

An editor reviews a record against its sources before their name appears on it. No record in the current dataset has been reviewed by an editor yet. Every record shows that it is unreviewed, and none names a reviewer.

Evidence status

Every record carries one evidence status. A record built from a single report starts as Reported and keeps that status until stronger evidence is cited or an editor changes it. The statuses are:

• Confirmed: A court, a regulator or the organization itself has stated the core facts, or the record cites a court or regulator source.
• Well documented: Three or more independent publishers report the core facts.
• Reported: Reported by fewer than three independent publishers, with no official finding.
• Under investigation: A regulator, court or police has opened a formal inquiry and reached no finding yet.
• Alleged: The record is a lawsuit, complaint or accusation that has not been decided.
• Disputed: Material facts are contested by a named party.
• Corrected: Earlier reporting was materially wrong and the record reflects the correction.

Unreviewed records

An unreviewed record has been built automatically and has not been checked by a person. Its page says so, it names no reviewer, and it claims no review. Treat it as a pointer to its sources rather than a finding: read the linked reporting before relying on it.

Deduplication

Multiple reports of the same underlying event should become one incident record. Records are built one report at a time, so the same event can appear more than once until duplicates are merged. The old URL of a merged or renamed record redirects to the current one.

Record identifiers

Every record carries a first-party reference of the form DII-2026-00001: the year of the report and a sequence number within that year. The identifier of the source post is stored alongside it as a cross-reference.

Classification

Each record receives one primary category from the public taxonomy, based on how the breach happened or, for enforcement and court records, on the action taken. Where the sources support them, a record can also carry an industry, the organizations involved, a country and the data protection laws it cites. GDPR and UK GDPR come first; India's Digital Personal Data Protection Act, 2023 follows.

Corrections

Anyone, including the organizations named in a record, can submit a correction, response or updated source without charge. Record removal is never sold, and payment is never accepted to change an evidence status.

Updating records

New evidence can change a record's status, classification or summary. A reviewed record shows when it was last reviewed.

Limitations

The Data Incident Index is not a comprehensive measure of all data breaches worldwide. Many breaches are never reported publicly, notification rules differ by country and sector, and the current dataset comes from one publication. Counts should therefore be interpreted as documented incidents in this dataset, not as estimates of how often breaches occur.