Incident Management on Spreadsheets: When It Works and What Breaks First

Most incident logs start in a spreadsheet, and for good reasons. It exists already, everyone can use it, it takes no procurement and no project, and it can be shaped to the way a particular site actually works in an afternoon. Very few purpose-built systems can claim all four.

So the useful question is not whether spreadsheets are a bad way to manage incidents. It is which part gives way first, at what point, and what can be done about each stage without necessarily changing tools.

When a spreadsheet is still the right tool

It is worth being direct about this, because a lot of what is written on the subject is not.

A spreadsheet remains a capable incident log when all of the following hold:

• One site, or one operation small enough that one person has the whole picture in their head
• One person maintaining the file, with everyone else contributing through them
• A volume low enough that nothing is forgotten between reviews
• Corrective actions that close within weeks, while the people involved are still in post
• No obligation to produce evidence of follow-up to a third party at short notice

If that describes your operation, the log is not your problem and changing it will not make anything safer. The rest of this article will still be useful as a list of things to watch for, but there is no urgency in it.

What breaks first

The failures do not arrive together. They arrive in a fairly consistent order, and recognising which one you are in tells you what to fix.

1. The follow-up, before the log

The first thing to notice is that the log itself usually stays accurate. Incidents get recorded, dates are right, descriptions are reasonable. What decays is everything downstream: the corrective action, its owner, the date it was due, and whether anyone confirmed it worked.

The reason is structural rather than cultural. A spreadsheet records events well and obligations poorly. A row can hold what happened. It has no way to chase anybody, and a due date in a cell is only as good as the person who remembers to sort by it. So the log becomes an accurate account of events and a poor account of responses, which is the opposite of what it is for.

This is the point at which most organisations discover the distinction matters, usually because someone asks what was done about an incident from eight months ago. Keeping the action, the incident it came from and the verification as one connected record, rather than three places that have to be cross-referenced, is the specific problem worth solving, and it is how ENSURE is put together.

2. The single copy

The second failure arrives with the second person. Two people need to write to the file in the same week, or someone needs to report from a phone while standing in front of the thing that happened.

What follows is familiar: a copy on someone's desktop, a version in an email thread, a shared drive copy that may or may not be current, and a period of reconciliation that nobody has time for. The log stops being a single source and becomes several accounts of the same month.

3. The evidence around the record

An incident is rarely just a row. It comes with photographs, a witness account, a permit, a shift handover note, a medical record, sometimes a supplier's report.

None of that fits in a cell, so it goes into email and a folder, connected to the incident by a reference number and someone's memory. It works while that person is there. It does not survive their departure, and it is the part that is hardest to reconstruct afterwards, because the material still exists and nobody can say with certainty which version was the one considered at the time. Keeping evidence attached to the record it belongs to, rather than filed near it, is what makes this recoverable years later.

4. The history of changes

The fourth failure is the one that matters most after a serious event, and it is the least visible day to day.

The question is not who edited the file. It is narrower than that: who changed the severity rating from major to minor, on what date, and on what basis. Who moved the closure date. Who marked the action complete, and what did they see that satisfied them.

A spreadsheet cannot answer any of that after the fact, and the absence is not neutral. It reads as a gap in exactly the circumstances where a clear account is most valuable, whether the reader is an auditor, an insurer or an investigating authority.

5. Comparison, not counting

The last to break is analysis, and it breaks more quietly than the rest.

Most logs can produce a count. What they do not easily produce is comparison: this shift against that shift, this site against the group, this quarter's near miss rate adjusted for the fact that one site reports everything and another reports almost nothing. Raw counts across sites with different reporting cultures are close to meaningless, and the work of correcting for that by hand is the reason it is rarely done twice.

Two consequences worth naming

Under-reporting caused by friction. If reporting a minor event means finding the file, asking for edit access and typing into a shared sheet, minor events stop being reported. Serious ones always get through, because someone escalates them. The near misses and first-aid cases are the ones that quietly disappear, and those are the leading indicators the whole system depends on. A drop in reported near misses is usually a reporting problem before it is a safety improvement.

The question that cannot be answered quickly. After a significant event, someone will ask for every similar incident in the last three years and what was done about each one. It is a reasonable question, and answering it from a spreadsheet plus an inbox plus a shared drive takes days of work that is difficult to warrant afterwards.

What to fix before changing anything

Several of these problems can be reduced substantially without buying a system, and it is worth doing that first, if only because it clarifies which of them are really about the tool.

• Separate the log from the action listKeep the incident record as the account of what happened, and give corrective actions their own list with one owner and one date each. Most of the decay described above happens because these two things share a row.
• One file, one owner, everyone else read-onlyContributions come through a form or through the owner. It is less convenient and it ends the version problem outright.
• Adopt a folder convention and use the reference numberOne folder per incident, named by reference, holding every attachment. Unglamorous, and it is what makes the record retrievable in three years.
• Write decisions down, not just outcomesWhen a severity rating or a closure date changes, add a dated line saying who changed it and why. It is a poor substitute for a real audit trail and far better than nothing.
• Review monthly, brieflyTwenty minutes a month on open actions catches more than a thorough annual review, because the people involved are still there and still remember.

What ISO 45001 actually requires

The standard does not prescribe a tool, and it is worth knowing precisely what it does ask for.

Clause 7.5 requires documented information to be controlled, identifiable and retrievable. Clause 10.2 requires evidence of the nature of incidents, the actions taken, and the results of any corrective action, including its effectiveness. Nothing there rules out a spreadsheet.

Signs the threshold has been crossed

Crossing one of these is usually workable. Three at once is where the effort of working around the tool starts to exceed the effort of replacing it.

• More than one site or shift reporting into the same log
• More than one person needing to update it in the same week
• Corrective actions that outlive the person who raised them
• Evidence that must be retained with the record and produced on request
• Questions about patterns across years, asked at short notice
• Reported near misses falling while nothing else has changed

If you do move, move less than you think

The common mistake is treating migration as an archiving project. Five years of history is imported, most of it incomplete, and the new system opens on the first day already full of records nobody trusts.

A better approach is to move open items only: incidents still under investigation, and actions still outstanding. Historical records stay where they are, retained and retrievable, which is all the standard asks of them. The new system then starts clean, and the first complete year in it is genuinely comparable with itself.

A practical starting point

Take the last incident closed in your log. Try to assemble, in one place, four things: the record of what happened, the investigation, the evidence considered at the time, and the confirmation that the corrective action worked.

If that takes a few minutes, the current arrangement is holding. If it takes an afternoon and a conversation with someone who has left, that is the answer, and it is a more useful one than any general argument about spreadsheets.