One of the easiest ways to slow down an OT cybersecurity improvement is to get stuck deciding who owns it.

I saw this with a food manufacturer that needed to introduce separation between its IT and OT networks.

Everyone agreed a firewall was needed. What stalled progress was ownership.

Engineering wanted authority over connectivity to its OT systems but didn’t want responsibility for administering and maintaining the firewall. IT could manage the firewall, but quite reasonably didn’t want to be accountable for OT rules it wasn’t authorised to approve.

Neither side was wrong.

The answer was to separate platform ownership from policy ownership.

IT maintained the firewall and owned the rules for common services. Engineering owned the rules governing access to OT systems, with the relevant system custodians approving changes that affected their systems.

Nobody had to own everything. They just needed to be clear about who owned each decision.

It was a pragmatic solution to a problem that had already consumed too much time.

The risk was understood. The technology wasn’t particularly complicated. What was holding things up was trying to resolve every aspect of governance before making progress.

And I think there’s a wider lesson in that.

You don’t need to know everything to improve something.

A roadmap shouldn’t become a waiting room

I’m a big believer in having a strategy.

OT environments can be complex. Changes need to be properly considered. Engineering, operations, cybersecurity and IT may all need to be involved.

But strategy and action aren’t mutually exclusive.

You can be developing a longer-term cybersecurity roadmap while making sensible tactical improvements today.

In fact, I think you should.

If you know remote access needs tightening, start there.

If you know accounts are being shared, deal with them.

If changes are happening without appropriate control, improve the process.

If nobody is quite sure who gets called during an OT cyber incident, sort that out.

If you’ve never practised your incident response plan, get the right people around a table and exercise it.

None of those things requires you to understand every asset, vulnerability and risk across the entire environment before you begin.

A roadmap should give you direction.

It shouldn’t become a waiting room.

Tactical doesn’t mean careless

There’s an important distinction here.

I’m not suggesting organisations should rush changes into industrial environments simply because somebody has identified a security weakness.

That would be missing the point entirely.

Changes in OT need to consider the operation. Availability, reliability and safety matter. Engineering constraints matter. Maintenance windows matter. And sometimes doing nothing immediately is the right decision until a change can be made safely.

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

But there’s a difference between being appropriately cautious and being unable to make a decision.

Not every improvement needs to wait for a major strategic programme.

Some improvements can be tactical.

Raise cybersecurity awareness among engineers and operators.

Introduce sensible change control where it doesn’t exist.

Review who has remote access and whether they still need it.

Clarify responsibilities between IT, cybersecurity, engineering and operations.

Get an OT incident response plan in place and practise it.

These aren’t replacements for a longer-term strategy.

They’re things you can do while building one.

You probably know more than you think

A question I hear regularly is:

• Where do we start?

Closely followed by:

• Where should we spend the money?

And:

• What are our biggest risks?

All reasonable questions.

Asset discovery, risk assessment, architecture reviews and strategic planning can help answer them. You need enough understanding of the environment and its consequences to make informed decisions.

But incomplete information doesn’t mean you know nothing.

You might not have the perfect asset inventory.

You might still be assessing every site.

You might not have agreed the target architecture.

But you may already know third-party remote access is poorly controlled.

You may know shared administrator accounts exist.

You may know the backups haven’t been properly tested.

You may know changes are happening without appropriate control.

You may know your incident response plan doesn’t properly account for the OT environment.

You don’t need to wait for the final maturity assessment to recognise that those things deserve attention.

Sometimes the first step is simply dealing with the problems you already know about.

Start with what you know

So how do you decide whether something can sensibly be tackled now?

I think a few straightforward questions help:

• Does this address a risk we already understand?
• Do we understand the operational consequence of making the change?
• Can we implement it safely?
• Is it clear who is responsible for the decision?
• If it goes wrong, can we recover or safely reverse it?

If you can answer those questions with confidence, there may be little value in waiting six months simply because the wider programme isn’t finished.

And if you can’t answer them, that’s useful too.

Maybe you need an engineer involved.

Maybe there’s a dependency you don’t understand.

Maybe the change needs testing.

Maybe there’s a genuine safety concern.

Or perhaps it really does need to wait for the strategic solution.

That’s not analysis paralysis.

That’s doing the necessary analysis to make a safe decision.

The difference matters.

Governance should help you make decisions

That brings me back to the firewall example.

Good governance matters.

But it should answer practical questions.

• Who understands the operational consequence?
• Who has the authority to approve the change?
• Who implements it?
• Who maintains the control?
• And who needs to know when something changes?

Those responsibilities don’t necessarily have to sit with the same team.

The people maintaining a security control don’t automatically have to own every operational decision associated with it.

Likewise, engineering shouldn’t have to become the firewall administration team simply because it has authority over connectivity to its systems.

What matters is that responsibilities are understood and decisions are made by the right people.

Governance should enable good decisions, not become the reason they don’t get made.

Not every improvement needs a purchase order

When organisations ask where to start with OT cybersecurity, the conversation can quickly turn to technology.

• What should we buy?
• Do we need better monitoring?
• Do we need another platform?

Sometimes the answer will involve technology.

But not every meaningful improvement requires a purchase order.

Better change control doesn’t require another security platform.

Clarifying incident roles doesn’t require another appliance.

Running a tabletop exercise can expose assumptions and gaps before you’ve bought anything.

Helping engineering and operations recognise unusual or unexpected activity is hardly cutting-edge technology.

But all of those things can improve how an organisation manages cyber risk.

I’m certainly not arguing against investment.

I’m arguing for understanding the problem before assuming buying something is the answer.

Another dashboard rarely fixed the plant.

Progress, not shortcuts

Some OT cybersecurity problems genuinely require significant engineering, investment and time to solve properly.

But that doesn’t mean every improvement has to wait until you have a perfect understanding of everything.

There’s a balance.

Move too quickly without understanding the operation and you can create new problems.

Spend too long trying to eliminate every uncertainty and known problems remain untouched.

Neither is particularly useful.

The aim is informed action.

Understand enough to make a safe decision.

Prioritise something that matters.

Make the improvement.

Check that it worked.

Learn from it.

Then improve again.

That isn’t a shortcut around strategy.

It’s how you make progress while building one.

Final thought

There will always be another vulnerability, audit finding, customer requirement or incident demanding attention.

If we spend all our time reacting to them, it’s very difficult to get ahead.

So make some space to ask:

• What do we already know needs improving?

Then do something sensible about it.

You don’t need perfect visibility before improving anything.

You don’t need every governance question answered before people can collaborate.

And you don’t need to finish a three-year roadmap before reducing a risk you already understand.

Be careful. Understand the consequence. Involve the right people.

But when you know something needs improving, and you can improve it safely, make a start.

You don’t need to know everything to improve something.

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.