A defensible incident record survives line-by-line questioning when it sits in one central place, can be interrogated by someone who was not there, and can be linked to the other incidents that shaped the response. Chronosoft produces a record built to meet all three, with immutable entries made by verified users at the time they were captured.
The relevant question is not whether a record exists. It is whether the record can answer questions asked years later by people looking for what was missed.
Three tests decide whether a defensible incident record exists.
Test one: is everything in one central point of reference?
The first test is completeness in one place. A record spread across a control room log, an email chain, a shared drive, a WhatsApp thread and someone’s notebook is not one record. It is five partial records with different rules and different survival rates.
Fragmentation causes two problems under scrutiny. Assembling the account afterwards takes weeks and produces gaps. Worse, the assembly itself becomes contestable, because someone had to decide what to include.
A record held centrally from the outset removes both. The account is not constructed after the fact, because it already exists.
The failure looks like this. Six months after an incident, a resilience team is asked for the decision log and produces a document compiled from several sources by a person who was not on duty.
Test two: can the record be interrogated?
The second test is whether the record withstands examination rather than merely presentation. Edward Swete Kelly, Chronosoft’s founder and a former paramedic and control room manager, frames it as a series of questions the record has to answer under questioning.
Four questions in particular:
- Can it be shown that this is the record of what occurred, rather than a version prepared afterwards?
- Is the record immutable, so entries cannot be altered once made?
- Were entries made by verified users, identifiable individually?
- Were they made at the point in time claimed, rather than reconstructed later?
A record that cannot answer these will be treated as a reconstruction, whatever its actual accuracy. That distinction has real consequences, because a reconstruction invites questions about who reconstructed it and why.
Actions and supporting material belong inside the same test. Decisions rarely stand alone, and the information that informed a decision needs to sit with it rather than in a separate system.
Test three: can related incidents be linked?
The third test is the one most organisations have not considered. An inquiry examines one incident. The response to that incident was shaped by everything else happening at the time.
A record that cannot show the surrounding context leaves a commander explaining resource decisions with no way to demonstrate what else was competing for those resources. That is a weak position, and an avoidable one.
Linking related incidents gives a single reference point that shows the incident under examination alongside the pressures around it. In a critical incident review, that context often explains decisions that look questionable in isolation.
The verdict test for a defensible incident record
Applied together, the three tests produce a simple check. A defensible incident record should let someone with no involvement in the incident answer, from the record alone:
- What happened, in sequence.
- Who knew what, and when they knew it.
- What decisions were made, by whom, and on what basis.
- What else was happening that constrained those decisions.
- Whether anything was corrected after the fact, by whom, and why.
A record that answers all five is defensible. A record that answers the first three is a good log with an exposure.
The UK’s recent inquiry climate has made the defensible incident record a live question for resilience teams rather than a theoretical one. The UK Government Resilience Framework sets clear expectations around learning and assurance, and the JESIP principles frame the joint working that a multi-agency record has to evidence.
How Chronosoft produces a defensible incident record
Chronosoft holds the incident in one place from the first entry. Every entry carries an author, a date and a time, applied by the system rather than typed by a user, and entries cannot be edited once submitted.
Corrections are handled by striking through rather than overwriting, so an error stays visible alongside its correction.
Related incidents can be linked, giving the single overall reference point that a critical incident review needs. The result is an evidential report produced from the record rather than assembled from sources afterwards. For the underlying mechanics, see what makes an incident audit trail defensible.
The formal process this feeds into is set out in the government post-incident review process.
Frequently asked questions
Does a defensible incident record have to be free of errors?
No. Errors and omissions are expected in a live incident, and their presence is not the problem. What matters is that they remain visible, with corrections shown rather than silently applied. Chronosoft keeps original entries intact and shows corrections as struck through, attributed and dated, so the record stays honest about what changed.
Can a spreadsheet or shared document serve as a defensible incident record?
Rarely. Neither reliably prevents editing after the fact, and neither proves who entered what at which time. Both are also easily copied into divergent versions. Chronosoft holds entries immutably against verified users, which is the property a spreadsheet cannot provide regardless of how carefully it is managed.
How long should an incident record be retained?
Retention depends on the sector, the nature of the incident and the organisation’s own policy, and inquiries can arrive many years later. The practical guidance is to retain longer than feels necessary. Chronosoft retains the full record with its attribution intact, so age does not degrade what the record can demonstrate.
Who should be able to produce the evidential report?
A named role with the authority to release it, usually within the resilience or legal function, rather than whoever happens to hold system access. Chronosoft separates the ability to read the record from the ability to produce a formal evidential export, so release stays controlled.
What is the single most common weakness in an incident record?
Retrospective capture. Entries written up after the event, often at the end of a shift, cannot demonstrate what was known at the moment a decision was taken. Chronosoft is designed for capture during the response, so the timestamp reflects the decision rather than the write-up.
Produce a record that holds
Chronosoft holds a defensible incident record in one place, with immutable entries made by verified users at the time of capture and related incidents linked for review. Book a demo with the Chronosoft team and test it against the five verdict questions above.
For a closer look at the platform itself, explore Chronosoft in more detail.