A Non-Technical Guide to Reading a Security Incident Report

Sooner or later, a security incident report lands on a leader's desk. It may come from your own IT team, an outside firm, or a supplier confessing that your data was involved in their breach. It will be dense, defensive, and written by people who hope you skim it.

Do not skim it. An incident report is one of the few moments when an organisation tells the truth about itself in writing — or reveals, by its evasions, that it is not ready to. You do not need technical training to read one well. You need to know its anatomy, the questions each part should answer, and the smell of a bad one.

I have been on the writing side of this document. In a security operations centre at a major Nordic telecom, I worked live incidents — monitoring, triage, response — and wrote and maintained the playbooks that structure what happens during them. (A playbook is the pre-written step-by-step plan a team follows under pressure, so nobody is improvising at 3 a.m.) Reports are where that work becomes accountable. Here is how to hold one to a standard.

The anatomy: five parts every report needs

ANATOMY OF AN INCIDENT REPORT — FIVE PARTS

  TIMELINE --> SCOPE --> ROOT CAUSE --> IMPACT --> REMEDIATION
  what & when  how far   why it         who/what   what changes
               it reached happened      it cost    so it can't recur

1. Timeline

The timeline answers: when did it start, when did we notice, when did we act, when was it over? Read it for the gaps. The most important number in any incident report is usually the distance between the first two events — how long the attacker was inside before anyone noticed. That gap measures your detection capability, which, as I argued in What Is a CSIRT, and Why Should a Government Care?, is the capability everything else depends on. A timeline that begins at "we detected" rather than "it began" is hiding the gap, not closing it.

2. Scope

Scope answers: what was reached — which systems, which data, which people? Precision matters more than reassurance. "Some customer records may have been accessed" and "the attacker reached the database holding all customer identity documents, and we can confirm export of 12,000 records" describe the same genre of sentence at very different levels of honesty. Watch also for the encryption caveat: "the data was encrypted" is comforting only if the report says in what sense — as I explained in How Encryption Actually Protects — and Doesn't Protect — You, encryption at rest is irrelevant if the attacker was inside a running system that had already unlocked the safe.

3. Root cause

Root cause answers: how did this become possible? Note the phrasing — not "who clicked" but "what made the click sufficient." A phished password is an entry point, not a root cause; the root cause is whatever let one password open so many doors. This is exactly the reasoning I recommended in Explaining Zero Trust to Non-Technical Executives: judge systems by what happens after credentials are stolen. A report that stops at the human error has stopped one question too early — and has conveniently assigned blame to the least powerful person in the story.

4. Impact

Impact answers: what did it cost — operationally, financially, legally, and to the people whose data was involved? Distinguish impact from scope: scope is what was touched, impact is what it means. A good report separates confirmed impact from possible impact and says plainly what is still unknown. Unknowns stated openly are a sign of competence, not weakness; certainty this early is usually fiction.

5. Remediation

Remediation answers two different questions, and a good report separates them: what stopped the bleeding (containment — the tourniquet), and what prevents recurrence (the fix — the surgery). Each fix should trace back to the root cause, carry an owner, and carry a date. "We have enhanced our security posture" traces to nothing, is owned by nobody, and is due never.

The questions to ask

Bring this list to the meeting. Every question is answerable without technical background, and each one probes a specific part of the anatomy:

• ☐ How long was the attacker inside before we detected them — and how did we finally notice? (Luck and outside notification are honest answers; they are also findings.)
• ☐ What do we know for certain was taken or changed, and how do we know? What can we still not rule out?
• ☐ If the entry point was a person's mistake, what allowed that one mistake to spread so far?
• ☐ Could this happen again tomorrow? Which specific fix prevents it, who owns that fix, and by when?
• ☐ Who outside this room needs to know — regulators, customers, partners — and what is the notification plan?
• ☐ Which playbook was followed, and where did reality force us off the script? (No deviations reported usually means nobody compared.)

Red flags of a bad report

One clarification, from someone who wrote these under pressure: an early report will be incomplete, and that is fine. Incident understanding evolves; first accounts are drafts. The red flags above are not marks of incompleteness — they are marks of concealment. "We don't know yet, here is how we will find out" is a good sentence. "Nothing to see here" on day two is not.

The one idea to keep

An incident report is not a technical document with a management summary attached. It is a governance document with technical evidence attached. Its real subject is never just the attacker — it is whether your organisation can see, decide, and change. Read the timeline for your blindness, the root cause for your honesty, and the remediation for your follow-through. The attacker wrote the incident. Your organisation writes the report, and the report tells you which one of them should worry you more.

SIEM Deployment Lessons from Two Very Different Organizations →

← All writeups