Incident documentation as you go, not after

Why this matters

Objective 4.2 covers incident reporting and communication, and this lesson is the written half: the notes taken during, and the report produced after.

The reason it is worth real attention is that documentation is the only part of an incident response that persists. The containment is undone, the systems are rebuilt, the people forget — and what remains is what was written down. If that record is thin, then for every purpose that comes later, the response is whatever the record can support.

The lesson

Contemporaneous notes and why they matter

Contemporaneous means written at the time, not reconstructed afterwards. The distinction is not pedantry; it changes what the notes are worth.

Why they carry weight recollection does not:

• Memory degrades and reorders. After a 14-hour response nobody reliably recalls whether the account was disabled before or after the transfer, and that ordering may be exactly the question.
• Hindsight rewrites. Once you know the outcome, your memory of the early decisions quietly becomes more coherent and more correct than it was. Notes written before the outcome was known are the only defence against this, and they are what makes lesson 35's blameless review honest.
• Handover depends on them. Incidents cross shifts, and the incoming responder inherits your notes and nothing else.
• They are evidence. For an insurer, a regulator, a court or an internal process, notes made at the time are treated very differently from a narrative written a fortnight later.
• They prevent repeated work. At hour nine somebody asks whether anyone checked the jump host. Without notes, someone checks it again.

What to record as it happens:

• Every action taken: what, when (UTC), by whom, on which system, and the exact command or change.
• Every observation, with its source.
• Every decision, who made it, and the reasoning available at the time.
• Every communication: who was told what, when.
• The questions you have not answered yet, which is the list that keeps an investigation from losing threads.

Practicalities that make it survive:

• A scribe role where the team is large enough, per lesson 29 — the person investigating cannot also be the person writing.
• A shared, timestamped, append-only place, not individual notebooks.
• On infrastructure that is not the incident, which is the out-of-band point again: notes in a compromised environment can be read by the attacker and lost with the systems.
• Record your own actions separately and clearly, so your footprint is distinguishable from the intruder's — the point from lesson 31, and this is where it is satisfied.

The incident report structure

The document produced afterwards. A workable structure, in the order a reader needs it:

1. Executive summary. What happened, what was affected, what was done, current status, what is being asked. Half a page, no jargon, written so that reading only this leaves the reader correctly informed.
2. Timeline. Attacker activity and response activity, in UTC, from lesson 30's working timeline.
3. Scope and impact. Systems, accounts and data affected, with the boundary of the search stated — what you looked at, and what limited it.
4. Root cause. Proximate and underlying, per lesson 35.
5. Response actions. Detection, containment, eradication, recovery, with verification evidence.
6. What worked and what did not, including the detection gaps.
7. Findings and actions, each with an owner and a date.
8. Appendices: indicators, evidence inventory, tooling, full logs.

Qualities that separate a useful report from a filed one:

• Distinguish fact from inference throughout, and mark confidence. This is lesson 37's discipline, in permanent form.
• Include the negative findings. "We searched the estate for this indicator and found it on four hosts" is much stronger than "four hosts affected", because it states the search.
• State your visibility limits. Retention, coverage, what you could not examine.
• Be honest about the response, including what was slow. A report that reads as though everything went well is one nobody learns from, and the reviewers who were there will simply discount the whole document.
• Write it soon, while the notes still make sense to their author.

Regulatory and contractual notification duties

Where an incident becomes a legal matter, and where the analyst's role is precise and limited.

What tends to apply:

• Privacy law. Personal data breaches typically require notification to a supervisory authority within a short window — commonly 72 hours of becoming aware — and to affected individuals where the risk is high. Lesson 26 covered the shape.
• Sector regulation, some of which now requires initial reports in hours rather than days.
• Contractual duties to customers, which are frequently stricter and faster than the law. Enterprise contracts often demand notification within 24 or 48 hours of awareness, and these are the obligations organisations most often miss because nobody has read them during an incident.
• Cyber insurance, which usually requires prompt notification and may require approved firms — a condition that can affect cover if missed.
• Payment card rules, with their own reporting and forensic requirements.

What an analyst needs to understand:

• The clock usually starts at awareness, not at confirmation. That makes your timeline and your notes legally significant, because the moment of awareness is determined from them.
• "Awareness" is a determination, and not yours to make. Legal and privacy decide, from facts you supply.
• Escalate early. The frequent and expensive failure is an analyst investigating for two days before anyone tells legal, by which point half the window is gone. A brief early notification — "we have an incident that may involve personal data, here is what we know" — costs nothing and starts the right processes.
• You supply facts, not conclusions: what data was accessible, what evidence of access exists, how many records, which jurisdictions. Whether it is notifiable is decided elsewhere.
• Preserve evidence for the notification itself, which may need to describe categories of data and numbers of individuals with some precision.

Customer and public communication

Rarely the analyst's to write, and worth understanding because the analyst supplies its factual basis and will be asked to check it.

What good external communication does:

• Says what happened, in plain terms, without minimising.
• Says what it means for the reader specifically — their data, their account, their service.
• Says what the organisation is doing.
• Says what the reader should do, concretely: change a password, watch for something, contact someone.
• Says when the next update comes, and then delivers it.

Failures that reliably make things worse:

• Minimising language that later proves wrong. "A limited number of accounts" is a hostage to fortune when the number turns out to be large.
• Promising completeness too early. "All affected customers have been notified" before scoping finishes is a statement that gets retracted.
• Technical language that obscures the consequence.
• Blaming the attacker's sophistication as an explanation. It reads as deflection, and is frequently untrue.
• Silence. In the absence of information, the story is told by someone else — a researcher, a journalist, or the attacker's own leak site.

The analyst's contribution is narrow and important: check the factual claims before they go out. Every sentence of the form "there is no evidence that" needs an analyst to confirm it is supportable, and the distinction from "this did not happen" has to survive the edit. A statement that outruns the evidence becomes a correction later, and a correction about a breach is a second news story.

What belongs in a report and what does not

The editorial judgement, which the exam probes and which protects both the reader and the organisation.

Belongs in:

• Facts, with their sources.
• Inferences, labelled as inferences, with confidence and reasoning.
• What was done, by whom, when.
• What is not known, and what would resolve it.
• The limits of the investigation.
• Findings and actions with owners.

Does not belong in:

• Speculation presented as finding. An early theory in a written report becomes the organisation's position and outlives the evidence that contradicts it.
• Attribution beyond the evidence. "Consistent with tooling reported for a known group" is supportable; naming a country is usually not, and carries consequences well outside the report.
• Blame directed at individuals, which is lesson 35's principle in writing, and also the fastest way to ensure nobody cooperates with the next investigation.
• Unnecessary personal data. A report about a compromised account does not need the contents of the mailbox. Minimise, and remember the report itself becomes a document with a wide readership and a long life.
• Credentials, keys, tokens or the malware sample itself. Reference them; never paste them. A report that quotes a credential to prove it was exposed has just exposed it again, to a larger audience, in a document that will be emailed and archived.
• Rhetoric. "Sophisticated", "nation-state", "unprecedented" are almost always doing work that the facts are not.

The standard that covers all of it: write the report as though it will be read by the regulator, the customer's lawyer, the journalist and the colleague you criticised — because over a long enough period, it will be. Everything that survives that test is the part worth writing, and it is also, not by accident, the part that is true.

Topics this lesson owns

• [x] Contemporaneous notes and why they matter
• [x] The incident report structure
• [x] Regulatory and contractual notification duties
• [x] Customer and public communication
• [x] What belongs in a report and what does not