GRC on a Seveso Site: You Already Have the Framework

If you manage a veiligheidsbeheersysteem (VBS) at a Seveso or BRZO-classified site, you already run a GRC program. You just don't call it that.

That's a problem when you sit across the table from a CFO, a board member, or a group risk committee. They think in Governance, Risk, and Compliance because that's the language their audit committee, their insurer, and their annual report use. You think in MAPP, PBZO, risk assessments, and the seven VBS elements from Seveso III. Both descriptions cover the same ground. But if you can't translate between them, your VBS looks like a technical cost center instead of what it actually is: the most mature risk management system most of these executives will ever see in the business.

This is a practical way to make that translation - and to use it to explain, defend, and improve your VBS.

Why the translation matters

Seveso III (Directive 2012/18/EU, implemented in the Netherlands through the BRZO 2015 / Besluit risico's zware ongevallen) requires upper-tier establishments to operate a safety management system covering seven elements: organization and personnel, identification and evaluation of major hazards, operational control, management of change, planning for emergencies, monitoring performance, and audit and review. That structure is deliberately comprehensive, but it wasn't written for a boardroom conversation.

GRC was. Governance, Risk, and Compliance is the framework non-specialist executives already use to reason about any control system in the business - financial controls, IT security, data privacy. When you present your VBS through that lens, you're not simplifying it or leaving anything out. You're using a vocabulary your audience already trusts.

The mapping is direct:

• Governance - who owns the system, how decisions get made, how the safety policy (MAPP) gets set and reviewed
• Risk - how major hazards get identified, assessed, and prioritized
• Compliance - how you operate within the boundaries you've set, and how you prove it

Below is how each piece of your VBS fits.

Governance: who owns the MAPP, and how

Governance is the question "who is accountable, and how is that accountability structured?" In VBS terms, this is your organization and personnel element, anchored by the Major Accident Prevention Policy (MAPP).

A MAPP that exists only as a signed document in a policy binder isn't governance - it's paperwork. Real governance means:

• A clear line from the MAPP to the people who implement it, with defined roles and responsibilities at every level of the site
• Competence and training requirements tied to those roles, not generic safety inductions
• A review cycle for the MAPP itself, so it reflects the current risk profile rather than the one that existed when it was last signed
• Documented decision rights: who can approve a deviation, who signs off on a management-of-change request, who escalates to the board

When you present this to an executive audience, frame it exactly as you would any other governance structure in the business: ownership, accountability, and a review cadence. That's what they're used to evaluating, and it's what your MAPP structure already provides - if it's actually operating, not just filed.

Risk: hazard identification and assessment

This is the part of GRC that maps most directly onto familiar VBS territory: identification and evaluation of major hazards, and the risk assessments that sit underneath your PBZO and safety report.

The GRC framing adds one useful discipline here - a single, current register. Not a set of studies from different years sitting in different folders, but one place that shows every identified major hazard, its current risk assessment, and the status of any control or mitigation tied to it. That's the same principle a financial risk register or an IT risk register follows, and it's the piece that's easiest to explain to someone outside EHS: "here is everything that could go wrong, ranked, with an owner and a current status."

For a Seveso site, that register has to stay connected to reality on the floor. A hazard identified in a HAZOP three years ago isn't static - process changes, new substances, aging equipment, and organizational changes all shift the picture. The register is only as credible as its last update.

Compliance: operational control, audit, and proving it

Compliance is where you demonstrate that the organization operates inside the boundaries governance set and the risk assessments defined. In VBS terms, this covers three elements at once: operational control, monitoring of performance, and audit and review.

Operational control means the procedures, safe operating limits, and permit-to-work systems that keep day-to-day operations inside the envelope your risk assessments allow - plus management of change, so that envelope gets reassessed whenever something shifts. Audit and review means the internal and external checks that confirm those controls are actually functioning, not just documented.

This is also where "demonstrating adherence to Seveso III" stops being abstract. Regulators, insurers, and increasingly your own board want evidence, not assurance. That means:

• Records that tie a specific control back to a specific hazard in the risk assessment
• An audit trail showing when a control was last checked, by whom, and what was found
• A closed loop on findings - an audit that identifies a gap is only useful if there's a visible record that the gap was closed

When compliance is treated as a GRC pillar rather than a standalone inspection checklist, it stops being reactive paperwork done to satisfy an inspector and becomes the evidence layer that makes governance and risk credible to everyone who wasn't in the room when the work happened.

Putting the three together

The value of the GRC lens isn't that it changes what your VBS has to do - Seveso III already defines that. The value is that it gives you one framework to show how the seven VBS elements connect to each other, instead of presenting them as seven separate obligations:

• Governance sets the policy and the accountability (organization and personnel, MAPP)
• Risk defines what you're managing against (hazard identification, risk assessment)
• Compliance proves you're operating within it (operational control, audit and review, monitoring)

When a gap shows up in an audit, you can trace it back through this chain in a sentence an executive will actually follow: a compliance gap because a control wasn't updated, because the risk assessment behind it was stale, because the governance review cycle that should have caught that didn't run on schedule. That's a much stronger conversation than "we found a nonconformity."

A practical starting point

If your VBS documentation currently reads as seven separate elements with seven separate owners, you don't need to rebuild it. Map what already exists onto Governance, Risk, and Compliance, and look for where the connections are thin:

1. Can you point to the MAPP and name who's accountable for each part of it, today?
2. Is there one current view of your major hazards and their risk assessments, or several partial ones?
3. For your top hazards, can you trace a straight line from risk assessment to the specific operational controls that manage it, to the audit evidence that confirms those controls work?

Wherever that line breaks is where your next improvement effort belongs - and it's also exactly the gap a GRC-literate executive will ask about first.