A message arrives with a dramatic subject line and a screenshot of a few account records. It claims to prove a large company breach.
The response should neither dismiss the report automatically nor accept the sender's entire narrative. Establish what can be verified through an authorized, controlled process.
Preserve the claim as a claim
Record where the report arrived, when it was received, what the sender asserted, and which material was actually provided. Preserve the original message using the organization's approved evidence process.
Do not turn the screenshot's file name or headline into a verified incident title. The screenshot may show an observation, but it cannot independently establish the full dataset, the origin, or the date.
NIST's incident-response guidance supports integrating analysis, communication, and response decisions. For an unverified report, those workstreams should begin with explicit uncertainty.
Use records you are authorized to inspect
Confirm whether referenced domains, accounts, and services belong to your organization. Compare the report with the directory, application inventory, and relevant security records through the teams authorized to access them.
A hypothetical report may contain a former employee's address and a hostname for an external service. That can justify an account review without establishing that your infrastructure was breached.
Do not test supplied passwords, purchase access to claimed data, or ask staff to open unknown archives on ordinary workstations. Escalate any need for additional material through the established security and legal review process.
Separate relevance from authenticity
An identifier can be real while the sender's broader story is false or incomplete. Conversely, an outdated account can still matter to an investigation even if it no longer authorizes access.
Use a simple evidence ledger:
| Statement | Current support |
|---|---|
| The address belongs to a known work account | Confirmed through the directory, or unconfirmed |
| The service association is relevant | Confirmed by its owner, or pending |
| The claimed incident occurred as described | Independently supported, disputed, or unknown |
| Current unauthorized access occurred | Established by authorized activity evidence, or unknown |
Update each statement independently as information arrives.
Communicate the next decision
Tell stakeholders what was observed, what action was taken, which questions remain open, and when the next update is expected. Avoid both a premature “confirmed breach” and a definitive “nothing happened” unsupported by the review.
Read third-party attribution boundaries and writing an uncertainty-aware update. Responsible verification gives the team a defensible basis for action without distributing more sensitive material or amplifying an unverified claim.