Data Breach: Data Point Intelligence Guide

A breach is not a single event, it is a dataset with a life of its own. The incident ends in weeks; the records circulate for a decade.

Understanding the Data Breach as an intelligence artifact

A data breach data point is a specific incident in which records held by an organisation were exposed, exfiltrated or published. As an artifact it has a defined shape: the breached entity, the discovery and disclosure dates, the estimated record count, the data classes exposed, the attack vector where known, and the provenance of any circulating dataset. Analytically the incident and the dataset are separate objects, because one breach can produce several differently packaged corpora that surface years apart.

Datasets mutate as they circulate. Original dumps get reformatted, deduplicated, merged into combolists and republished under new names, which inflates apparent record counts and destroys provenance. Some breaches are never confirmed by the named entity, some are credential-stuffing artefacts misattributed to a company, and some are wholly fabricated to build seller reputation. Distinguishing a first-party breach from an aggregation is the core analytical task.

Why it matters

Breach data drives exposure assessment for your own organisation and third parties, supports victim notification obligations, and provides investigators with historical identity and relationship data. It explains how intrusions began, since exposed credentials and personal data are inputs to later attacks. For risk teams, the pattern of breaches across a supply chain is a measurable indicator of a vendor's control maturity, and the regulatory record around each incident is publicly documented.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Data classes exposed, which determine notification obligations and the realistic downstream harm to affected individuals.
Record count versus unique identity count, which usually differ by a large margin once duplicates and aggregations are removed.
Time between compromise, discovery and disclosure, which is a direct indicator of the organisation's detection maturity.
Hash algorithms protecting stored credentials, which determine whether exposed passwords are effectively plaintext or genuinely protected.
Presence of internal fields such as account creation dates or system identifiers, which help authenticate a first-party dump.
Distribution path and timing, including leak site posting, forum sale, or bulk release, which indicates actor motive and negotiation status.
Overlap with previously known corpora, which distinguishes a genuine new breach from repackaged historical data.
Regulatory and litigation footprint, including notification filings and enforcement action, which corroborates scope independently of the seller.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

Have I Been Pwned — Curated, verified breach catalogue with data classes, dates and free domain-level exposure search for owned domains
DeHashed — Commercial breach record search across many corpora, used under contract for lawful exposure assessment
US state attorney general breach portals — Official notification filings, notably California and Maine, giving confirmed dates, causes and affected counts
HHS OCR Breach Portal — Mandatory US healthcare breach reporting with entity, record count, breach type and investigation status
SEC EDGAR 8-K Item 1.05 — Material cybersecurity incident disclosures by US-listed companies with dated, attributable narrative detail
ICO enforcement register — UK regulatory findings and penalties describing breach causes and control failures in detail
Ransomware.live — Leak site postings identifying claimed victims and publication dates ahead of formal disclosure

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Separate incident from dataset — Record the breach event and any circulating corpus as distinct objects with their own provenance, dates and confidence levels.
Verify the claim independently — Corroborate against regulatory filings, the entity's own statements and reporting before accepting a seller's or forum claim.
Assess authenticity structurally — Examine schema, field consistency, internal identifiers and hash formats to distinguish a first-party export from an aggregated combolist.
Deduplicate against known corpora — Compare the corpus against previously catalogued datasets and internal records to establish what is genuinely new rather than recycled or repackaged.
Scope your own exposure — Use domain-level services and internal records to determine which of your identities and third parties appear, without ingesting unnecessary data.
Drive defensive action — Force credential resets, revoke sessions, tighten monitoring on affected accounts and notify individuals where obligations apply.
Track the regulatory tail — Follow notifications, enforcement and litigation, which reveal root cause detail that initial disclosure almost never contains.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

Criminal Intelligence — Intelligence Supporting Criminal Investigation
Breach Intelligence — Exposed Credentials and Compromised Data
Cyber Intelligence — Adversary Activity in Networks and Systems
Threat Actor Intelligence — Tracking Adversary Groups Over Time
Dark Web Intelligence — Hidden Services and Closed Criminal Venues
Financial Intelligence — Following Value Through the Financial System
Cryptocurrency Intelligence — Tracing Value on Public Ledgers

Investigated in these domains

Pivots to these data points

File Hash — Cryptographic fingerprint of a file, used for malware identification.
CVE / Vulnerability — Common Vulnerabilities and Exposures identifier for a known flaw.
SSL/TLS Certificate — A digital certificate binding a public key to an identity.
Malware Family — A named class of related malicious software.
File / Document — A file or document artifact — malware sample, leaked document, image, or email attachment.
Onion / Hidden Service — A Tor hidden service address on the dark web.

Inside the platform: where Data Breach lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

datapoint.php?dp=dp_breach — Data point hub
ioc.php — Cyber Crime dashboard
domain.php?d=darkweb — Dark Web Intel dashboard
blockchain.php — Fraud & Identity dashboard
domain.php?d=healthcare — Healthcare & Drug Security dashboard
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Enrichment Runner
Enrichment → Local
Correlate Infrastructure
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Separate incident from dataset is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Assess authenticity structurally turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Track the regulatory tail feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Data Breach

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Breach data supports personnel security and supply chain risk in defence. Exposure of a defence contractor drives an assessment of what programme data or access was at risk and whether the incident creates a route into mission networks. Exposure of personnel records, particularly where it includes identity documents or clearance-adjacent detail, feeds counter-intelligence referrals and personal security advice to affected individuals, including protective guidance for those in sensitive roles. The constraint is that a breach affecting a supplier is legally and operationally the supplier's incident: your product is a risk assessment and a set of contractual and protective actions, built where possible on regulatory filings and confirmed disclosures rather than on possession of the stolen corpus.

🕵 National intelligence

For national intelligence, breach corpora are simultaneously a collection opportunity, a counter-intelligence risk and a legal problem. Requirements-driven questions include which national entities have been compromised, whether a hostile service is assembling identity data at scale, and whether a specific incident matches the tradecraft of a tracked actor. Handling requires care: acquired corpora of criminal origin carry acquisition, retention and dissemination constraints, and their use to identify or profile individuals is governed by domestic law. Fusion pairs the incident with attribution reporting, infrastructure analysis and the regulatory record. Assessments should separate the confirmed incident from the circulating dataset, because those have different provenance and different confidence.

👮 Law enforcement

In law enforcement the breach is an offence and the dataset is evidence. Investigation focuses on the intrusion itself: initial access, exfiltration, the actor's infrastructure, and the sale or publication of the data, with evidence obtained from the victim under consent or warrant and from providers under production orders or mutual legal assistance. The circulating dataset supports victim identification and notification but requires careful handling because it is stolen property and contains third-party personal data. Record how any corpus entered the investigation, who authorised it, and what filtering was applied. Charging decisions typically rest on the intrusion and the subsequent trafficking rather than on the dataset's contents.

🔍 Private investigation and corporate security

Corporate security uses breach data for third-party risk, incident scoping and litigation support. Regulatory filings, the entity's own statements and reputable catalogues give a defensible picture of a supplier's incident history without touching stolen data. In litigation and insurance disputes, the question is usually what the organisation knew and when, so the regulatory record and disclosure timeline matter more than the corpus. What a private actor may not do is buy stolen data, download corpora containing third-party personal data without a lawful basis, or use exposure data to profile individuals. Prefer indirect assessment services that answer exposure questions without transferring records to you.

📰 Journalism and OSINT media

Breach reporting is a verification discipline. A seller's claim on a forum is not a breach, and a great deal of what circulates is repackaged aggregation or outright fabrication built to establish a vendor's reputation. Corroborate against regulatory filings, the named entity's own statements, and independent technical assessment of the data's structure. Where you obtain a sample, examine schema and internal consistency rather than reproducing records. Never publish personal data from a corpus, give the named organisation a genuine right of reply with time to respond, and consider the harm to individuals whose data is in the set, who are victims rather than subjects of the story.

🌍 NGO, humanitarian and human rights

For civil society, breach exposure is a protection issue. Staff, partners and beneficiaries whose data appears in circulating corpora face targeted phishing, harassment and, in repressive contexts, physical risk. The response is notification, practical mitigation and support rather than collection: help affected people change credentials, enable phishing-resistant authentication and understand what is exposed. Do not ingest corpora containing beneficiary data in an attempt to assess exposure, because that recreates the harm inside your own organisation. Use domain-level exposure services instead. Where a breach affects a persecuted community, treat the incident as a security emergency with a communications plan in the affected community's language.

🎓 University and research

Breach research covers disclosure economics, notification effectiveness, credential reuse and the market for stolen data. Ethics review is essential and institutions increasingly have explicit policies on unlawfully obtained data. The defensible designs work on metadata rather than content: analysing breach announcements, regulatory filings, data class distributions and timelines rather than individual records. Where record-level analysis is unavoidable, use vetted access arrangements, aggregate before publication and never republish records. Pin dataset versions and query dates, since catalogues are revised as claims are verified or debunked, and report which corpora were excluded and why so the sample is assessable.

Playbook: working Data Breach end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Separate the incident from the dataset

Create two objects with independent provenance, dates and confidence: the breach event at a named entity, and each circulating corpus claiming to derive from it. One incident can produce several differently packaged datasets appearing years apart, and one corpus can aggregate dozens of incidents. Conflating them produces inflated record counts and wrong attribution. A good output is a data model where a corpus links to zero or more incidents with a stated confidence per link, rather than a single row asserting both.

Phase 2 — Verify the claim against primary sources

Corroborate a claimed breach against the entity's own statement, regulatory filings, state attorney general notification portals, sector regulators and reputable reporting before accepting a seller's or forum claim. Absence of confirmation is not disproof, but it changes confidence materially. A good output is a verification record listing each source checked and what it said, with dates. Stop and mark the claim unverified rather than repeating it, because unverified breach claims propagate rapidly and are difficult to retract.

Phase 3 — Assess authenticity structurally

Where a sample is lawfully available, examine schema coherence, field naming conventions, internal identifier ranges and sequences, hash formats and password policy artefacts, and date distributions. A genuine first-party export looks like a database dump from one system; an aggregation looks like a merged spreadsheet with inconsistent field semantics. A good output is an authenticity assessment listing the specific structural evidence. Note that a fabricated set can be structurally plausible, so this test discriminates aggregation from first-party far better than it detects fabrication.

Phase 4 — Deduplicate against known corpora

Compare against previously catalogued datasets to establish what is genuinely new versus recycled, since the same records reappear under new names repeatedly and each republication inflates apparent scale. Record overlap percentages rather than a binary judgement. A good output is a statement of how much of the corpus is novel and what it overlaps with. This step is what prevents an organisation from running a full incident response cycle on a repackaged set it already handled two years ago.

Phase 5 — Scope your own exposure indirectly

Determine which of your domains, identities and third parties appear using domain-level exposure services and your own records, rather than ingesting the corpus. The exposure question is answerable from identifiers and metadata alone. A good output is a list of affected internal accounts and suppliers with the data classes involved. Stop and take legal advice before ingesting any corpus directly, and where ingestion is genuinely necessary, minimise fields, restrict access and set a short retention period.

Phase 6 — Classify data classes and impact

Establish precisely which categories were exposed, because the response differs sharply: email addresses drive phishing risk, credentials drive account takeover risk, government identifiers drive identity theft risk, and health or biometric data drive special category obligations and long-term harm. A good output is a data class inventory with the corresponding obligations and mitigations per class. This is the analysis that determines notification duties, so it should be done before the communications drafting rather than after.

Phase 7 — Drive defensive action

Force credential resets and, critically, revoke active sessions and refresh tokens for affected accounts, tighten monitoring, enforce phishing-resistant multi-factor authentication and screen new passwords against compromised-password lists. Where the exposure involves an infostealer log rather than a service breach, treat the endpoint as compromised and rebuild it. A good output is a completed action list per affected account with verification. Stop treating a password reset alone as remediation, because stolen session material remains usable after a reset.

Phase 8 — Discharge notification obligations

Identify which regimes apply by data class and by the residence of affected individuals, then meet the deadlines, which in several regimes run from awareness rather than from confirmation. Notification content should tell people what was exposed, what the specific risks are and what to do, in plain language. A good output is a notification record showing who was told, when and what they were told, retained for the regulator. Involve counsel early, because the assessment of whether notification is required is a legal judgement.

Phase 9 — Assess third-party and supply chain exposure

Map which suppliers, processors and downstream partners are implicated, since a large share of significant incidents originate at a third party. Check contractual notification obligations, request the supplier's incident report, and assess whether your data was in scope. A good output is a supplier risk record updated with the incident, the supplier's response quality and any contractual remedies. Repeated incidents at one supplier with weak responses is a procurement decision, not a security metric.

Phase 10 — Investigate root cause where you can

For your own incidents, establish initial access, dwell time, exfiltration method and the control failures that allowed each stage, and record what would have detected it earlier. For third-party incidents, the regulatory tail often reveals root cause detail that initial disclosure never contains. A good output is a root cause statement with specific control changes and owners. Stop at the point where the analysis becomes speculation about the actor rather than evidence about the failure.

Phase 11 — Track the regulatory and litigation tail

Follow enforcement actions, regulator decisions, class litigation and securities disclosures over the following months and years, because these produce the most reliable technical and organisational detail available about any incident. Filings and enforcement notices frequently state exactly what failed. A good output is a monitored case record that updates the initial assessment as the record develops, and that feeds concrete lessons into your own control set rather than remaining an interesting file.

Phase 12 — Handle and retire the data

Where any corpus was lawfully ingested, restrict access to named responders, encrypt at rest, log every query, minimise retained fields to those serving the documented purpose, and delete on a short defined schedule with verifiable destruction. Never use the data to contact, profile or enrich individuals beyond the notification duty being discharged. A good output is a destruction record and an access log that maps every query to an authorised purpose. This is the step that determines whether your response created a second breach.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
Have I Been Pwned	Open	Curated and verified breach catalogue with per-incident data classes, dates and free domain-level search for owned domains.	The primary lawful way to assess organisational exposure without ingesting any stolen corpus.
HHS OCR Breach Portal	Open	Mandatory US healthcare breach reporting with covered entity, affected count, breach type and investigation status.	Authoritative confirmation and detail for healthcare sector incidents affecting five hundred or more individuals.
State attorney general breach notification portals	Open	Official notification filings, notably California and Maine, giving confirmed dates, causes and affected resident counts.	Primary source confirmation of a claimed breach, frequently the earliest official record available.
SEC EDGAR	Open	US registrant filings including material cybersecurity incident disclosures and subsequent risk factor and litigation detail.	Confirms materiality assessments and timelines for incidents at listed companies, with dated legal consequences.
Information Commissioner's Office enforcement	Open	UK regulator decisions, monetary penalty notices and enforcement action detailing control failures behind specific breaches.	Provides root cause detail that initial disclosure rarely contains, useful for benchmarking your own controls.
European data protection authority decisions	Open	EU supervisory authority decisions and EDPB documentation covering breach notification obligations and enforcement outcomes.	Establishes notification thresholds and what regulators have treated as adequate response.
Ransomware.live	Open	Aggregated ransomware leak site postings recording claimed victims, dates and the group behind each claim.	Early indication that an organisation or supplier has been compromised, often before any official disclosure.
DeHashed	Licensed	Commercial search across many breach corpora with record-level results, available under contract.	Contracted exposure assessment for your own identities and domains where indirect services are insufficient.
Intelligence X	Licensed	Commercial search across leaks, darkweb content and archived material with selector-based lookup.	Establishes whether specific organisational identifiers appear in circulating material, under a contractual basis.
CISA advisories and Stop Ransomware	Open	Government technical advisories covering intrusion sets responsible for large-scale data theft, with indicators and mitigations.	Links a breach to a known intrusion set and supplies hunting indicators for your own environment.
Verizon Data Breach Investigations Report	Open	Annual analysis of thousands of confirmed incidents with pattern, actor and vector distributions across sectors.	Baseline for whether an incident's vector and pattern are typical, useful for board-level context.
IC3	Open	US Internet Crime Complaint Center reporting and public service announcements on data theft and extortion campaigns.	Reporting channel for US victims and a source of campaign-level context on data theft trends.
National CERT advisories	Open	National technical authority guidance on incident handling, notification expectations and sector-specific breach response.	Jurisdiction-specific expectations for how a breach should be handled and reported.
Court records via CourtListener	Open	US federal and state dockets including class actions and enforcement litigation arising from data breaches.	Litigation filings frequently disclose technical root cause and timeline detail absent from public statements.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Data Breach. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Domain-level exposure search — Answers which of your addresses appear in catalogued breaches without transferring records. Limitation: coverage is limited to corpora the service has verified and loaded.
Identity and access management console — Executes forced resets, session revocation and MFA enrolment across affected accounts. Limitation: coverage gaps for federated and legacy applications outside the identity provider.
Session and token revocation tooling — Invalidates active sessions and refresh tokens, closing the gap a password reset leaves open. Limitation: some applications cache sessions independently of the identity provider.
Compromised password screening service — Checks proposed passwords against known-exposed corpora using k-anonymity so the secret is never transmitted. Limitation: only prevents reuse of already-known values.
Data classification and discovery — Determines what data classes the breached system held, which drives notification obligations. Limitation: accuracy depends entirely on the quality of the classification scheme.
Case management for notification — Tracks who was notified, when and with what content, producing the regulator-facing record. Limitation: only as good as the affected-individual list feeding it.
Third-party risk platform — Maintains supplier incident history and contractual notification obligations. Limitation: relies on self-attestation, which historically diverges from reality.
Log retention and search — Supports hunting for use of exposed credentials across the full exposure window. Limitation: retention windows are usually shorter than the exposure window.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

The incident and the dataset are different objects and must be modelled separately. One breach can produce several corpora surfacing years apart, and one corpus can merge dozens of incidents, so a data model that conflates them produces inflated counts and misattributed blame.
Structural analysis distinguishes first-party exports from aggregations far more reliably than any provenance claim. Consistent field semantics, coherent internal identifier ranges and a single password hashing scheme indicate one source system; a merged spreadsheet indicates a combolist.
Record counts in seller claims are marketing. Deduplicate against known corpora before repeating any figure, because republication under a new name is the norm and each cycle inflates the apparent scale of an incident that may be years old.
Absence of confirmation is not disproof, but it belongs in the confidence statement. Many genuine breaches are never confirmed by the named entity, and many claimed breaches are credential-stuffing artefacts misattributed to a company that was never compromised.
Notification clocks in several regimes start at awareness rather than at confirmation, so the moment your team credibly believes an incident occurred is a legal event. Build that trigger into the process explicitly rather than discovering it during the post-incident review.
Prefer indirect exposure assessment over ingestion every time. Downloading a corpus to check whether you are in it recreates the breach inside your own environment, creates a processing basis problem and adds a dataset you must now protect and destroy.
The regulatory and litigation tail is where the real technical detail lives. Enforcement notices and class action filings state what actually failed, months or years after the initial disclosure said very little, and that is the material worth benchmarking against.
A password reset without session and token revocation is not remediation. Stolen session cookies and refresh tokens remain valid after a reset in many applications, which is precisely why infostealer-derived exposure keeps producing intrusions at organisations that reset diligently.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Data Breach is producing anything, and they are worth baselining before you change process or tooling.

Time from credible awareness of an incident to completed data class assessment, since that assessment determines notification obligations and everything downstream depends on it.
Proportion of exposure assessments completed using indirect services rather than by ingesting corpora, which measures whether the response is creating new risk.
Percentage of affected accounts where session and token revocation was performed alongside credential reset, verified from logs rather than assumed.
Notification completion within the applicable regulatory deadline, with the record retained. Missed deadlines are the enforcement trigger far more often than the breach itself.
Share of supplier incidents learned about from the supplier under contract versus discovered from public sources. A low share indicates contractual notification is not working.
Overlap percentage between newly circulating corpora and previously handled datasets, which prevents repeat response cycles on recycled data.
Number of control changes implemented as a direct result of root cause analysis, tracked to completion. Incidents that produce reports but no control changes will recur.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Advertised record counts are marketing figures from criminal sellers and routinely overstate unique affected individuals by an order of magnitude.
Combolists aggregated from many sources get attributed to a single company, generating false breach claims against uninvolved organisations.
Absence from public catalogues means nobody has verified and indexed the corpus, not that an organisation was never breached.
Fabricated breaches are published to build seller reputation or to extort, and can trigger costly and unnecessary response programmes.
Old breaches resurface repackaged under new names, causing teams to re-run response for exposure they already remediated years ago.
Downloading a breach corpus to assess exposure can itself create unlawful possession of personal data and severe compliance liability.

Legal and ethical considerations

Breach datasets are concentrated personal data and often unlawfully obtained. Possession, storage and processing require a clear lawful basis, and in several jurisdictions handling stolen data is an offence regardless of defensive intent. Prefer indirect assessment through services that answer exposure questions without transferring records to you. Where ingestion is genuinely necessary, restrict and log access, minimise fields, encrypt at rest, define a short retention period, and never use the data to contact, profile or enrich individuals beyond the notification duty you are discharging.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Data Breach, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 7 intelligence disciplines, 4 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Should we download a leaked dataset to check whether we are affected?

Almost never, and not as a first step. Downloading a corpus of stolen personal data creates a processing activity requiring a lawful basis, adds a highly sensitive dataset you must now protect, and in some jurisdictions constitutes handling stolen data regardless of defensive intent. Domain-level exposure services answer the question from identifiers alone. Where ingestion is genuinely necessary, take legal advice first, minimise the fields retained, restrict access to named responders, log every query and set a short deletion schedule with verifiable destruction.

How do I tell a real breach from a repackaged combolist?

Look at structure rather than at the seller's claim. A first-party export shows coherent field semantics, a consistent password hashing scheme, internal identifier sequences that behave like a real primary key, and a date range that stops at a plausible exfiltration point. An aggregation shows inconsistent field names and types, multiple hash formats, records with impossible combinations, and a date range spanning many years. Cross-check a sample of records against known older corpora to measure overlap. High overlap with material already in circulation is the clearest signal of repackaging.

What is the difference between a service breach and an infostealer log?

A service breach exposes records from one organisation's systems at one point in time, and the remediation is scoped to that service. An infostealer log reflects a compromised endpoint and typically contains many credentials, cookies, session tokens and autofill data belonging to one user across dozens of services. The remediation is fundamentally different: the device must be treated as compromised and rebuilt, all credentials entered on it rotated, and all sessions revoked. Resetting a password on a machine that still hosts the stealer simply hands the attacker the new value.

When does the notification clock start?

In several regimes, including GDPR, at the point of awareness rather than at confirmation, which is earlier than most teams assume and is a legal judgement rather than a technical one. That means a credible internal belief that a personal data breach has occurred can start a seventy-two hour clock even while the investigation continues, and regulators accept phased notification where full detail is not yet available. Involve counsel at the moment of credible awareness, record the time and basis of that determination, and do not delay the clock while seeking certainty.

How should we handle a breach at a supplier?

Treat it as your incident for the data you own. Invoke the contractual notification and cooperation clauses, request the supplier's incident report with scope, timeline and root cause, and independently assess whether your data was in scope rather than accepting a reassurance. Determine your own notification obligations, because being a controller does not delegate away with the processing. Record the supplier's response quality in the third-party risk record, since a pattern of poor responses is a procurement decision. Where the supplier is unresponsive, escalate commercially and consider regulatory obligations independently.

Is data that has been public for years still a risk?

Yes, in specific ways. Old credentials remain dangerous because password reuse persists and because many accounts are never rotated. Personal data does not expire: names, dates of birth, addresses and government identifiers remain usable for identity theft and social engineering a decade later. What does decay is the immediate operational risk of session material and current credentials. Assess by data class rather than by age, and note that aggregation of several old breaches produces a richer profile of an individual than any single recent incident did.

Can we publish or share breach data internally to warn people?

Share the fact and the action required, never the data. Telling an employee that their corporate address appears in a named breach along with a password hash, and that they must reset and enrol in phishing-resistant MFA, achieves the entire security objective. Circulating the records themselves multiplies the exposure, creates new processing without basis, and frequently reaches people with no need to know. The same applies to third-party data: sharing a supplier's leaked records with your own staff is a separate disclosure that you would then have to justify.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

GDPR Articles 33 and 34 set the personal data breach notification obligations to supervisory authorities and to affected individuals, with the seventy-two hour trigger.
HIPAA Breach Notification Rule governs US healthcare breach reporting, including the public HHS portal for incidents affecting five hundred or more individuals.
SEC cybersecurity disclosure rules require US registrants to report material cybersecurity incidents, creating a dated public record.
NIS2 Directive imposes incident reporting timelines and supply chain security obligations on essential and important entities in the EU.
ISO/IEC 27035 defines information security incident management process, including detection, assessment, response and lessons learned.
NIST SP 800-61 provides the computer security incident handling guide underpinning most enterprise response processes.
US state breach notification statutes, notably California and Maine, define notification triggers, content and the public filing portals used as primary sources.
PCI DSS defines obligations and forensic investigation requirements where payment card data is involved in a breach.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Have I Been Pwned — Troy Hunt. Verified breach catalogue with data classes and free domain-level exposure search.
Breach Portal — US Department of Health and Human Services, Office for Civil Rights. Mandatory reporting of US healthcare breaches with entity, cause and affected counts.
Data breach notification filings — California Office of the Attorney General. Official state repository of breach notifications submitted by affected organisations.
EDGAR filings — US Securities and Exchange Commission. Material cybersecurity incident disclosures by listed registrants with dated legal consequence.
Enforcement action and penalty notices — UK Information Commissioner's Office. Regulator decisions detailing the control failures behind specific breaches.
Computer Security Incident Handling Guide — National Institute of Standards and Technology. Reference process for incident detection, analysis, containment and recovery.
Data Breach Investigations Report — Verizon. Annual pattern analysis across thousands of confirmed incidents by sector and vector.
Stop Ransomware — Cybersecurity and Infrastructure Security Agency. Government guidance and advisories on intrusion sets responsible for large-scale data theft.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: breach exposure monitoring for your domains and supply chain, with verified incident records and no unnecessary data retention. Explore the platform, or browse the rest of the library by following any tag above.