White paper
Investigating a suspected breach without confirming it
Most breach investigations begin with a theory. The ones that go wrong are the ones that set out to prove it. How to structure an investigation so the premise can fail, and why that is when the useful findings appear.
Who this is for
Founders, operations leads and technical teams responding to something that looks like a compromise.
The premise is a hypothesis, not the brief
An investigation is usually commissioned with the answer already sketched: someone got in, and the job is to find out who. That framing is understandable and it is the single most common reason investigations produce confident conclusions that are wrong.
The discipline is to treat the premise as a hypothesis that is allowed to fail, and to state at the outset what evidence would falsify it. If nothing would, the investigation is not an investigation.
Start with the artefact, not the theory
Begin from the thing that was actually observed. The record, the submission, the log line, and establish its provenance before reasoning about who could have produced it. Metadata is frequently decisive and frequently ignored: where a request came from, what interface produced it, what else shares its characteristics.
A useful question is what the platform records natively rather than what it appears to record. Platforms differ enormously in what they retain, and conclusions built on a field that does not mean what it looks like are worse than no conclusion.
Work read-only, and say so
Investigations contaminate evidence. Creating a test record, correcting a setting, or deleting something suspicious while establishing what happened destroys the ability of anyone later, including a regulator or an insurer, to reconstruct the state.
Work read-only wherever possible and record that constraint in the report. It is also the thing that makes findings credible: an investigator who changed things is an investigator whose conclusions can be questioned.
Attribution is where investigations do damage
The strongest pull in any suspected-breach investigation is toward naming someone. Technical evidence rarely supports it. Shared identifiers, matching names and coincident timing are correlations, and a name appearing in a system is not evidence that its owner put it there, names are used by other people, deliberately and accidentally.
Identifying a private individual incorrectly carries real legal exposure for the organisation that does it, and it forecloses the investigation. Where intent exists to act on a name, that determination belongs with law enforcement or a licensed investigator instructed by counsel, and the technical report should say so explicitly rather than implying more than it can support.
When the premise fails, keep looking
"No attacker" is not the same as "no exposure." The reason someone noticed something is often adjacent to a genuine problem even when their explanation is wrong, and the review that establishes a false premise is usually already inside the systems where the real issue lives.
This is the most valuable half hour in an investigation and the one most often skipped, because the commissioned question has been answered and the engagement feels finished. It is not: an investigation that closes a false alarm without checking what else is true has produced reassurance rather than a finding.
In short
- State at the outset what evidence would disprove the theory, if nothing would, it is not an investigation
- Establish provenance from metadata before reasoning about who is responsible
- Work read-only; an investigator who changed things is one whose findings can be challenged
- Correlation is not attribution, and misidentifying a person carries legal exposure
- A disproved premise is the beginning of the useful work, not the end of the engagement