When the Factory Floor Meets the Boardroom

I opened my talk at Cybersec Europe with two scenes. No slides full of statistics, no threat-actor taxonomy. Just two rooms.

Scene one. It's 3 a.m. A Belgian hospital is offline. Surgery schedules, lab results, infusion pumps — all dark. There is no ransom note. The backups are gone too.

Scene two. It's Saturday morning. A factory in the Netherlands is running smoothly. The line is moving, the chillers are humming, the HMIs all say "all green." But the PLC code was changed last night, and the safety system cannot see it.

Two very different rooms.

One thing in common: Nobody in that room is from IT.

That's the whole talk in one line, and it's why I keep giving it.

The uncomfortable truth

The systems running our production lines, our energy grids and our critical infrastructure were designed when cybersecurity meant locking the server-room door.

That isn't a criticism of the engineers who built them. They optimized brilliantly for what they were asked to optimize for: reliability and longevity. A control system commissioned in 2003 and still running today is an engineering success story, not a failure. It was simply never meant to exist in a world of nation-state actors, ransomware-as-a-service and internet-connected sensors that someone added in 2019 because the vendor's dashboard needed them.

The threat landscape changed. The technology did not.

One world, two languages

Here's what makes this harder than it looks. IT and OT teams frequently share parts of the same network, and they operate by fundamentally different rules.

The differences between IT and OT

• Priority: In IT this is Confidentiality, it is key to protect the data Availability and safety — while in OT uptime is non-negotiable
• Patching: In IT this is Patch Tuesday, regular and automated - while in OT, it is often best effort, if ever, under strict change control
• Asset lifespan: in IT is about 3–5 years while in OT it is around 20–30 years or more
• Standard fix: in IT is often "Have you done a reboot" - while in OT when you do a reboot this could mean a lost batch or possible safety event
• Vocabulary: in IT its about CVE, CVSS, GRC - in OT it is about Uptime, HAZOP, SIL

Neither IT or OT is wrong. Both are rational responses to different consequences of failure. In IT, the worst case is usually a data breach. In OT, the worst case is a person in an ambulance…. or worse.

The problem starts when one culture's playbook gets applied to the other. That doesn't reduce risk. It migrates it — usually into places nobody is monitoring.

Why good IT security fails in OT

This is the part where the plant engineers in the audience start nodding, and the IT people go quiet. Four things I've watched go wrong, all of them done by competent people with good intentions:

• A vulnerability scan on a production PLC. The controller crashes. The line stops. A standard network probe generates traffic volumes that fragile OT protocols were never designed to tolerate.
• A patch push to an HMI. It reboots mid-batch. Product lost. The automated deployment had no idea about the operational state of the machine it was "protecting."
• An endpoint agent on a control workstation. CPU latency climbs, SCADA times out. The agent is consuming cycles that a real-time control system cannot spare.
• An MFA prompt on a control-room console. The operator can't acknowledge an alarm in time. A two-second login delay just became a safety incident on a fast-moving process line.

Same tool. Right intention. Wrong context.

Every one of those is a control that would earn full marks in an IT audit. That's exactly what makes them dangerous: they pass the audit and create an incident.

The board's blind spot

Ask most boards about cyber risk and they'll probably (hopefully) speak fluently these days. Data. Email compromise. GDPR. Ransomware. They've been briefed, they've read the headlines, they know the vocabulary.

Now ask the same board about their PLCs. Their SCADA environment. The building management system.

Silence.

It isn't negligence. It's an artifact of how the agenda was built. Board cyber discussions were shaped by a decade of privacy & security regulation as well as data-breach headlines, so the agenda lists regulatory fines, data breaches and ransomware — and usually not a single line about the operational systems that keep the business alive.

The result is a strange asymmetry. The organization has extensive governance over the systems that store information about the business, and comparatively little over the systems that are the business.

NIS2 has quietly ended that arrangement

For the first time, European law explicitly names operational technology as a regulated surface and puts accountability on executive leadership rather than in the IT department.

Three things matter here:

• Personal liability. Leadership can be held personally accountable for cybersecurity failures, including OT incidents that cause operational disruption. Not the CISO. Leadership.
• OT explicitly in scope. Manufacturing, energy, water, healthcare and transport are named sectors. Control systems are no longer the exempt corner of the estate.
• Incident reporting triggered by operational outage. Not just by a data breach. A production shutdown qualifies.

Read those together, and the conclusion is unavoidable: this is no longer IT compliance. It is directors' fiduciary duty of care.

That re-framing does more work than any technical control I could recommend. "The SOC needs budget" is a line item to be negotiated. "The board is personally accountable for something it cannot currently see" is a governance problem, and governance problems get solved.

Where availability cannot be compromised

One slide in the talk usually changes the temperature in the room. It's just four columns:

• Hospital — patients on monitors. Downtime measured in lives, not euros.
• Manufacturing — lost batches, contamination risk, safety system failures.
• Energy grid — cascading failures across regions. Millions without power.
• Water — a public health emergency, potentially within hours.

The cost of attacks in OT includes lives. Not just euros. Once that's said out loud, the conversation about whether OT monitoring is affordable tends to resolve itself fairly quickly.

The resilience roadmap: five pillars, in order

This is the part people ask for afterwards, so here it is in full. Five pillars — and the order matters more than the list. Each one is only possible because the one before it exists. Done along with OT culture rather than against it.

1. Visibility - Asset inventory - device, firmware, protocol Can you list every PLC on your network, by name, today?
2. Network security - Zones, conduits, remote access — is it defensible? Could malware cross the border between them?
3. Detection - Passive monitoring, OT-specific - Would you know if a PLC's logic was changed last night? Would you spot something injected into the protocol stream?
4. Response - IR plans built with plant operations in the room - When did your CFO last sit a tabletop with your plant director?
5. Governance - OT risk in the enterprise risk register - Is OT a line item on the board dashboard, or a footnote?

Pillars are easy to agree with and easy to claim. The tests are hard to fake. If you can't answer one of them with a name, a date or a document, that's your next project — regardless of what the roadmap says.

And note where governance sits. Last, not first. Governance without visibility is paperwork. You cannot govern an estate you cannot enumerate.

Five questions every board should be able to answer

At this point in the talk, I say: photograph this slide. Roughly half the room does. So, take these into your next board or audit committee meeting:

1. Critical system inventory — Do we know which OT systems would halt production or harm people if compromised?
2. End-to-end recovery testing — Have we tested recovery of those systems, end to end, not just on paper?
3. Enterprise risk ownership — Is OT risk in our enterprise risk register, owned at C-level?
4. Operational IR plans — Does our incident-response plan include plant and operations leadership, not only IT?
5. NIS2 operational readiness — Are we NIS2-ready operationally, or only on paper?

Five questions, none of them technical, none requiring the board to understand a single protocol. What they require is a specific answer. "We're working on it" is a finding, not an answer.

The new contract

If any of this is going to change, three roles have to accept something uncomfortable.

CISOs: walk the factory floor. Earn the trust of the people who run it. They will not learn your language — you must learn theirs. Turning up with a CVSS score and a remediation deadline is how you get politely ignored for two years.

Plant managers: cybersecurity is not IT's problem. It is production continuity. It is safety. It belongs to you the same way physical safety already does.

Business and board: OT risk is enterprise risk. It has stopped being an IT footnote, whether or not the agenda has caught up. The landscape changed. The mindset has to change too.

The same system

I closed with the line the talk was named for, and I'll close with it here.

The factory floor and the boardroom are not separate systems. They are the same system. One of them makes the decisions; the other lives with them. Resilience begins when they finally speak the same language — when operational risk becomes enterprise risk, and every leader owns the outcome.

So, a question, and I'd genuinely like to hear the answers:

When did your board last discuss a control system by name?

Not "OT security" as a category. An actual system, with an actual owner, and an actual recovery time. If you're struggling to remember, you already know which of the five pillars to start with.