Breach Intelligence Methodology

Patient Protect Breach Intelligence reports canonical breach events: reconciled representations of individual real-world breaches, built from public source records. This page specifies how that reconciliation works, what each figure counts, and where the method reaches its limits.

Canonical model: CDM v1.1
Canonical events: 2,153
Data through: 2026-08-21
Last reviewed: 2026-08-24

Source records

A source record is one immutable assertion by one source: a breach notification filed with a regulator, an enforcement action, a security advisory. It records what that source said, when it said it.

A source record is not a breach. One breach commonly produces several records — an initial filing, a revision, notifications to more than one jurisdiction, a later enforcement action — and some records describe no breach at all.

Canonical breach events

A canonical breach eventis Patient Protect’s reconciled representation of one underlying breach, produced by Canonical Data Model v1.1. Where several source records describe the same breach, they resolve to a single event, and that event is counted once.

Reconciliation is deterministic: the same records produce the same events regardless of the order in which they are processed. It uses the entity a record names, the timing of the filings, and the magnitude of the figures they assert. It does not merge records because their text looks similar.

Currently 2,339 breach source records resolve to 2,153 canonical breach events.

Why source totals differ from ours

Aggregating a source-record feed directly will not reproduce these figures, and can materially misstate them. There are five distinct reasons, and they compound.

Multiple filings per breach. A revision or a second notification adds a record without adding a breach.
Mixed record classes. A feed that contains enforcement actions alongside breach filings will overstate breach volume if every row is counted as a breach.
Multi-jurisdiction reporting. One breach notified to several states appears once per jurisdiction.
Entity resolution.One organisation may file under a legal name, a trading name and a subsidiary. Until those are resolved to one entity, its breaches look like several organisations’ breaches.
Population scope. Affected counts do not all describe the same population, so summing them mixes units. See affected counts.

Aggregation audit · 24 August 2026

A point-in-time illustration, not a current figure. On that date, counting every row of the open source-record feed as a breach overstated breach volume by roughly 2.4×, because most rows were regulatory actions rather than breach filings. Summing the affected column across all rows overstated the reconciled total by roughly 6×.

Deduplicating by the feed’s own grouping key without first filtering by record class still overstated it by roughly 2.6×. The lesson is the ordering: class first, then grouping. The magnitudes will change as the corpus changes; the failure mode will not.

Record classes

Every record is classified, and the class determines which metrics it can contribute to.

Class	What it is	Counts as a breach event
Confirmed breach	A breach notification filed with a regulator.	Yes
Regulatory action	An enforcement action, resolution agreement or civil money penalty. It concerns a breach; it is not a report of one.	No
Security advisory	A vulnerability or threat advisory. Context about risk, not a record that a breach occurred.	No
Community signal	A report from a practitioner network. Contextual, unverified against a primary source.	No
Modeled signal	An algorithmic projection derived from reporting. Pre-confirmation by construction.	No

Only confirmed breaches produce canonical breach events. The other classes are held, counted and displayed separately — they are not discarded, and they are never folded into a breach total. Patient Protect currently holds 3,117 regulatory actions, none of which increments a breach count.

Canonical entities

Organisations file under inconsistent names. Resolving them is necessary — an unresolved entity splits one organisation’s breaches across several apparent organisations — but it is also where a reconciliation layer can most easily invent a relationship that does not exist.

Patient Protect therefore merges names only on deterministic, documented relationships:

Trading and legal names.Where an authority or the organisation itself states that one is the other’s name — a “doing business as” relationship, or a corporate rename — the two are one entity.
Umbrella brands. A brand covering several legal entities is resolved for a single event where the evidence supports it, and never treated as a blanket synonym. A parent is not a synonym for its subsidiary.

There is no fuzzy matching, no string-similarity threshold and no automatic merging of names that merely look related. Each alias records the authority that states the relationship, and each is reversible under review.

Persistent event identity

Every canonical breach event carries a durable Patient Protect event identity. It is opaque: it encodes nothing about the organisation, the date or the size of the breach, which is precisely what allows it to survive those things changing.

An identity persists as further source records are reconciled into its event. When a later filing arrives and the event grows, the identity is unchanged and the change is recorded.

When evidence changes how records should be grouped

Reconciliation is a reading of the evidence, and evidence accumulates. Later records can show that two events were one, or that one was two.

When that happens, Patient Protect preserves identity history rather than silently reusing an identifier for a different event. A merged identity is marked as superseded and points to the event that absorbed it, so a reference made a year ago still resolves to the right breach. An identity whose evidence is withdrawn is retired rather than deleted, and is restored — not replaced — if that evidence returns. Identifiers are never reused.

Affected counts

“Reported affected” is the most easily misread figure in this system, so it is worth being exact about it.

Sources assert affected counts against different populations:

Event total. Everyone the breach affected, anywhere.
Jurisdiction resident total. Only the residents of the state to which that notification was made.
Unknown scope. The source states a number without saying which population it describes.

Where sources disagree, the disagreement is recorded rather than averaged away, and where it cannot be resolved the event is marked as such. For aggregate metrics Patient Protect selects one analytic assertion per event — the best-supported event-total figure — and sums those. It never adds two assertions about the same event together.

Reported affected is not a count of unique people. It sums one reported total per breach event. Someone affected by two breaches is counted in both, and no source publishes the person-level data that would be needed to deduplicate across events.

Geography

A state attorney general publishing a breach notice establishes that the breach was reported there. It does not establish that the incident happened there, and it does not by itself establish that residents of that state were affected — the notice may be a courtesy filing.

Reporting jurisdiction is therefore not event identity. One breach notified to several states is one event, appearing in each of those state views.

State event counts do not add up to the national total. Adding them double-counts every breach reported in more than one jurisdiction — which is disproportionately the largest breaches. Each state page counts events with a filing naming that state; the national figure counts distinct events.

Confidence

Each canonical event carries a confidence level — High, Moderate or Limited evidence — describing how well the evidence supports the reconciliation: whether the entity resolved cleanly, and whether the sources agree on what they assert.

Confidence is not:

the severity of the breach;
a measure of compliance risk;
a probability that a breach will occur.

A large, serious breach reported once and unambiguously is High confidence. A small breach whose sources contradict each other is Limited evidence. The two say nothing about each other.

Current distribution: 2,080 high, 31 moderate, 42 limited evidence. 16 events have sources that disagree on an affected count.

Open dataset vs canonical analysis

These are two different products and the distinction matters more than any other on this page.

Open dataset

Source records

/breach-dataset and the CSV/JSON endpoint. The underlying public evidence, as published, licensed CC BY 4.0. It contains no canonical events and no Patient Protect event identities.

Breach Intelligence

Canonical events

/breachdash and the state analytics. Patient Protect’s analytical layer, built by applying CDM v1.1 to those records.

Canonical Data Model v1.1 is a Patient Protect analytical layer. Grouping the open feed by its own grouping key does not reproduce it, and does not approximate it — the two operate on different rules over a different set of records.

The CC BY 4.0 licence covers the open source-record dataset. It does not extend to the canonical analytical layer, which is not published as an open dataset. Underlying government records retain their own status in either case.

Two kinds of event identifier

The open dataset carries a source event grouping identifier assigned upstream, which groups records describing one filing event. It is useful for deduplicating rows within that file.

It is not a Patient Protect canonical event identity, and the two are not interchangeable. The canonical identity is produced by the reconciliation described above, across a wider set of records, and persists through merges and revisions. Grouping by the upstream key yields a different number of groups than the model yields events.

HIPAA Response

A Response is a separately verified interpretation: what a particular development means operationally for an independent practice. It is a layer above the data, not a part of it.

Not every event receives a Response — most do not — and not every Response concerns a breach event. Regulatory developments, enforcement actions and advisories can each warrant one, and those have no canonical breach event by construction.

A Response about a breach records both its relationship to the canonical event and the specific source records it was written from. A Response may only name a primary authority as its source of record where its stored evidence resolves to a record from that authority.

Data freshness

Three different dates, deliberately not merged:

Source retrieval. When Patient Protect last fetched from the sources. Currently daily.
Data through. The most recent date the corpus actually covers — currently 2026-08-21. This lags retrieval, because authorities publish on their own schedules.
Canonical model version. Currently v1.1. Figures produced under different model versions are not directly comparable.

This is not real-time data and is not presented as such. Breach notification deadlines are measured in weeks, publication lags filing, and an incident frequently becomes public months after it occurred.

Known limitations

These are properties of the method and the sources, not defects awaiting a fix.

Reporting lag. A breach appears when it is filed, not when it occurred. Recent periods are always incomplete, and a fall in recent counts usually reflects filing lag rather than fewer breaches.
Incomplete and conflicting source fields. Some filings omit dates, counts or mechanism. Sources sometimes contradict each other. Neither is invented or averaged away.
Unresolved entity ambiguity. Where a relationship between names cannot be established deterministically, the names stay separate — which understates concentration for those organisations.
Events without usable geography. Some events carry no state on any record and appear in no state view, while still counting nationally.
No person-level deduplication. Affected totals cannot be deduplicated across events. No source publishes the data that would make it possible.
Coverage windows differ by source. Enforcement and breach reporting have different histories and different thresholds, so comparing their volumes over time compares two different collection regimes.
Modeled and community records are contextual. They indicate that something may have happened. They are never counted as confirmed breaches.

Model revision history

CDM v1.0 — initial canonical model: Established the separation between source records and canonical events: reconciliation of multiple filings into one event, canonical entity resolution on documented relationships, jurisdiction roles, and population scope for affected counts.
CDM v1.1 — order-invariant deterministic resolution: The v1.0 rules did not always produce a unique answer: the order in which records were processed could change how they were grouped, and therefore change national totals. v1.1 replaces that with resolution that is provably independent of processing order, so the same records always yield the same events. It also introduced durable event identity, described above.

Questions about this methodology, or a correction to it, are welcome. See editorial standards for how we handle corrections, and Breach Intelligence for the data itself.