Reading an Incident Like an Analyst: Evidence, Bounded Unknowns, and Honest Reporting
The gap between a rookie and a real analyst is not a tool. It is how they handle the things they cannot see. This lesson is about reading an incident honestly — reporting what you actually know, bounding what you don't, and never filling a gap with a comforting guess.
Steven reports his backlog as “almost done.” That is not a bounded unknown — that is optimism with a progress bar. Today we do it properly. — Nyx
Why it matters: during an incident, the pressure to say “we got it all” is enormous. The analyst who says “here is what we know, here is what we can't yet prove, and here is who owns finding out” is the one you want in the room. Builds straight on the incident response lifecycle. Spot something wrong? Tell us.
A short, honest case
An engineer changes a storage-bucket setting to fix a partner integration and, without meaning to, makes it readable by anyone. A researcher reports that customer documents are exposed. The bucket holds 680 GB. The access logs show 1,240 downloads during the exposure window — but detailed logging was only switched on partway through. So what do you report?
Bounded unknowns beat comforting numbers
The wrong answer is “1,240 files were taken.” You do not know that. Logging started late, so those 1,240 are a floor, not a total. The honest report is a bounded unknown: “at least 1,240 objects were accessed; total exposure is unknown because logging did not cover the full window — treat the whole bucket as potentially exposed until proven otherwise.” You never substitute a number you wish were true for one you can defend.
Name the owner, record the reasoning
Every real decision in an incident has a name attached and a reason written down. Who decided to keep the bucket online while preserving the policy history? On what basis? A good incident record reads like a logbook: decision, owner, evidence, time. Months later, the question is never just “what did we do” — it is “why, and who called it.”
Containment is a claim until you prove it
Suppose you flip the bucket back to private and the tooling says “done.” That is a claim, not a fact. Were there pre-signed URLs still valid? Cached copies? A second misconfigured path? “The control plane reported success” and “the exposure actually stopped” are two different statements. The analyst verifies the second one.
A defensible answer can differ from the playbook
Playbooks are a starting point, not scripture. If the evidence points somewhere the playbook didn't anticipate, you are allowed to deviate — as long as you record why and you still protect the same business and security goals. “We did it differently and here is the reasoning” is professional. “We did it differently” on its own is not.
What to write down, every time
- Timeline — earliest observable event, when you noticed, when you declared. If the start is unknown, say so; don't invent one.
- Scope — what is confirmed affected, what is suspected, what you genuinely cannot see.
- Evidence — where each claim comes from, and how reliable that source is.
- Residual risk — anything you could not fully resolve, and who owns chasing it down.
Interview quick-fire
- Q: Logs show 1,240 downloads but logging started late. How much data was taken? A: Unknown — 1,240 is a floor; report a bounded unknown and treat the full set as potentially exposed.
- Q: The containment tool reported success. Are you contained? A: Not proven yet — verify effective state, check for alternate paths, pre-signed URLs, cached copies.
- Q: Can you deviate from the playbook? A: Yes, if you record the reasoning and still protect the same objectives.
Nyx grades every incident like it's Nova's homework. “You assumed containment? Bold.” — Nyx
And that is the whole skill: say what you know, bound what you don't, prove what you claim. Next up, the attacks that actually trigger these incidents. — Nova