Guides

How to Write a Cybersecurity Incident Report

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

A cybersecurity incident report is a clear, factual document that explains what happened, when, what was impacted, what you did, and what you will change next. Companies hire analysts who can write this under pressure: executives need decisions, engineers need actions, and auditors need evidence — not panic poetry.

Facts → Timeline → Impact → Actions → Lessons
Opinions and blame belong in a separate retro, not the factual report

What do I need before this guide?

• IR first 24 hours for response order.
• What is a SOC? for who writes what.
• A text editor and a ticket number habit.

What does a good report look like?

Readers and what they need:

1. Leadership — severity, business impact, are we safe now, next decision.
2. SOC / IR peers — timeline, pivots, evidence locations.
3. Engineering — exact systems, configs, patches, owners.
4. Legal / compliance (when involved) — facts, retention, notification triggers — follow your policy; this guide is not legal advice.

Educational warning: never invent certainty. Write “suspected” when you mean suspected. Never paste real secrets, full card numbers or private customer data into a widely shared doc — link to a restricted evidence store instead.

Real incident reporting lesson (public, high level)

After major public breaches, regulators and customers repeatedly ask the same questions: when did you know, what data classes were involved, what did you do, and what controls failed. Teams that kept a running timeline during the incident wrote better external statements later. Care-take:

1. Start the timeline at hour zero — not on Friday when memory fades.
2. Separate facts from hypotheses.
3. Record who authorised containment that affects customers.
4. Preserve ticket IDs and log query links.
5. Schedule lessons-learned while details are fresh (IR guide).

Red Team vs Blue Team (reporting angle)

How do I write the report step by step?

Step 1 — Create the shell immediately

1. Ticket ID / incident ID.
2. Severity (use your org’s scale).
3. Incident commander name.
4. Status: investigating / contained / monitoring / closed.
5. Distribution list (need-to-know).

Step 2 — Write the executive summary last (but draft bullets first)

1. What happened in one sentence.
2. When it started and when you detected it.
3. Current risk to customers and ops.
4. What you already did.
5. What decision you need (if any).

Step 3 — Build the timeline

1. Use IST for local teams; add UTC if global.
2. One row per material event: detection, containment, erase, restore, comms.
3. Cite sources: SIEM alert ID, EDR case, email ticket.
4. Do not backdate guesses — mark approximate times explicitly.

Step 4 — Impact and scope

1. Hosts / accounts / apps affected.
2. Data classes (none / internal / personal / secrets) — high level.
3. Duration of exposure if known.
4. Customer-visible impact (downtime, email risk, etc.).

Step 5 — Actions and evidence

1. List containment actions with timestamps and owners.
2. Point to evidence locations (bucket path, case ID) — not raw dumps in Slack.
3. Note outstanding actions with due dates.

Step 6 — Lessons with owners

1. Detection gap (missing log source / weak rule).
2. Process gap (slow escalate / unclear owner).
3. Control gap (MFA missing / over-broad role).
4. Each lesson gets an owner and a date — or it is wallpaper.

Quick vocabulary

1. Executive summary — short forwardable status for leadership.
2. Residual risk — what danger remains after containment.
3. IOC — indicator of compromise (user, IP, hash) shared carefully.
4. Need-to-know — limit distribution of sensitive details.
5. Lessons-learned — owned improvements after the incident.

Audience checklist before you hit send

1. Would a new L1 understand the timeline without Slack archaeology?
2. Would legal/comms be surprised by a fact you asserted?
3. Did you mark unknowns clearly?
4. Are secrets redacted?
5. Is the next action and owner obvious?

Care-take — writing hygiene

1. Facts first; hypotheses labelled.
2. No passwords, API keys or full PAN/Aadhaar in the doc.
3. Version the report (v0.1 running → v1.0 closed).
4. Align public statements with legal/comms — analysts draft facts only.
5. After close, file lessons into detection backlog.
6. Practise on fictional tabletop incidents before a real night shift.

Mini template you can copy

INCIDENT REPORT — INC-____
Severity:  Status:  Commander:
1) Summary (5 lines)
2) Timeline (IST)
   - HH:MM event (source)
3) Impact (systems / data / customers)
4) Root cause (known / suspected)
5) Actions taken + pending
6) Evidence index (restricted links)
7) Lessons + owner + due date
8) Distribution

How do I fix common report mistakes?

Ghabru naka 😅 — these are the usual ones: