An incident audit trail is trustworthy when every entry is immutable and attributed, corrections stay visible rather than replacing the original, and the whole record sits in a system that genuinely prevents alteration. Chronosoft holds all three properties as standard, so the audit trail can be relied on months after the incident closed.
Three tests cover an incident audit trail. Each has a specific failure mode, and each failure is discovered at the worst possible time.
Test one: is every entry immutable and attributed?
Immutability means an action recorded in the audit trail cannot be edited afterwards. Attribution means each entry carries the identity of the person who made it.
Edward Swete Kelly, Chronosoft’s founder and a former paramedic and control room manager, sets the minimum for each entry as an incident number, an author, a date, a time, and the substance of the entry itself. All five, on every line.
The failure mode is quiet. A system that permits editing does not announce that an entry was changed, so a record can be entirely accurate and still be indefensible, because nobody can demonstrate that it was not altered.
Applied timestamps matter as much as recorded ones. A time typed by a user is a claim. A time applied by the system is evidence.
Test two: are corrections visible?
Records made under pressure contain errors. That is expected and it is not the problem.
The problem is invisible correction. When an entry is removed or overwritten, the record loses the fact that something changed, and with it the ability to show good faith.
A correction handled properly is struck through rather than deleted, signed by whoever made it, dated, and given a reason. The original stays readable. Both the mistake and its correction remain part of the source of truth.
An incident audit trail containing visible errors is stronger than a clean one that cannot prove it was always clean.
Test three: is the record actually protected?
The third test is where most organisations are weakest. A record is only as trustworthy as the environment holding it.
The question is whether the record sits in a system proven to prevent alteration, or in a document that could have been amended, edited or replaced by someone with file access. A document on a shared drive has no answer to that question.
Protection covers access control, alteration prevention and the ability to demonstrate both. The National Cyber Security Centre publishes guidance relevant to holding records of this kind, and ISO 27001 certification is the assurance most UK procurement processes will ask about first.
The incident audit trail tests as a checklist
| Requirement | What it means in practice | How it fails |
|---|---|---|
| Immutable entries | Entries cannot be edited once submitted | Editable log, so accuracy cannot be demonstrated |
| Author on every entry | Named, verified individual, not a shared account | Shared logins destroy attribution entirely |
| System-applied date and time | Timestamp set by the system, not typed | Retrospective entry indistinguishable from live capture |
| Incident reference on every entry | Each entry ties to a specific incident | Orphaned entries that cannot be placed in sequence |
| Struck-through corrections | Original visible, correction signed, dated, reasoned | Overwrite or deletion, so the change itself vanishes |
| Protected environment | System proven to prevent alteration | File on a drive that anyone with access could change |
| Evidential export | Report produced from the record on request | Manual assembly, which is itself contestable |
Why spreadsheets and documents fail all three tests
Many resilience teams still run an incident log in a spreadsheet or a document, and it is worth being direct about why that fails rather than treating it as merely untidy.
Entries can be edited with no trace. Timestamps are typed, so they record a claim rather than a fact. Shared file access means attribution rests on whoever was logged in. Copies diverge, producing several versions with no way to establish which is authoritative.
None of this reflects poor practice by the teams involved. The format simply cannot hold the properties an incident audit trail requires.
For the wider question this feeds into, see whether an incident record will stand up in a public inquiry.
How Chronosoft holds the audit trail
Chronosoft applies attribution and timestamps at the system level, against verified users rather than shared accounts. Entries cannot be edited after submission.
Corrections are recorded by striking through, with the author, date and reason attached, and the original entry stays readable alongside.
Every entry carries its incident reference, which is what allows the sequence to be reconstructed and related incidents to be linked. An evidential report is produced from the record itself rather than assembled by hand.
The consequences of holding no usable record are covered in the cost of having no incident record at all.
Frequently asked questions
Can an entry in an incident audit trail ever be deleted?
Not in a defensible system. The correct handling is to strike the entry through, leaving it readable, with an author, date and reason recorded against the change. Deletion removes the evidence that something was changed. Chronosoft does not permit deletion of submitted entries, so the audit trail always shows what was corrected and why.
Do shared logins break an incident audit trail?
Yes, comprehensively. A shared account means no entry can be attributed to an individual, which removes the property the audit trail exists to provide. Under-licensing is the usual cause. Chronosoft scopes access by role so partner and occasional users can be given appropriate accounts without a full seat each.
How does an incident audit trail differ from a decision log?
A decision log records choices and their rationale. An audit trail records everything that happened, including the actions, information and corrections around those choices. The decision log is a subset. Chronosoft holds both in one record, so a decision can be read alongside what was known at the time it was made.
Is a timestamp enough to prove when an entry was made?
Only where the system applied it and the entry cannot be altered afterwards. A typed time proves nothing, and a system-applied time on an editable record proves very little. Chronosoft applies timestamps automatically and prevents subsequent editing, so the time and the content stand together.
What should a resilience team check first in an existing audit trail?
Whether an entry made yesterday can be edited today. That single test usually settles the question. Chronosoft is built so the answer is no, and so any correction made instead appears as a struck-through, attributed and reasoned change.
Hold a trail that stands up
Chronosoft keeps an incident audit trail with immutable, attributed entries, visible corrections and an evidential export produced from the record itself. Book a demo with the Chronosoft team and test the three requirements above against it.
For a closer look at the platform itself, explore Chronosoft in more detail.