How to Write an Incident Report That Gets Used

What an incident report is actually for

An incident report is the written record of something that went wrong, or nearly went wrong: what happened, when and where, who was involved, what the conditions were, and what was done about it. That is the definition, and it is the least interesting part.

The useful part sits one level down. A report has two readers. The first is the person who has to decide today whether this needs a response beyond the fix that already happened. The second is a colleague two years from now who was not there, cannot ask anyone, and has to reconstruct what you saw.

Write for the second reader and the first one is served automatically. Write for the first one only, and you get a file that closes a shift and answers nothing later.

What belongs in an incident report

Keep the fields boring and fixed. Variation in structure is what makes a set of reports unanalysable.

Identification: date, time, exact location, reference number, reporter.
Classification: incident, near miss, unsafe situation, property damage, environmental release. Pick one from a closed list.
What happened: the sequence of events in plain order, in the words of the people who were there.
Who and what was involved: people, equipment, installation, substances, contractors, third parties.
Conditions at the time: task being performed, permit status, shift, weather, staffing, whether the work was routine.
Immediate actions taken: first aid, isolation, shutdown, evacuation, notification.
Consequences, actual and potential: what did happen, and what could reasonably have happened.
Evidence: photos, readings, log extracts, permit copies, witness statements.
Follow-up: owner, action, due date, and how closure will be demonstrated.

Notice what is not on that list. Cause is not on it, and neither is blame. A report captures observation. Analysis comes after, by people who have the time and the standing to do it.

Write it in this order

The order matters more than the vocabulary. Most bad reports are bad because they start with the conclusion.

Write the facts first, within the shift. Times, positions, sequence. Memory degrades fast and it degrades toward a story that makes sense.
Separate observation from interpretation. "The valve was open" is an observation. "The valve was left open by the night shift" is a conclusion. Put conclusions in a field that is labelled as such.
Use the words the people involved used. If an operator says the line "kicked", write that the line kicked and ask what they mean. Translating it into procedural language deletes the signal.
Attach the evidence while it still exists. A photo taken at the time replaces a paragraph of description and survives disagreement later.
State the potential consequence explicitly. This is the field that drives triage, and it is the field people skip.
Assign one owner and one date. Two owners is no owner.

Where incident reports fail

They rarely fail at the moment of writing. They fail in the gaps around it.

The form is longer than the event. If a four page template has to be filled in during a shift, it gets printed, ticked on paper, and typed in later from memory, or not at all. The length of the form is a design decision about how much truth you will receive.

Near misses never arrive. Reporting drops sharply when the reporter gets nothing back. A reported near miss that produces no visible response teaches the whole team what reporting is worth. We wrote about that pattern in more detail in incident reporting that actually gets used.

Everything goes to the safety team. Not every finding deserves the time of a specialist, but when there is no triage step, everything lands in the same queue and the serious items queue behind a broken light fitting.

The report closes but the action does not. This is the most common one, and it is the reason the "check" and "act" half of the cycle stays weak in so many organisations. The incident is documented. The action is created. Nobody verifies that the action changed anything.

The report is disconnected from everything else. An incident that reveals an out of date procedure, an unfinished change, or a barrier that did not perform should visibly touch those records. If the incident report lives in one system and the procedure lives in another, nothing propagates.

Triage before investigation

Volume is not the problem. Undifferentiated volume is the problem.

Rank every report on potential severity, not on what actually happened. A dropped spanner and a dropped spanner from a walkway above a manned area are the same event and a different report. Low potential items go back to the team that found them and get handled inside normal work. High potential items, the ones where serious injury or a loss of containment was realistically available, get a proper investigation with time allocated to it.

The test is simple: if this had gone slightly differently, what is the worst credible outcome? Ask that before deciding how much effort the report deserves.

Timing, notification and the record

Write the report the same day. Serious workplace accidents in the Netherlands carry a legal duty to notify the Nederlandse Arbeidsinspectie, and the internal record is what you will be working from when that conversation happens. For sites under supervision by a regulator such as DCMR, the same logic runs further: the report is one of the places where the consistency between what your system says you do and what the site actually did becomes visible.

That is also where reports stop being an administrative topic. A single incident report is a document. A year of them is a statement about whether your management system is working, and inspections increasingly read it that way. That shift in what is being examined is the subject of our piece on why generic safety management software falls short for Seveso III companies.

A short test for your own template

Take the last ten reports you filed and check:

Could someone who was not present reconstruct the sequence from the text alone?
Is potential severity filled in, and does it vary?
Does every report with a corrective action have a demonstrated closure, not just a closed status?
Can you find every report that touched the same installation in under a minute?
Did the person who reported it ever hear what happened next?

If the answer to the last one is no, fix that before you touch the template. Software will not repair a reporting culture that gives nothing back, and the shape of your workflow matters more than the fields in your form. We cover that side in our overview of EHS incident management.

Where to start

A better incident report is not a better form. It is a shorter path from what someone saw to what someone changed.

If you want to look at how your current reports move through that path, and where they stop, we are happy to go through a handful of real ones with you. No demo required, and you will get a straight answer about whether your process needs software at all.