The Basics of EHS Incident Management on Seveso Sites

At a Seveso-classified site, "incident management" covers two very different kinds of events, and treating them the same way is a common source of compliance gaps. A forklift bumping a rack is a workplace incident. A pressure relief valve lifting on a process vessel - even if nothing escaped and no one was hurt - is a near-miss with major-accident potential, and it triggers a different track entirely.

This distinction, and the process that follows from it, is what Seveso III Annex III means by monitoring performance and incident investigation. It's not a reporting form. It's an end-to-end process: classify, investigate, find the root cause, fix the system, close the loop, and prove you did it.

Classification: routine incident or major-accident-relevant event

The first decision in the process is also the one most sites get wrong under time pressure: what track does this event go on.

A routine workplace incident - a slip, a minor cut, a near-collision between a forklift and a pedestrian - follows your standard HSE incident process. It matters, it gets investigated, but it doesn't touch your major-hazard risk assessment.

A major-accident-relevant incident or near-miss is different. It's any event, or narrowly-avoided event, that involved (or could have involved) loss of containment of a dangerous substance, failure of a safety-critical system or barrier identified in your safety report, or a deviation from a scenario covered in your risk assessment. The site didn't need to explode for this to count. A relief valve lifting, an interlock that didn't trip on the first signal, a gas detector that alarmed and was overridden, a procedure that was skipped and happened not to matter this time - these are all major-accident-relevant near-misses, and Seveso III explicitly expects them to feed into the same investigation and monitoring-performance process as an actual loss of containment.

Getting this classification right at the point of reporting matters because it determines the depth of investigation and who needs to be involved. Misclassifying a barrier failure as a routine incident is how near-misses stop reaching the people who own the VBS.

Investigation: root cause, not just what happened

A description of what happened is not an investigation. "Operator opened the wrong valve" is an observation, not a root cause - it tells you what, not why the system allowed it.

For major-accident-relevant incidents, the investigation needs to go past the immediate act and into the conditions that made it possible:

Immediate cause - the direct trigger (wrong valve opened, alarm not acknowledged, barrier bypassed).
Underlying causes - the conditions that made the immediate cause likely: unclear labeling, an alarm that fires too often to be trusted, a procedure that's out of step with how the task is actually done, inadequate handover between shifts.
Root/systemic causes - the management system gaps behind the underlying causes: a training program that doesn't cover this scenario, a change that was made to the process without updating the procedure, a barrier that was known to be degraded and not flagged for repair.

A method like the "5 Whys" or a formal bowtie review against the barriers in your safety report works for this. What matters less is which method you pick and more that the investigation is documented at all three levels, with evidence - not just a narrative written from memory two weeks later. Interview notes, control system data, maintenance records, and photos of the physical evidence belong in the file, not just the conclusion.

Investigation depth should scale with potential consequence, not actual consequence. A near-miss that could have caused a major accident deserves the same investigation rigor as one that did - this is precisely the "near-miss" element regulators look for when they ask how monitoring performance actually works at your site, not just whether you log incidents.

Corrective action: closing the loop into the VBS

An investigation that ends with a root cause and no system change is a paperwork exercise. The point of finding the root cause is to change something in the VBS so the same failure mode can't produce the same result again.

That means every major-accident-relevant investigation should end with an explicit answer to: what changes as a result of this, and where does it get recorded. In practice, that's usually one or more of:

Procedure updates - the operating or maintenance procedure that failed to prevent the event gets revised, not just re-issued.
Risk assessment revisions - if the investigation reveals a barrier is less reliable than assumed, or a scenario wasn't covered at all, the risk assessment and possibly the safety report need updating to reflect reality.
Training updates - if the root cause traces to a knowledge or competency gap, the training program needs a corresponding change, not a one-off toolbox talk.
Barrier or equipment changes - if a technical safeguard failed or degraded, the corrective action includes the engineering fix, its target date, and verification that it was actually done.

Each corrective action needs an owner and a deadline, and - this is the part that gets skipped under workload - a verification step confirming the action was completed and actually closed the gap, not just marked done in a tracker. An action item sitting open for eight months with no owner following up is functionally the same as never having investigated at all.

Documentation: the evidence trail is the compliance

Regulators and auditors don't observe your investigation happening. They see the file afterward. Under Seveso III, the ability to demonstrate that your monitoring-performance and incident-investigation process is real and functioning depends entirely on what's in that file - which means the documentation isn't a byproduct of the process, it's how the process gets verified.

A defensible incident file for a major-accident-relevant event should let an inspector reconstruct, months later, exactly what was found and what was done about it:

The initial classification decision and who made it.
Evidence gathered during investigation - not just conclusions.
The root cause analysis, at all three levels (immediate, underlying, systemic).
Every corrective action, its owner, deadline, and closure evidence.
The specific VBS documents that were updated as a result - procedure version numbers, risk assessment revision dates, training records - with a traceable link back to this incident.

That last point is where a lot of sites fall short. It's common to find a procedure that was updated "around the same time" as an incident, with no documented link between the two. An auditor reasonably reads that as coincidence, not corrective action, unless the file states it explicitly. If your VBS update doesn't reference the incident that triggered it, you haven't demonstrated a closed loop - you've just made two separate changes that happen to be related.

Where this fits with your broader safety process

Incident management, as described here, is the process that runs once an event has already happened or nearly happened: classify it, investigate it to root cause, fix the underlying system, and document the trail. It's deliberately narrower than your ongoing safety performance monitoring (tracking leading and lagging indicators over time) and narrower than the mechanics of getting an incident reported in the first place. Both of those are important, related pieces of the same VBS - but they're a different problem from what to do once an incident lands on your desk, which is what this process governs.

Sites that treat incident management as a closed loop - classification through to a documented, traceable VBS update - are the ones that hold up under a Seveso inspection. Sites that treat it as a reporting form are the ones that get asked, during an audit, to explain why the same failure happened twice.