When an incident is contained and systems are back online, the pressure shifts to paperwork. Your board wants answers, your insurer wants evidence, and a regulator may want notification within days. A cyber incident response report is the document that gives each of them what they need, and a rushed or vague one can cost you a claim, a contract or your credibility.
In short, a good cyber security incident response report is a factual, time-stamped record of what happened, what it affected, what you did and what changes next. Write it while details are fresh, keep opinion separate from evidence, and tailor the summary to a non-technical reader. In the UK, you must tell the ICO within 72 hours if personal data is at risk.
This guide walks through the key sections to include, from the executive summary and timeline to root cause, impact and lessons learned. It also covers a simple template and who to notify, and when. It draws on our experience at TrustedIA, where our CyberSOS team helps businesses, insurers and loss adjusters recover from incidents and document them properly.
Why a cyber incident response report matters
Who reads it and what they need
Every report has several audiences, and each reads it for a different reason. Write for the least technical reader first, then push the detail into appendices for the people who need it. The table below shows what each group usually looks for.
| Reader | What they look for |
|---|---|
| Board and directors | Business impact, cost, decisions needed |
| Insurer or loss adjuster | Timeline, evidence, costs incurred, policy conditions met |
| Regulator (ICO) | Whether personal data was affected, how many people, your response |
| Customers and partners | What happened to their data and what you have done about it |
| IT and security team | Root cause, indicators of compromise, technical fixes |
One document can serve all five if you structure it well. Lead with a plain-English summary, then add the timeline, impact and technical findings underneath. That layout stops your board wading through log extracts and stops your engineers hunting for the detail they need.
What happens without a proper record
Memory is the first casualty of an incident. Within a week, people forget which account was disabled first or when the restore began. Gaps in the timeline make it hard to show an insurer that you acted promptly, and a vague account can slow or even jeopardise a claim. Loss adjusters will test your figures, so every cost and decision needs a date and an owner.
Regulators take a similar view. Under UK GDPR you must keep a record of every personal data breach, even those you decide not to report. If the ICO later asks why you made that call, your report is the evidence. The ICO’s guidance on reporting a breach sets out what it expects, and the maximum fine for serious infringements is £17.5 million or 4% of global annual turnover, whichever is higher.
A response you did not record is a response you cannot defend, repeat or improve.
Finally, there is the cost of repeating yourself. Without a written root cause, the same weak password policy or unpatched server survives into the next quarter. Standards expect better. ISO 27001 (Annex A 5.27 in the 2022 edition) requires you to learn from incidents, and auditors will ask to see the evidence. A well-written cyber incident response report is that evidence, and it turns a bad week into a documented improvement plan.
Step 1. Capture the facts while the incident unfolds
Your cyber incident response report is only as good as the notes behind it. Start recording the moment you declare an incident, not when the pressure drops. Reconstructing events from memory a week later is how timelines end up with holes.
Appoint a scribe and keep one running log
Name one person as the incident scribe and take them out of the technical work. Their only job is to keep a single running log in a shared location, with every entry time-stamped. Pick one time zone, UK local time or UTC, and use it throughout.
Log decisions as you make them, because nobody remembers them accurately afterwards.
A simple pipe-separated format is enough:
2026-10-09 09:42 | Source: Helpdesk | Finance reports files renamed with .locked extension
2026-10-09 09:55 | Owner: J. Patel | Decision: isolate file server FS02 from the network
2026-10-09 10:20 | Owner: A. Moore | Action: disabled admin account svc-backup
Record facts, not theories
Separate what you know from what you suspect. Label guesses as hypotheses and update them once confirmed. Each entry should help answer these questions later:
- When and how was the incident detected, and by whom?
- Which systems, accounts and data are affected?
- What action was taken, by whom, and why?
- Which decisions were made, and who approved them?
- Who has been told so far, and when (insurer, customers, ICO)?
- What costs are building up, such as consultants, overtime and replacement hardware?
Preserve the evidence
Finally, protect your evidence before anyone rebuilds a machine. Take forensic images, export logs and record hash values so you can prove the files were not altered. Keep short chain-of-custody notes saying who handled each item and when. Anyone reviewing your cyber security incident response report will ask where a claim came from, and this is how you answer.
Step 2. Write the core sections of the report
With your log and evidence in hand, you can draft the document. A typical cyber security incident response report runs to six to ten pages, with logs and screenshots in appendices. Use the same headings every time, so readers know where to look and you can compare one incident with the next.
The sections to include
Work through the sections below in order. The executive summary sits first on the page, but write it last, once the facts are settled.
| Section | What to write |
|---|---|
| Executive summary | Five sentences: what happened, impact, status, decisions needed |
| Incident details | Date detected, incident type, severity, incident owner |
| Timeline | Time-stamped events from your log, from first compromise to recovery |
| Impact | Systems, data, people affected, downtime and financial cost |
| Root cause | How the attacker got in and which weaknesses allowed it |
| Response actions | Containment, eradication and recovery steps taken |
| Notifications | Who was told, when, and any reference numbers |
| Lessons and actions | Fixes, each with an owner and a deadline |
Write the summary and root cause carefully
Most readers never get past page one, so your summary must stand on its own. Keep it plain and free of jargon. Here is a skeleton you can copy:
What happened: Ransomware encrypted our file server on [date].
Impact: [number] staff lost file access for [hours]. No customer data confirmed taken.
Cause: Compromised VPN account without multi-factor authentication.
Status: Contained and restored from backup. Monitoring continues.
Decision needed: Approve [amount] for multi-factor rollout.
Root cause needs separating from the trigger. The trigger might be a phishing email, but the root cause is the missing multi-factor authentication that let a stolen password work. Keep asking "why" until you reach something you can fix. Describe failed controls and processes, never named individuals.
A root cause you can fix is worth more than a culprit you can name.
Finally, keep facts and opinion apart. Put confirmed findings in the body and label anything unproven as a hypothesis, so an insurer or auditor can see exactly what you can evidence.
Step 3. Work out who you must notify and when
Know the deadlines before you need them
Notification clocks start when you become aware of an incident, not when your report is finished. Log every call and email with a time and a reference number, because that log feeds the notifications section of your cyber incident response report. The table below covers the usual duties for a UK business.
| Who | When | Trigger |
|---|---|---|
| ICO | Within 72 hours of becoming aware | Personal data breach likely to risk people’s rights and freedoms |
| Your insurer | Often 24 to 72 hours, so check your policy | Any incident that could lead to a claim |
| Affected individuals | Without undue delay | High risk to them |
| Sector regulator (such as the FCA) | Promptly, or as its rules state | Regulated firms and essential services |
| Police and NCSC | As soon as practical | Criminal activity such as ransomware or fraud |
Read your policy before an incident happens. Late notice can void cover, and many insurers also require you to use their approved responders.
Report to the ICO with what you know
Under UK GDPR, you only report breaches that are likely to put people at risk, but you must record the decision either way. If you are unsure, use the ICO’s breach reporting guidance to assess the risk. You can report in phases, so submit what you know within 72 hours and add detail later.
Report on time with incomplete facts, then update the ICO as they firm up.
If you miss the deadline, explain the reasons for the delay in your submission.
Tell affected people clearly
Where the risk to individuals is high, you must tell them without undue delay. Use plain language and include these points:
- What happened and when you found out
- What data was involved
- The likely consequences for them
- What you have done to contain it
- What they should do, such as changing passwords
- A named contact for questions
Finally, keep copies of everything you send. Paste the final wording and send dates into your report, so the record shows who knew what, and when.
Step 4. Review, finalise and learn from the report
A draft is not yet a finished cyber incident response report. Before it reaches the board, your insurer or the ICO, give it a proper review, then use it to change how you work.
Check the draft before it goes out
Ask someone who was not involved in the incident to read it cold. If they cannot explain what happened after page one, rewrite the summary. Get your legal adviser or data protection officer to check anything going to a regulator, and classify the document so it is shared only with people who need it. Work through this list:
- Does the summary make sense without the rest of the report?
- Does every timeline entry match your running log?
- Do costs, dates and headcounts agree across all sections?
- Is every unproven claim labelled as a hypothesis?
- Have passwords, keys and unnecessary personal data been removed or moved to restricted appendices?
Turn findings into owned actions
Hold a lessons-learned meeting within two weeks, while details are still fresh. Keep it blameless. You are examining controls and processes, not people. Ask what worked, what failed, and what would have shortened detection or recovery.
Then convert every finding into a named action. Each action needs an owner and a deadline, as in the table below.
| Action | Owner | Deadline |
|---|---|---|
| Enforce multi-factor authentication on all remote access | IT Manager | 30 days |
| Test restoring the file server from backup | Infrastructure lead | 60 days |
| Run phishing simulation for finance staff | Security lead | 90 days |
An action without an owner and a deadline is just a wish.
Close the loop
Track the actions to completion and review progress monthly until each one is closed. Add the incident to your risk register, and update your incident response plan with anything the response exposed. ISO 27001 auditors expect to see this evidence of continual improvement.
Finally, test the changes. A short tabletop exercise based on this incident shows whether the fixes work before a real attacker does.
Turning your report into better resilience
A strong cyber incident response report does one job well. It gives every reader the facts they need, in the order they need them, from the board’s summary to the engineer’s indicators of compromise. Capture events as they happen, use the same sections each time, meet your notification deadlines and review the draft before it leaves the building.
The real value comes afterwards. A report that ends in owned, dated actions turns one bad week into fewer bad weeks. It also gives insurers, auditors and regulators proof that you learn from incidents. Keep the template, test your fixes and update your plan.
If you would rather not face the next incident alone, TrustedIA can help. Our CyberSOS team supports recovery and documentation, and our ISO 27001 experts can build the process around it. Talk to TrustedIA about incident response support before you need it.
