Preparing incident records for an inquiry is work done before the incident rather than after the request arrives. Plan the record while planning the response, and the evidence forms as a by-product of the work. Chronosoft is built around that sequence, so a verified evidential report is produced at the click of a button rather than assembled under time pressure.
Edward Swete Kelly, Chronosoft’s founder and a former paramedic and control room manager, makes the point plainly. Plan and prepare in the lead-up, and the outcome forms naturally.
The alternative is a scramble, and a scramble is visible in the result.
Before the incident: build the record into the plan
Readiness starts with the plan, because incident records reflect the structure that produced them. If the plan already defines who records what, at which point, and to what standard, the record produced during a response will meet that standard without anyone thinking about it.
Four things belong in the plan rather than in a live incident:
- Which roles capture which information, so nothing depends on who happens to be available.
- The prompts each contributing agency will be asked for, agreed in advance with those agencies.
- The reporting rhythm, and the thresholds that trigger reporting outside it.
- Who is authorised to release an evidential report, and to whom.
Access and credentials sit in the same category. Verified individual accounts have to exist before an incident, because they cannot be retrofitted onto entries already made.
Exercises are where this gets tested. An exercise that produces an unusable record has done its job by revealing that early.
During the incident: capture at the time, by the people present
Three properties determine whether incident records will hold, and all three are set during the response rather than afterwards.
Timing. Entries need capturing at the point of the decision, not written up retrospectively at the end of a shift. A retrospective entry cannot demonstrate what was known at the moment it mattered.
Authorship. Entries need making by someone present inside the decision-making process, rather than by a third party summarising later.
Verification. Contributions need to come from identified, verified users, so each entry ties to a person rather than to a role or a shared account.
These are the questions a regulator asks first, and they are unanswerable after the fact.
After the incident: close out before anyone asks
The window immediately after an incident is the cheapest time to complete the record, because the people involved are still available and still remember.
Three tasks belong here. Confirm the record is complete and that any outstanding corrections have been made properly, with attribution and reasons. Link related incidents so the surrounding context is preserved. Capture lessons into the system rather than into a separate document that will be hard to locate later.
Delay makes each of these harder. Staff move on, memories fade, and a gap noticed two years later cannot be filled honestly.
If the planning did not happen
Some teams face a request for incident records having never prepared for one. The position is recoverable and it needs an honest audit first.
Work through the incident records and establish, for each part of them:
- Whether entries were captured during the incident or written up afterwards.
- Whether the author of each entry was present in the decision-making process.
- Whether contributions were recorded and verified by the people who made them.
- Which entries were corrected, and whether those corrections are visible and reasoned.
Where the answer is unfavourable, say so in the submission rather than allowing it to be discovered. A record accompanied by a candid account of its limitations is a stronger position than one that appears complete until examined.
The UK Government Resilience Framework sets clear expectations around assurance and learning, and the JESIP principles frame the joint working a multi-agency record has to evidence.
Five steps before submitting incident records
- Produce the full record from the system, unedited, rather than a compiled summary.
- Confirm every entry carries an author, a date and a time applied by the system.
- Confirm corrections appear as struck-through, attributed and reasoned changes.
- Attach the linked incidents that constrained decisions during the response.
- Have a named authorised role release the report, and record that release.
How Chronosoft removes the scramble
Chronosoft holds the plan as configuration, so the prompts, the roles and the reporting rhythm are already in the system when an incident starts. Every user on the system holds a credential and is verified, which means attribution is a property of the record rather than an assumption about it.
Information is prompted from each user and each part of the response as the incident runs, so the sequence reflects the process it followed.
The output is a verified evidential report covering who captured what, when they captured it, and what they did. It is produced from the record rather than assembled from it. See also what makes an incident audit trail defensible.
On the specific weakness of retrospective capture, see why writing a post-incident report from memory fails.
Frequently asked questions
How far back should a resilience team expect an inquiry to reach?
Inquiries and regulatory reviews frequently examine incidents several years old, and retention policy rather than memory determines what is available. Records should be kept well beyond the period that feels necessary. Chronosoft retains the full record with attribution intact, so the age of an incident does not weaken what the record can show.
Can a record be improved after a request arrives?
It can be completed and clarified, and it cannot be rewritten. Adding context is legitimate when the addition is dated and attributed as a later entry. Chronosoft prevents alteration of submitted entries, so any post-incident addition is visibly separate from what was captured at the time.
Who should speak to the record during an inquiry?
Usually the person accountable for the resilience function, supported by whoever can explain how the system captured and protected entries. The technical explanation matters as much as the operational one. Chronosoft produces documentation of how attribution and immutability work, which supports that second conversation.
Should lessons learned sit inside the incident record?
Yes, ideally in the same system as the incident they came from. Lessons held in separate documents become difficult to locate and difficult to evidence as having been acted on. Chronosoft holds captured lessons alongside the incidents that generated them, so the link between finding and action stays visible.
What is the most common gap found in submitted incident records?
Entries written up at the end of a shift rather than during the response. The content is often accurate and the timing cannot be demonstrated, which weakens the whole submission. Chronosoft is designed for capture during the incident, so timestamps reflect decisions rather than write-ups.
Be ready before the request arrives
Chronosoft holds the plan, the credentials and the prompts in advance, so incident records for an inquiry are produced as a verified evidential report rather than assembled under pressure. Book a demo with the Chronosoft team to see what a submission from your own arrangements would look like.
For a closer look at the platform itself, explore Chronosoft in more detail.