A claim appears on a forum at 4:50 on a Friday. A seller says they have four million records from your company, posts a blurred screenshot and a sample of two hundred rows, and gives buyers a week to inquire. By Monday, three reporters have emailed your press address and a customer has posted the screenshot on social media. What you do in the next 48 hours determines whether this becomes a contained incident or a month of guesswork.
Verification is not one task. It is a short sequence: capture the claim, test the sample, scope the exposure, decide who needs to be told, and write down what you did. Here is how to run that sequence without breaking things along the way.
Start With Intake, Not With Panic
Assign one owner and one intake channel before anyone starts investigating. Five analysts chasing the same post from five directions produce conflicting notes and no chain of custody.
Record what you actually saw, not what you remember. Capture the forum URL, the seller's handle, the post ID, the timestamp in UTC, and a screenshot with your own system clock visible. Threat actors edit posts, delete them, and repost under new handles within hours. Your notes may be the only surviving copy of the original claim.
Note the exact wording. "Database from your customer portal" is a very different claim from "emails scraped from a marketing list." Sellers blend both, often deliberately, to widen the pool of potential buyers.
Triage the Sample for Credibility
A sample is the only part of the claim you can test. Most fabricated or recycled dumps fail on simple checks before you ever touch a database.
- Schema realism. Does the column order, naming convention and data type match what your system actually produces? A dump with user_id, email, password, created_at when your application writes account_uuid, login_email, pw_hash is probably not yours.
- Internal consistency. Do the date ranges, record counts and identifier formats line up with each other? A file claiming 2017 records with a UUIDv4 format you only adopted in 2022 is a problem for the seller, not for you.
- Cross-field logic. Does the postal code match the city? Does the account creation date precede the last login? Fabricators rarely keep that level of detail straight.
- Freshness. Do any records contain values created after your last known change to that system? Genuine recent data is harder to fake convincingly.
- Recycling patterns. Pasted headers, uniform test addresses, or rows that also appear in an old publicly known breach dump.
A resold 2019 dump is still worth a look, but your response will be smaller: confirm the exposure is closed and decide whether any notification duty still applies.
Handle Samples Like Evidence
Never open a leaked archive on a workstation with domain credentials. Use an isolated analysis machine or virtual machine with no network access and no shared folders. Compute and record a hash of the file before you open it, along with the time and method of acquisition. If the claim ends up in a regulatory filing or a lawsuit, that hash is what lets you say the sample you examined is the sample you received.
Avoid the two mistakes that cause real damage. Do not ingest a sample into production or staging systems to "see what matches." And do not test leaked credentials by attempting logins against your live identity provider. That triggers mass lockouts, generates noise in your logs, and can signal to the seller that you found them. Work from an exported, offline copy of your authentication records instead.
Treat the sample as hostile input from an unknown source. Curiosity is fine; connectivity is not.
Scope What Actually Leaked
Once the sample looks genuine, answer these questions in order.
- Which system of record produced these fields? Narrow it to one application, database, or third party.
- Are the records current or historical? Count how many fall inside your retention window.
- Do they contain internal-only values — ticket numbers, staff email domains, environment names — that an external scraper could not have obtained?
- Check your canary records. If your team planted honeytoken rows in specific tables, their presence pinpoints the source.
- Classify the exposed data: credentials, contact details, financial identifiers, health information, or a mix.
- Confirm whether the access path still exists. Leaked data is often a symptom of a live exposure: an unauthenticated API, a bucket left public, a vendor with excessive access, or a stale export sitting in a shared drive.
If step six fails, you have an ongoing incident rather than a historical one, and the priority order changes immediately.
Keep the Investigation Quiet
Assume the seller is watching for a reaction. Do not contact them from corporate infrastructure, and do not let procurement or sales teams reply to the original post. Route any communication through legal counsel or an external party.
While you scope, look for signs the access is still live: bulk export jobs, new administrator accounts, mailbox forwarding rules created recently, logins from unfamiliar networks. These take minutes to check and can turn a data review into a containment exercise.
On payment: demands escalate, and paying does not reliably remove the data. It may also raise legal or sanctions issues. This is a decision for counsel and leadership, not for the on-call engineer.
Notification, Contracts, and the Clock
Obligations vary widely by jurisdiction, sector and contract. Privacy statutes, sector regulators, customer agreements, payment network rules and cyber insurance policies can each impose separate deadlines and content requirements. Some require notice within days of determining a breach occurred; others hinge on risk thresholds.
Your job is to supply facts fast, not to guess at requirements. Prepare a single-page brief: what data, how many individuals, when the exposure began, how it was discovered, what containment is in place, and what remains unknown. Counsel then decides what must be filed and when.
Two rules of thumb. Do not publish a statement before scope is confirmed — corrections cost more credibility than a short delay. Do not stay silent on a confirmed exposure while waiting for a perfect picture. Legal advice here should come from a qualified professional in each relevant jurisdiction, not from a forum post or a blog.
Make the Next Claim Boring
Write the playbook now, while nothing is on fire. Keep a one-page template with fields for intake details, sample hash, scope findings, decision and notification status. Name a decision owner in advance, and rehearse once a quarter using a real sample pulled from a public leak site. Most teams lose their first day simply working out who is allowed to decide.
Do that, and the next Friday-evening post becomes a checklist instead of a crisis.
Photo: Vitaly Gariev / Pexels