Incidentenrapport: What to Write and What to Leave Out

An incidentenrapport is not a description of an event

Most incident reports are accurate and useless at the same time.

They tell you the pump failed, the operator slipped, the tank overflowed. They are filed, numbered, closed. And eighteen months later the same finding comes back in a different building, written by a different person, with the same three sentences under "cause".

The problem is rarely the writing. It is what the report is understood to be for. An incidentenrapport is not a record of what happened. It is a record of what you now know that you did not know before the incident, and what you changed because of it.

Everything below follows from that.

The melding and the report are two different documents

A near miss or an incident gets reported by somebody on the werkvloer. That melding should be short, fast and low-friction: what, where, when, who to call. Make it any heavier and people stop reporting.

The incidentenrapport comes later, after investigation, and it carries a different load. It has to survive being read by someone who was not there: a new colleague, an auditor, your own successor, a Nederlandse Arbeidsinspectie inspector, or for a Seveso site the inspection partners including DCMR.

Collapsing the two is the most common structural mistake. Either the melding becomes a four-page form that nobody fills in honestly, or the report stays at melding depth and never becomes evidence of anything.

What belongs in an incidentenrapport

Keep the list short enough that it gets completed every time:

• Identification and classification. Reference number, date, location, installation or asset, and the severity classification you actually use. If you work with a SIF or high-potential ranking, record it here, because this field decides who spends time on the case.
• Factual course of events. Time, place, installation state, people present, shift handover, permit status, weather if relevant. Separate observation from interpretation. If something is a reconstruction, say so in the sentence.
• Immediate measures taken. What was done in the first hour, by whom, and whether the installation was returned to service.
• Analysis. The method used, what it produced, and where the analysis ran out of evidence. An honest gap is worth more than a confident guess.
• Affected barriers. Which lines of defence were supposed to work, which ones did work, and which ones turned out to be weaker than the documentation suggested.
• Corrective and preventive actions. Owner, deadline, and the criterion by which the action can be called finished.
• Verification. How and when you will check that the measure had the intended effect, and who signs that off.
• Notification record. Who was informed internally, and whether a statutory notification was required.

That last point is worth stating plainly. The Arbowet obliges an employer to notify the Nederlandse Arbeidsinspectie without delay of an accident resulting in death, hospital admission or lasting injury, and to keep a list of those notified accidents. That obligation sits next to your internal process, not inside it. Check how your own procedure routes it, because "we assumed the manager had called" is a sentence that shows up in investigation reports more often than anyone would like.

Write it in this order

1. Freeze the facts first, while they are still recoverable. Photos, logs, settings, permit, names. Memory of a shift degrades within a day.
2. Write the timeline before the cause. If you write the cause first, the timeline becomes an argument for it.
3. Mark every unknown as unknown. "The valve position at 14:10 could not be established" is a usable finding. A plausible-sounding reconstruction is not.
4. Then analyse. Whatever method you use, the output has to name the barrier that was supposed to hold.
5. Formulate actions with a finish criterion. "Toolbox given" is attendance. "The work instruction now contains the isolation step and three crews have been observed applying it" is a finish criterion.
6. Only then write the summary. The summary is the last thing you write and the only thing most people read.

Where incidentenrapporten quietly fail

Four patterns, all of them boring, all of them expensive:

The cause is a person. "Human error" ends the investigation exactly where it should start. The question is which condition made that action the reasonable one at that moment.

The action is training. Training is a real measure, sometimes the right one, but it is also the default when nobody wants to touch the design or the planning.

The report is complete and the change is not. The incidentenrapport gets closed while the procedure, the safety study, the labels and the drawing still say the old thing. This is where incident handling and management of change have to meet, and where they usually do not. The installation runs again, but the barrier is not demonstrably restored.

The report lives somewhere nobody searches. An Excel file, an email thread, a SharePoint folder named after a colleague who left. If an answer takes twenty minutes to find, the organisation behaves as if it does not exist.

The Check is the part that gets skipped

Plan and Do are the easy halves. Most organisations register incidents properly and assign actions properly. The loop breaks after that: nobody goes back to establish whether the measure actually changed anything in the field.

That is why recurrence is such a common finding, and why inspections increasingly look past the single event at whether your management system notices its own patterns. If the same type of incident appears three times in two years with three closed reports behind it, the reports were not wrong. The checking was missing.

So one practical test: pick three closed incidentenrapporten from last year at random. Can you show, from the record and without asking anyone, what changed and whether it held? If not, you have a checking problem, not a reporting problem. For companies with a formal veiligheidsbeheerssysteem this is also where generic tooling starts to show its limits, which is a longer story we told in why generic safety management software falls short for Seveso III companies.

Start with your own archive

A template will not fix an incident process, and software does not take the judgement off your hands. What helps is deciding, once, what an incidentenrapport in your organisation is allowed to leave open, and who checks later that the measure worked.

We build inspection, forms and corrective action tracking for EHS and compliance teams, so this is the terrain we spend our days in. If you want to think out loud about your own incident flow, send me a message and we will look at it together.

What does a closed incidentenrapport mean in your organisation: the event is described, or the barrier is demonstrably back?