Incident Case Management: From First Alert to Final Report

The investigation is only as good as its notes

Ask any responder about their worst incident and the technical part is rarely the story. The story is the spreadsheet of IPs that three people edited at once, the disk image nobody could prove was unaltered, the timeline reconstructed from Slack scrollback two weeks later, and the report that said "on or around" eleven times.

Case management is the unglamorous discipline that prevents this. It is not a tool, although tools help. It is a set of habits: one place for the facts, one owner per decision, and a record that someone outside the team can follow months later.

Alert, event, incident, case

Teams use these words loosely, which causes real confusion about when the paperwork starts. A workable set of definitions:

The rule that matters: open a case early. The cost of a case that turns out to be nothing is a closed ticket with a "benign" disposition. The cost of a case opened late is every note taken before it existed, scattered across chat, personal text files and memory.

Promotion criteria

Write down what promotes an alert to a case so that L1 analysts do not have to make a political judgment at 3 a.m. Examples that work:

• Any confirmed credential compromise, even a single account.
• Any malware execution (not just delivery) on a managed endpoint.
• Two or more alerts correlated to the same host or identity within 24 hours.
• Anything touching a system in your crown-jewels list.
• Any report from an external party (CERT, customer, law enforcement, researcher).

What lives in a case

Summary and scope

At the top: what happened, in two sentences, kept current. Then scope: affected hosts, identities, data, business units. Scope changes constantly in the first days, so record changes with timestamps rather than overwriting.

Indicators

Every IOC goes into the case with context, not just a value:

indicator:   45.93.x.24            (type: ipv4)
role:        C2 (HTTPS beacon)
source:      EDR network telemetry, host FIN-WS-0231
first_seen:  2026-08-11 22:14:03 UTC (in our environment)
confidence:  high
status:      blocked at egress 2026-08-12 09:40 UTC

Without role and source, an indicator list is useless to anyone who did not build it. Enrich as you go (/domain/, /hash/, /email/ for the usual suspects) and paste extracted indicators through something like /tool/ioc-extractor rather than retyping them. Retyping is how a 0 becomes an O and a block rule silently matches nothing.

Evidence

Evidence is anything you might rely on to support a conclusion: disk images, memory dumps, log exports, email samples, screenshots, EDR timelines. Each item gets:

• a unique ID within the case,
• what it is and where it came from (host, system, account),
• who collected it, when, and how (tool and version),
• a cryptographic hash computed at collection,
• where it is stored now.

Hash at collection and verify on every transfer. SHA-256 is the default; MD5 survives in some forensic tooling for compatibility, and recording both costs nothing (see /compare/md5-vs-sha256 for why SHA-256 is the one to rely on). /tool/hash-generator is fine for small artefacts; for disk images, use your imaging tool's built-in hashing.

Decisions log

Containment and eradication involve trade-offs: isolate the server now and stop payroll, or monitor for six hours and risk spread. Record each decision with who made it, what information they had, and what alternatives were rejected. This is the section that protects your team in the post-incident review, and it is the one most often missing.

The timeline is the backbone

A timeline turns a pile of evidence into a story. Build it as you go, not at the end.

Normalize to UTC. Logs arrive in local time, UTC, epoch seconds and epoch milliseconds, sometimes in the same incident. Convert everything on entry; /tool/timestamp handles the odd formats. Record the original value too, so a reviewer can check your conversion.

One row per observation, with its source:

2026-08-11 21:58:40 UTC | Email delivered to j.doe (invoice lure)       | M365 message trace
2026-08-11 22:13:51 UTC | j.doe opens attachment, Excel spawns rundll32 | EDR process tree
2026-08-11 22:14:03 UTC | First HTTPS beacon to 45.93.x.24             | EDR network, proxy
2026-08-12 03:02:17 UTC | LSASS access from rundll32                    | EDR, Sysmon EID 10
2026-08-12 09:40:00 UTC | Egress block deployed                         | Firewall change log

Mark confidence. "Attacker likely moved laterally around 04:00 based on logon gap" is a hypothesis; keep it visibly separate from observed facts until confirmed.

Watch clock skew. An endpoint with a drifting clock will reorder your story. When two sources disagree on one event, note the offset and apply it consistently to that source.

The rework slice is the argument for live documentation. It never shows up in anyone's estimate, and it is always there.

Chain of custody, without the theatre

Not every incident ends in court, but you rarely know on day one which ones will: an insider case, a fraud claim, a regulator inquiry or a cyber-insurance dispute can turn routine evidence into contested evidence. Chain of custody is cheap if done from the start and impossible to retrofit.

The essentials, consistent with guidance such as RFC 3227 and ISO/IEC 27037:

Collect in order of volatility (memory and network state before disk, disk before archived logs), as RFC 3227 describes. And log the collection method: a memory dump taken with a specific tool version, on a live system, by a named person, is defensible; "we grabbed memory" is not. Our memory forensics primer covers the collection side in more detail.

Closing the case: the final report

The report has at least two audiences, and mixing them is the most common mistake. Write in layers.

Executive summary (one page)

What happened, impact, whether it is contained, what it will cost or might cost, and the three decisions leadership needs to make. No IP addresses, no process names.

Technical narrative

The timeline, condensed into phases (initial access, execution, persistence, lateral movement, impact), each mapped to evidence IDs. Mapping to ATT&CK techniques here makes the report useful to detection engineers later; /mitre/map helps with the mapping.

Indicators and detections

The final IOC list with roles and confidence, plus any detections written during the case. Defang everything in the document.

Root cause and recommendations

Separate the proximate cause (the user opened the attachment) from the root causes (macros allowed from the internet, no egress filtering, a local admin account shared across workstations). Recommendations must be specific, owned and dated, or they will not happen.

Appendices

Evidence register with hashes, custody log, full timeline. Nobody reads these until someone challenges your conclusions, and then they are the only part that matters.

Tooling notes

A case management tool should make the right thing the easy thing: indicators and evidence attached to the case rather than to chat, timestamps captured automatically, an audit trail of edits, and export to a report format. On mlab.sh, /cases is where investigations, indicators and notes live together so enrichment and documentation happen in the same place. Whatever you use, avoid splitting the record across tools; the case is only a source of truth if it is the only one.

For the first hour, before any of this structure exists, see incident response: the first 60 minutes.

Checklist

• [ ] Written promotion criteria from alert to case.
• [ ] One case per incident, opened early, with a named lead.
• [ ] Indicators recorded with role, source, first-seen and confidence.
• [ ] Evidence register with SHA-256 at collection and verification on transfer.
• [ ] Timeline in UTC, one row per observation, sources cited, hypotheses marked.
• [ ] Decisions log with who, when, and what alternatives were rejected.
• [ ] Report in layers: executive, technical, indicators, root cause, appendices.

None of this is difficult. It just has to start before you think you need it.