Seven weeks after the flooding, an emergency planning officer at a district council is asked for one document. Not the plan, and not the risk register. An account of what the council actually did, in what order, and who decided what.
A post-incident report is not a piece of writing. It is an assembly job, and the only material available is whatever somebody captured while the incident was still running. Nobody writes their way out of a gap in the record. If the moment a rest centre was opened went uncaptured, the report either guesses or stays quiet. To a committee, those two answers look the same.
A post-incident report is the written account of what an organisation knew, told, did and decided during a disruption, assembled from records created at the time. Its credibility rests on the completeness of those records, not on the quality of the writing that comes afterwards.
What Is A Post-Incident Report?
A post-incident report is a structured account of a disruption and an organisation's response to it, produced afterwards for leadership, elected members, regulators, insurers or auditors. It sets out what happened, who was informed, which actions were taken, which decisions were made, and what the organisation intends to change.
It isn't a debrief note. A debrief gathers impressions from the people involved while those impressions are still fresh. The report is the formal, attributable version that leaves the building, and it has to survive a reader who wasn't there and who may be unsympathetic. What the debrief produces then needs chasing, which is its own discipline, covered in our piece on tracking debrief actions across agencies.
Why Does A Post-Incident Report Get Harder To Write Every Week You Wait?
Recollection decays, and the people holding it move on. Within a fortnight the sequence of a long night blurs. Within three months duty officers have changed role, the phone that carried half the coordination has been wiped, and the group chat has been cleared. The record exists already, or it is gone.
This is the part that catches resilience teams out. The instinct after a hard week is to let everyone recover and write the report later. That is humane, and sensible, and it quietly destroys the evidence. Response and record-keeping are one activity, not two in sequence.
What Will A Scrutiny Committee Actually Ask?
A scrutiny committee asks about timing, authority and consequence: when the council knew, who it told, who authorised the response, and what happened to the people affected. In England and Wales such a committee is not limited to inviting a witness. It can require attendance.
Section 21 of the Local Government Act 2000 lets an overview and scrutiny committee require members of the executive and officers of the authority to attend before it to answer questions, and it puts a duty on those people to comply. So the questions are rarely about whether the response was perfect. They are about whether the council can account for it.
Public bodies elsewhere in Europe meet the same demand through a different door. The European Commission's summary of the NIS2 Directive confirms the regime now covers public administration at central and regional levels, and that entities in scope must notify national authorities of significant incidents. In the United Kingdom, section 2 of the Civil Contingencies Act 2004 already requires Category 1 responders to maintain plans and to maintain arrangements to warn and inform the public. That is the activity a report is later asked to evidence.
As at November 2026, that is the position in both regimes. This is orientation and not legal advice. The deadlines that bind any one organisation come from its own regulator and its own constitution.
Which Records Have To Exist Before The Report Is Written?
Six records have to exist before the report can be written: the first alert, the delivery and acknowledgement data, the role assignments, the decision entries, the task records and the improvement actions. Each one can only be created at a particular moment during the incident, and not afterwards.
The table below maps the question a committee asks to the record that answers it, and to the point at which that record has to come into existence.
| What the committee asks | The record that answers it | When it has to be created |
|---|---|---|
| When did you first know? | The initial alert or report, with the time it was raised and the person who raised it | The moment the incident is raised |
| Who did you tell, and did it reach them? | Delivery and acknowledgement data for each recipient and channel | As each message goes out |
| Who was in charge? | Named incident role assignments, with the time each was accepted | At activation |
| On what basis did you decide? | A decision entry holding the options, the choice, the person and the time | At the point of decision |
| Did the critical actions happen? | Task records showing owner, deadline and completion time | As tasks are assigned and closed |
| What are you changing? | Improvement actions with a named owner and a review date | At the debrief |
Read the right-hand column again. Not one of those records can be manufactured in week seven. A council that keeps a decision log live while the incident runs, as described in keeping a decision log during a multi-agency incident, ends up with a report that largely writes itself. A council that doesn't has a writing exercise and no source material.
How Does Crises Control Support A Post-Incident Report?
Crises Control captures the operational record while the incident runs, so the report is compiled from activity instead of reconstructed from memory. Its Audit and Reporting capability records every incident action automatically as it happens, and puts every update, acknowledgement and task into a single incident timeline.
From that timeline, incident reporting software produces an Executive Summary Report, a Detailed Incident Report and an Audit Trail Report, exportable as PDF or CSV, for leadership, regulators and post-incident reviews. Organisations running an ISO 22301 business continuity management system can use those records as supporting evidence. Crises Control's own certifications, among them ISO 22301, ISO 9001, ISO/IEC 27001 and Cyber Essentials Plus, are listed on its accreditation page.
Two honest limits. The audit trail is built from live platform activity, which is why it cannot be reconstructed after the fact, and equally why a decision taken in a corridor and entered nowhere never appears in it. And the platform evidences the response. It does not justify it. Whether opening one rest centre instead of three was the right call stays a judgement for the council's own officers and members to defend. That is where public bodies pair the operational record with the wider continuity picture in business continuity software and the sector view on public sector incident management software.
Post-Incident Report Checklist
- One timestamped record of when the incident was first raised, and by whom.
- Per-recipient delivery and acknowledgement data for every message sent, rather than a count of messages.
- Named role assignments with the time each role was accepted.
- A decision entry for each significant choice, holding the options considered and the person accountable.
- Task records showing owner, deadline and completion time for the actions that mattered.
- One chronological timeline a reader who was not present can follow unaided.
- Improvement actions with an owner and a review date, tracked after the report is filed.
- The whole set exportable in a format that can go straight into a committee pack.
Record It Once, Account For It Forever
The organisations that find this straightforward are rarely better writers. They are the ones that stopped treating the record as paperwork to catch up on and started treating it as part of the response. Every acknowledgement, assignment and decision lands in one place as it happens, and the document a committee eventually reads is a view of that rather than a reconstruction of it.
The test is cheap to run. Take the last incident of any size and try to answer the six questions in the table above using only what was written down at the time. Whatever you can't answer is the gap that gets found in public, by somebody entitled to require an answer.
To see how the operational record is captured and turned into a report during a live incident rather than after one, request a demo and ask to be shown the incident timeline and the audit trail export.
Frequently Asked Questions
What should a post-incident report include?
A post-incident report should set out what happened, who was informed, which actions were taken and which decisions were made, each with a time and a named person. A report built from records created during the incident is far harder to dispute than one assembled from recollection afterwards. It should close with improvement actions that carry an owner and a review date.
How soon after an incident should the report be produced?
The deadline is set by whoever is asking, not by good practice. Regulatory regimes impose their own notification and reporting windows, and a committee cycle fixes the date a written account has to be in the papers. The real constraint sits earlier: the quality of the report is decided during the incident, not during the week it is written.
What is the difference between a post-incident report and a debrief?
A debrief is a conversation held soon after an incident to gather impressions from the people involved. A post-incident report is the formal, attributable account that goes to leadership, elected members or a regulator. A debrief produces learning; a report produces evidence. Most organisations need both, and the actions agreed at the debrief belong in the report.
Can a post-incident report be written from memory?
It can be written, but it won't hold up. Memory supplies a narrative and not a timeline, and the questions asked afterwards are almost all about when something happened, who authorised it and whether it was acknowledged. Anything not captured while the incident was running cannot be recovered by writing harder. See how councils evidence what was received in proving who received an emergency alert.
Does incident reporting software write the report for you?
No. Software of this kind captures and assembles the operational record, then generates summary, detailed and audit-trail reports from it. The analysis, the judgement about whether the response was proportionate, and the improvement actions stay the organisation's own work. What it removes is the reconstruction, which is the part that fails under scrutiny.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
