Most cybersecurity conversations start with technology.

In OT, I think we need to start somewhere else.

Earlier this year, I opened the OT Defenders Summit in London with a keynote called The State of OT Defence: From Cyber Controls to Operational Resilience. My job was to set the scene for the day. Rather than talk about another technology or the latest cyber trend, I wanted to start with something more fundamental:

What are we actually trying to protect?

That led to four questions:

1. What stops?
2. What becomes unsafe?
3. What can’t recover quickly?
4. What does society depend on?

The point was simple.

In OT, start with consequence.

And I think that principle deserves a bit more attention than I could give it in a 30-minute keynote.

When I first sit down with an organisation to talk about OT cybersecurity, one of my first questions is usually quite simple:

“So, tell me your pain points with OT cybersecurity.”

I deliberately don’t start with the technology.

I want to understand what’s actually causing concern. What isn’t working? What keeps getting pushed down the list? What are people worried about? And where does the organisation already know it has a problem but isn’t quite sure what to do about it?

The answers vary.

It could be legacy systems that can’t easily be changed. Third-party access that’s grown organically over the years. Poor visibility. Limited maintenance windows. Vulnerabilities everyone knows about but nobody quite knows how to tackle. Or incident response and recovery arrangements that exist on paper but haven’t really been tested.

There’s usually plenty to talk about. But before getting too far into controls, tools and technology, I think there’s another question we need to ask.

What actually matters?

And that means starting with consequence.

What happens if this stops?

We are very good in cybersecurity at talking about technology.

• What assets do we have?
• What vulnerabilities exist?
• Which systems need patching?
• Who has access?
• What controls are missing?

All perfectly sensible questions.

But in an OT environment, I think another question needs to come much earlier:

What happens if this stops?

• Does production stop?
• Does a service become unavailable?
• Could people be put at risk?
• Could we lose visibility or confidence in the process?
• Could there be an environmental impact?
• How long could the operation realistically continue?

And then:

How would we recover?

Once you start asking those questions, the conversation changes.

A device isn’t important simply because of what it is or because it has a vulnerability. What matters is what it does, what depends on it and what the consequence would be if it were no longer available or trustworthy.

That’s operational context.

Without it, we risk spending a lot of time fixing the things that are easiest to measure rather than the things that matter most.

OT isn’t IT’s poor cousin

One thing I’d like our industry to stop doing is treating OT cybersecurity like IT’s poor cousin.

That’s not a criticism of IT security. There is plenty OT can and should learn from IT.

But OT has its own constraints, priorities and consequences.

We’re dealing with systems that interact with physical processes. Availability and reliability can be critical. Changes may require engineering approval, testing or a planned outage. Equipment can remain operational for years, sometimes decades. Vendor dependencies can be difficult to remove.

That changes how we need to think about cybersecurity.

The technically correct answer isn’t always the operationally safe answer.

• “Patch it.”
• “Scan it.”
• “Segment it.”
• “Switch it off.”

Perhaps.

But first:

• What does it do?
• What depends on it?
• What happens if the change goes wrong?
• Can we safely recover?

We don’t always need another six months of analysis

One of my frustrations with OT cybersecurity is analysis paralysis.

I’m not arguing against proper risk assessment, good engineering or careful planning. Of course we need those things. But there comes a point where everyone around the table already knows something isn’t right.

You know remote access needs tightening.
You know accounts are being shared.
You know the backups haven’t been properly tested.
You know the network needs better segmentation.
You know nobody is entirely sure who would make certain decisions during an incident.

Yet somehow another six months can disappear into analysing the problem.

At some point, you have to do something.

Start somewhere.
Put a sensible control in place.
Learn from it.
Refine it.
Then tackle the next thing.

OT cybersecurity can be complex. Industrial environments can certainly be complex. But I don’t think knowing where to begin always needs to be.

Sometimes the first step is simply dealing with the things you already know are wrong.

Basic controls still matter

There’s understandably plenty of discussion about new threats, AI, advanced detection and increasingly sophisticated security technology.

Those conversations have their place.

But they shouldn’t distract us from getting the basics right.

• Who can remotely access the environment?
• Are privileged accounts properly controlled?
• Do we understand the important communication pathways?
• Are backups available and have they actually been tested?
• Does everyone know who to call if something unusual happens?
• Can parts of the environment be isolated if necessary and operationally safe to do so?
• Is there an incident response plan that actually reflects the OT environment?

None of that is particularly glamorous.

It is, however, useful.

I’d rather see a handful of sensible controls working properly than an impressive architecture diagram containing controls that nobody quite trusts when they’re actually needed.

A recovery plan is full of assumptions

This is where practising really matters.

I was involved in an exercise with an organisation that had an off-site disaster recovery facility. On the face of it, they’d done the right thing. If their normal location became unavailable, they had contracted space elsewhere that could support their recovery.

There was a plan.
There was a location.
There was a contract.

Then, during the exercise, a fairly simple question came up:

What happens if we’re not the only organisation that needs it?

The recovery facility was commercially provided and shared across multiple customers.

The particular scenario we were exercising had the potential to affect other organisations too. A widespread supply-chain incident is a good example of the type of event that could create that problem.

So the questions changed.

• What happens if several customers invoke their recovery arrangements at the same time?
• Is capacity guaranteed?
• Does anybody have priority?
• What does the contract actually guarantee during a widespread event?
• And what happens if the space you planned to recover into isn’t available?

To be clear, the exercise didn’t prove that the recovery facility would fail or that capacity wouldn’t be available.

It did something much more useful.

It exposed an assumption.

The organisation had considered what would happen if it had a problem.

The exercise made us consider what would happen if everyone had a problem.

That’s the value of practising.

Having a recovery plan and being able to recover aren’t quite the same thing.

You only really start discovering the difference when you test the assumptions behind the plan.

If you do one thing: be prepared

If an organisation asked me to choose one thing it could do over the next twelve months to improve its OT cybersecurity, my answer probably wouldn’t involve buying anything.

I’d say:

Be prepared.

Get an OT incident response plan in place.

Work out who needs to be involved.
Make sure people understand their roles.
Think through the decisions that might need to be made.
Understand how cyber, engineering, operations, safety and leadership would work together.

And then practise it.

Don’t make the exercise perfect.

Give people a realistic problem.
Take something away.
Challenge an assumption.
Ask somebody to make a decision they weren’t expecting to make.

And when the answer to a question is:

“We’re not sure.”

Good.

You’ve found something useful.

Better to discover it during an exercise than during the real thing.

Start somewhere

I don’t think good OT cybersecurity is about doing everything.

Few organisations have unlimited budgets, unlimited people or unlimited maintenance windows.

It’s about understanding what matters, making sensible decisions and improving the things that genuinely reduce risk to the operation.

So start with consequence.

Understand what you’re protecting and why it matters.
Deal with the problems you already know about.
Put sensible controls in place.
Prepare for an incident.
Practise your response.
Learn from it.
Then improve again.

OT cybersecurity isn’t simple.

But we don’t need to make it more complicated than it already is.

Sometimes you just need to start.

Final thought

If you do one thing this year, get the right people around a table and practise responding to an OT cyber incident.

Don’t make the scenario perfect. Make it slightly awkward.

Challenge the assumptions your plans depend on and see what happens.

You’ll learn far more from discovering a gap during an exercise than discovering it at three o’clock in the morning during the real thing.

About the author

Serkan Yusuf is Director of Professional Services at OTIFYD, working with organisations to understand and manage cybersecurity risk across Operational Technology and industrial environments. OTIFYD helps organisations improve OT cybersecurity and operational resilience through practical, engineering-aware security services.