IR Documentation and Case Management
Building the incident record in real time — the timeline, decision log, evidence inventory, and the final report that serves legal, regulatory, and operational audiences simultaneously.
Six months after a significant breach, outside counsel sends a discovery request: all documents and communications related to the incident. The IR team had done solid technical work but kept notes scattered across personal Slack messages, a Google Doc with no version history, and a whiteboard that was photographed by someone's phone. Half the team members who worked the incident have since left the company. The IR lead can't reconstruct the timeline with confidence, and the decision to delay containment by 2 hours — a defensible call at the time — has no contemporaneous documentation. Good documentation during the incident is not bureaucratic overhead. It is the technical team's protection when the lawyers arrive later.
Case File Structure
Incident Case File Structure ═══════════════════════════════════════════════════════════════════ IR-2026-023/ ├── 01_overview.md — Incident summary, severity, current status ├── 02_timeline.md — Chronological event log (auto-updated) ├── 03_scope.md — Confirmed affected systems, accounts, data ├── 04_decisions.md — Decision log with context ├── 05_evidence/ — All collected artifacts │ ├── inventory.csv — Hash, filename, collection time, collector │ ├── memory_images/ — .raw files with .sha256 sidecar │ ├── log_exports/ — .evtx, .csv exports │ └── disk_images/ — Forensic images ├── 06_communications/ — SITREPs, escalation records ├── 07_tasks.md — What's in progress, who owns it └── 08_pir.md — Post-incident review (filled after close)
The Incident Timeline
The timeline is the single most important document in any incident. It is built in real time, entry by entry, as findings emerge. Every entry has: UTC timestamp, what happened, who found it, and what evidence supports it.
Timeline Entry Format
═══════════════════════════════════════════════════════════════════
YYYY-MM-DD HH:MM UTC | [Category] | Finding | Evidence | Analyst
Example entries:
2026-08-28 03:12 UTC | DETECTION | EDR alert: ransomware activity on
LAPTOP-JSMITH. 400 file encrypt events.
| CS alert ID: 8a9f23b7 | SOC-analyst-01
2026-08-28 03:18 UTC | DECISION | Decision: delay containment 30 min
to scope additional hosts. Active
encryption appears stopped on LAPTOP-JSMITH.
Authorized by: IR Lead, CISO notified.
| Slack message screenshot (OOB) | IR-lead
2026-08-28 03:22 UTC | FINDING | EDR sweep finds 6 additional hosts with
beacon activity: [list]. All show type=
LockBit based on file extension .lockbit
| EDR host group search results | EDR-analyst
2026-08-28 03:48 UTC | CONTAINMENT| Simultaneous isolation of 7 hosts via
CS bulk contain. All confirmed isolated
at 03:49 UTC.
| CS action log screenshot | IR-lead
The Decision Log
Every material decision made during the incident must be logged separately from the timeline. The decision log answers: what did we decide, why, who authorized it, and what information did we have at the time.
| Field | Purpose |
|---|---|
| Decision ID | DECISION-001, DECISION-002 — reference in timeline and communications |
| Time (UTC) | When the decision was made |
| Decision | What was decided — concrete, specific |
| Decision maker | Name and title of the person who authorized it |
| Information available | What was known at the time — prevents retrospective "you should have known" claims |
| Alternatives considered | What else was considered and why rejected |
| Outcome | Filled in retrospect: did the decision achieve its intended purpose? |
The Final Incident Report
The final report serves three audiences with different needs. One report cannot serve all three — write a layered document.
| Audience | What they need | Report section |
|---|---|---|
| Executive / Board | Business impact, decisions made, current status, cost estimate, reputational considerations | Executive summary: 1-2 pages, no technical detail, no jargon |
| Legal / Regulatory | What data was affected, what notification obligations exist, what was done and when, evidence of reasonable security practices | Legal section: data classification findings, notification timeline, documentation of security controls that were in place |
| Technical / Security Operations | Full technical timeline, attack chain, IOCs, TTPs, detection gaps, eradication steps, hardening recommendations | Technical appendix: full detail, all evidence references, MITRE ATT&CK mapping |
The documents you create during an incident may eventually be reviewed by opposing counsel in litigation, regulators with enforcement authority, insurance adjusters evaluating a claim, or journalists under a FOIA request. Write facts, not opinions. Write what you knew, not what you later learned. Avoid language that speculates about liability, attributes blame, or makes legal conclusions ("we were negligent in not patching this"). The technical timeline is your best defense — it shows what was done, when, and by whom. The decision log shows that decisions were made thoughtfully with the information available, not carelessly. These documents protect the organization and the individuals who worked the incident.
Q & A
Q: A team member sends an informal Slack message saying "I think this was caused by the unpatched server we've been meaning to fix for months." The attacker didn't use that server. The message is wrong and potentially damaging. What do you do?
Act immediately: (1) Ask the team member to clarify the message or retract it in the same channel — a corrections post in the same thread is better than leaving a false statement standing. (2) Have the IR lead issue a factual statement in that channel correcting the record. (3) Brief legal counsel that the message exists, so they're aware of it and can address it in any privilege or litigation strategy. (4) Post-incident: reinforce the IR communication policy — only the IR lead communicates incident findings, and only through the designated channels. Informal statements in public channels are the most common source of damaging documentation in breach litigation. The correction is worth making, but also accept that the message exists and prepare for the possibility that it becomes discoverable. Do not delete it — intentional destruction of potentially discoverable communications is worse than the message itself.