BreachCensus

Methodology

Breach Census is built from a claim→outcome lifecycle: every confirmed incident, cost figure and regulator action shown on the site carries a citation back to a source document, and a claim is never allowed to look the same as a confirmed fact.

The confirmation ladder

Every incident-related fact on the site carries one of five confirmation levels, in ascending order of certainty:

  1. Claim — someone or something (typically a ransomware group’s own leak site) says an organisation was compromised. Reproduced as posted, on the Threat groups page only, and never treated as fact.
  2. Press reported — a news outlet reported the incident, but no self-report, regulator filing or court record has been found yet. Still not enough to confirm.
  3. Self report — the organisation itself disclosed the incident (an SEC 8-K Item 1.05 filing, a state attorney general breach notification, a public statement). Confirms the incident.
  4. Regulator — a data-protection or financial regulator (ICO, CNIL, FCA, PRA, a US state AG in an enforcement capacity) took or published an action tied to the incident. A filing on an official register, not a press release about one. Confirms the incident.
  5. Court — a court record (via CourtListener/RECAP) ties litigation to the incident. Confirms the incident.

An incident’s confirmed flag is only true once at least one event on it reaches self-report, regulator or court. A bare claim or press report is not enough: the incident is forced to noindex, shown with an explicit “claimed victim (as posted), unverified” label, and the page is not allowed to use breach-asserting language (“was breached”, “suffered a breach”) against it.

The claim-only rules

A handful of rules keep an unverified claim from ever looking like, or becoming, a confirmed breach:

  • A leak-site claim never creates an organisation page on its own — see “How entities are resolved” below.
  • No breach-asserting language is used against a claim-only or press-only incident; it is always labelled a claim, as posted, unverified.
  • Threat groups and Vendors stay noindex by design while they hold only claim-derived material — they only become indexable once a confirmed incident actually backs them.
  • Anyone named on a claim-only page has a right of reply — see Contact.

Records affected vs. residents affected

“Records affected” on an organisation or incident page is the organisation’s own reported total for that incident. A US state attorney general breach notice (California, Washington, Texas, Massachusetts, New Hampshire, Vermont) reports something narrower: residents of that one state who were notified — not the organisation’s total. That state-residents figure is kept in a separate field and is never added into records affected, so a national total is never quietly inflated by re-counting the same incident state by state.

State attorney general jurisdictions

Six US states publish their own breach-notification register and are ingested directly: each has its own statute, its own rule for when the Attorney General must be notified, and its own definition of what the published “affected” figure counts. This is the same data that backs the “What a <state> notice means” box shown on an incident card — one set of facts, not two that could drift apart.

  • Massachusetts — M.G.L. c. 93HNotice to the Attorney General is required for a breach affecting any number of Massachusetts residents' personal information -- the statute sets no minimum count. Published counts: the count is Massachusetts residents only, not a total. Massachusetts breach-notification register ↗
  • California — Cal. Civ. Code §1798.82A copy of the notification must be sent to the Attorney General when a single breach requires notifying more than 500 California residents. Published counts: no affected-count is published on this register. California breach-notification register ↗
  • Washington — RCW 19.255.010Notice to the Attorney General is required when a breach affects more than 500 Washington residents. Published counts: the count is Washington residents only, not a total. Washington breach-notification register ↗
  • Texas — Tex. Bus. & Com. Code §521.053Notice to the Attorney General is required when a breach affects at least 250 Texas residents. Published counts: the published count is a total, not limited to Texas residents. Texas breach-notification register ↗
  • Vermont — 9 V.S.A. §2435Notification to the Attorney General is required. Published counts: the count is Vermont residents. Vermont breach-notification register ↗
  • New Hampshire — RSA 359-C:20Notification to the Attorney General is required. Published counts: the count is New Hampshire residents. New Hampshire breach-notification register ↗

Sources

How entities are resolved

An organisation is only created or matched against a registry identifier — a US SEC Central Index Key (CIK), a UK Companies House number, or a Legal Entity Identifier (LEI) — or against a name that is globally unique across the register. Where a name match is ambiguous (more than one live candidate survives), it is refused rather than guessed, and the row is queued for manual review instead of being attached to the wrong organisation. This is also what keeps a leak-site claim from ever manufacturing a page: entity creation only happens through registry-id or globally-unique-name resolution, never from a claim alone.

Freshness

Ingest jobs for each source run on a daily cron schedule. The totals on the weekly report are live and recomputed on every request; each Monday a frozen snapshot of that week’s totals is published and never changes again, so a past week’s report always matches what was true that week.

Frequently asked questions

Why is an organisation listed with no details?

Some incidents are confirmed by a single source document — a state attorney general notice or a regulator filing — that itself says little beyond an organisation name, a date and a headline figure. The page shows what the source shows; nothing is invented to fill it out.

Why isn't a threat group's claim shown as a breach?

A ransomware or extortion group posting a victim on its own leak site is a claim, not a confirmation. Claims are reproduced on the Threat groups page as posted, labelled unverified, and never promote an incident to confirmed on their own — see the confirmation ladder below.

How do I correct or remove an entry?

Email [email protected] with the page URL, what is wrong, and a source for the correction. See the Contact page for the full right-of-reply process.

What does 'confirmed' mean?

An incident's confirmed flag is only true when at least one event on it carries a self-report, regulator or court confirmation level — a bare claim or press report is not enough.

Where does the data come from?

Public regulator filings, court records and company disclosures — HHS OCR, SEC EDGAR, US state attorneys general, the ICO, CNIL, the FCA and PRA, CourtListener, CISA KEV / NVD, and ransomware-group leak-site trackers. See the source list below.

Can I use the data?

Yes. Derived signals, narratives and aggregates are CC BY 4.0 with attribution to breachcensus.com — see Developers for the free JSON and CSV endpoints and the full dataset export.

Why does a company from a leak-site claim not get its own page?

A claim is never allowed to manufacture an organisation page on its own. An entity is only created by matching a registry identifier (SEC CIK, Companies House number, LEI) or a globally unique name — an unresolved or ambiguous name is refused, not guessed.

Why aren't Massachusetts, Washington or other state figures in a national total?

A state attorney general notice counts residents of that state who were notified, not an organisation's total records affected. That state-residents figure is never summed into records_affected — the two are kept in separate fields so they are never mixed.