PDCA and the VBS: Your Safety System Is Already a PDCA Cycle

If you manage safety at a Seveso or BRZO-classified site, you've built a veiligheidsbeheersysteem (VBS) - the safety management system required under the EU Seveso III Directive, structured around the seven elements of Annex III. What often gets missed is that this structure isn't just a compliance checklist. It's a Plan-Do-Check-Act (PDCA) cycle, and understanding it that way changes how you run it.

PDCA is a familiar model from quality and operational management: plan a change, execute it, check whether it worked, act on what you learned. Seveso regulators built the same logic into the VBS requirement, but split across seven named elements instead of four generic phases. Most EHS teams handle the two structures separately - one for the auditor, one for how work actually gets done. That's more overhead than the regulation asks for. The two are the same loop, described at different levels of detail.

Plan: MAPP, Risk Assessment, and Procedures

In PDCA, "Plan" means defining the problem, setting objectives, and deciding how you'll achieve them. In a VBS, this is where three Annex III elements sit together:

• The MAPP (major accident prevention policy) sets the top-level objectives and commitments - what the organization is trying to prevent and the principles it will follow to do it.
• Hazard and risk identification and assessment turns those objectives into specifics: which major-accident scenarios apply to your installations, what the consequences could be, and where the exposure is highest.
• Organization and personnel, plus operational control procedures, translate the assessment into concrete rules - who is responsible for what, and which procedures govern normal operation, maintenance, and change.

This is the planning layer of your VBS, and it's also the layer most likely to go stale. A MAPP or risk assessment written once and left untouched for years stops functioning as a plan and becomes an archive document. If your Check and Act stages aren't feeding new information back into this layer, the Plan stage isn't really part of a cycle - it's a starting point that never gets revisited.

Do: Operational Control in Practice

"Do" is where the plan meets the plant floor. In VBS terms, this is operational control being executed day to day: inspections carried out on schedule, permits-to-work issued and followed, maintenance done to spec, contractors briefed, procedures actually used rather than filed away.

This is also the stage where the gap between documented procedure and actual practice tends to open up. A procedure can be technically compliant and still not reflect what happens on a night shift with reduced staffing, or during a non-routine task that wasn't fully anticipated in the risk assessment. The point of the Do stage isn't just execution - it's execution that generates evidence of how the plan holds up under real conditions. Without that evidence, there's nothing for the Check stage to work with.

Check: Performance Monitoring and Audit

"Check" is where PDCA earns its reputation as a genuine improvement loop rather than a compliance ritual. In the VBS, this maps to performance monitoring (prestatiebewaking) and internal audit - two related but distinct activities.

Performance monitoring is ongoing: tracking leading and lagging indicators, near-miss reporting, deviations from procedure, inspection findings, and whether corrective actions from previous cycles actually closed out. Audit is periodic and more structured: a systematic check of whether the VBS as designed is the VBS as implemented, typically covering all seven Annex III elements on a defined interval.

The distinction matters operationally. Performance monitoring should surface problems continuously, not just at audit time. If the only place deviations get identified is during the scheduled audit, the Check stage is running too slowly to support a real PDCA loop - issues sit unaddressed for months between checks instead of being caught close to when they occur.

Act: Management of Change and Management Review

"Act" is the stage that's easiest to skip and most costly to skip. In PDCA, it means taking what Check revealed and using it to adjust the plan - not just fixing the immediate finding, but asking whether the underlying procedure, risk assessment, or policy needs to change.

The VBS has two elements built for exactly this:

• Management of change governs how modifications - to equipment, procedures, organization, or process conditions - get assessed for major-accident risk before they're implemented. It's the mechanism that keeps the Plan stage from drifting out of sync with how the site actually operates.
• Management review is where senior management periodically evaluates whether the VBS as a whole is still adequate - not just whether individual findings were closed, but whether the MAPP's objectives are still being met and whether the system needs structural adjustment.

This is the step that closes the loop back to Plan. A finding from an audit that results in a corrective action, but never triggers a look at whether the risk assessment or MAPP itself needs updating, is Check without Act. The cycle stops halfway.

Why the Mapping Matters

None of this changes what's legally required in a VBS - the seven Annex III elements stay the same regardless of how you think about them. What changes is how you build and run the system.

Treating the VBS as seven separate compliance boxes tends to produce seven separate documents, seven separate owners, and seven separate audit checklists that don't talk to each other. Treating it as a PDCA loop - Plan (MAPP, risk assessment, procedures), Do (operational control), Check (monitoring and audit), Act (management of change and review) - makes the dependencies visible. A risk assessment that never gets updated after an audit finding isn't a documentation gap; it's a broken link in the loop between Check and Act. An operational control procedure that isn't grounded in the current risk assessment isn't a training issue; it's a broken link between Plan and Do.

The seven elements were never meant to be static. Annex III describes a system that's supposed to keep moving. PDCA is just the name for what "keeps moving" looks like in practice - and it's worth designing your VBS so the connections between elements are as deliberate as the elements themselves.