Seeing more is useful. Knowing what to do with what you’re seeing is where it starts to make a difference.

I see this regularly when organisations start sending OT security data into their Security Operations Centre (SOC).

On paper, it makes perfect sense.

More visibility. More monitoring. More alerts. Better coverage of the OT environment.

All good things.

But then an analyst receives an alert from an industrial system and is faced with a fairly basic question.

What does this actually mean?

Is it normal activity?

Does engineering need to know?

Could it affect production?

And if we decide to take action, could that action create a bigger problem than the one we’re trying to solve?

The analyst can see the alert. The monitoring platform has done its job.

But without understanding the operational context, deciding what to do next can be difficult.

And that’s where I think many organisations still have work to do.

We’ve become much better at seeing what’s happening in OT environments.

The next challenge is understanding what we’re seeing and knowing what to do about it.

Visibility is useful. But what happens next?

Let’s be clear. I’m not arguing against OT asset discovery or monitoring.

Quite the opposite.

Knowing what is connected to your environment, how systems communicate and what activity is taking place is an important part of understanding and managing cyber risk.

But visibility is a starting point.

Imagine you’ve invested in an OT monitoring platform and discovered thousands of assets across your sites.

You now have a much better picture of the environment.

That’s progress.

But what does the information actually tell you?

Which assets support critical processes?

Which ones could affect safety or production if they became unavailable?

Who owns them?

What does normal activity look like?

And what happens if something changes?

An asset inventory might tell you that a particular engineering workstation exists.

It doesn’t necessarily tell you that the workstation is used to maintain a critical production process, that a particular engineer is responsible for it, or that taking it offline could prevent essential maintenance from being carried out.

That information matters when you’re deciding how to respond to a potential security incident.

Visibility tells you what’s there. Operational context tells you why it matters.

You need both.

What events of interest do we actually care about?

There’s another question I think organisations should spend more time considering when implementing OT monitoring.

What events of interest (EoI) do we actually care about?

It’s easy to enable a range of detections and start sending alerts to the SOC.

But not every event should be treated in the same way.

Take something as simple as a server reboot.

A server rebooting at 2am might deserve attention if nobody was expecting it.

But what if 2am is the agreed maintenance window and the reboot was part of an approved change?

Equally, a reboot at 2pm might appear perfectly normal until you discover that the server supports a critical process and wasn’t supposed to be restarted.

The time of the event provides useful context.

It doesn’t, by itself, tell us whether the activity is legitimate or suspicious.

The same applies to a controller programme download.

Was it carried out as part of an approved change?

Was the person performing it authorised?

Was the correct engineering workstation being used?

Was the process in an appropriate state?

And what could happen if an unauthorised change had been made?

A controller download during working hours isn’t automatically legitimate, just as one outside working hours isn’t automatically malicious.

What matters is whether the activity was expected, authorised and appropriate for the operation.

That’s where I think the conversation around monitoring needs to change.

Rather than simply asking what events the technology can detect, we should be asking what events matter to the operation and what we expect somebody to do when they occur.

Engineering and operations understand how the process works, when changes normally take place and which activities could have significant operational consequences.

Cybersecurity understands the events and behaviours that might indicate suspicious or unauthorised activity.

Together, they need to agree what should be monitored, what context is required and when something warrants investigation or escalation.

A controller programme download to a critical system might always be worth recording, with unexpected or unauthorised downloads requiring further investigation.

A server reboot might be routine in one part of the environment but significant in another.

We also need to be careful not to create blanket exceptions. An approved maintenance window shouldn’t mean that everything happening during that period is automatically considered safe.

The monitoring technology can tell us that something happened.

It’s the operational understanding that helps us decide whether it matters.

When an OT alert reaches the SOC

Let’s go back to the SOC.

An analyst receives an alert indicating unusual communication involving an engineering workstation.

Perhaps an engineer is carrying out planned maintenance.

Perhaps a vendor has connected remotely to investigate a problem.

Perhaps somebody has made a change outside the agreed maintenance window.

Or perhaps the activity is genuinely suspicious.

The alert alone might not give the analyst enough information to distinguish between those possibilities.

So, quite reasonably, the analyst escalates it to engineering.

But then progress slows.

Sometimes the response takes longer than expected. Sometimes the information coming back doesn’t provide the clarity the analyst needs to decide what happens next.

I’ve seen this in environments where escalation arrangements are structured and in others where the process is far more informal.

It can even vary between sites within the same organisation.

And having a formal process doesn’t necessarily solve everything.

Having somebody to contact doesn’t mean they have the knowledge needed to answer the question.

The analyst may understand the cybersecurity implications but not the operational context.

The engineer may understand the process but have limited experience of investigating cybersecurity alerts.

And the person who understands both might not be available when they’re needed.

I don’t think that’s necessarily a failure of either team.

It’s a capability gap that needs to be recognised and addressed.

Engineering has a plant to run. The SOC has an alert to investigate.

Unless the organisation has agreed how those two functions work together, it’s easy for an alert to end up sitting between them.

Escalation isn’t the same as response.

The SOC needs more than an escalation contact

I don’t think the answer is to expect every SOC analyst to become an industrial control systems engineer, or every engineer to become a cybersecurity specialist.

That’s not realistic.

But we do need to make sure the right knowledge is available when decisions need to be made.

That means establishing clear escalation arrangements and identifying people who understand the critical systems.

It means agreeing what information engineering needs from the SOC, what information the analyst needs back and how quickly somebody needs to respond.

It means making sure the person being contacted has the knowledge and authority to help.

And it means having arrangements for when that person isn’t available.

There’s also a practical skills issue here.

Organisations can spend a lot of time discussing the shortage of specialist OT cybersecurity knowledge.

But I think we should also be asking how we can make better use of the knowledge we already have.

Get SOC analysts talking to engineers.

Help analysts understand the operational context of the most critical systems.

Help engineers understand what common cybersecurity alerts mean and what information the SOC needs to investigate them.

Review real events together.

Discuss what normal activity looks like.

Agree which events require immediate escalation and which can be investigated through the normal process.

Where the necessary expertise doesn’t exist internally, organisations may need additional specialist support.

The objective isn’t to turn everybody into an expert in everything.

It’s to make sure the right people can work together when something needs a decision.

Don’t wait for an incident to find out whether it works

This is where I think organisations can make some fairly practical improvements without necessarily buying anything new.

Get the SOC, cybersecurity, engineering and operations teams around a table.

Take a handful of events from your existing monitoring platform.

A server reboot.

A controller programme download.

An unexpected remote-access session.

A configuration change to a critical system.

Then work through them.

Is this something we actually care about?

What would make it suspicious?

What information would help us determine whether it was expected?

Who would the SOC contact?

Who would decide whether action was needed?

And what would happen if the usual engineering contact wasn’t available?

You might discover that some detections need refining.

Others might need additional operational information.

Some may be generating unnecessary noise.

And some might identify activity that deserves more attention than it’s currently receiving.

That’s useful progress.

Then take it a step further.

Run a realistic scenario and see whether the agreed escalation process actually works.

Not just whether the monitoring platform detects something, but whether the right people can understand what has happened, make an informed decision and take appropriate action.

And don’t assume that isolating a system is always the correct response.

In OT, containment decisions need to consider the potential impact on the process, safety and continuity of operations.

If the answer to any of those questions is “We’re not sure”, you’ve found something worth improving.

Better to discover that during an exercise than when the real thing happens.

More alerts don’t necessarily mean better defence

One of the things I’d be careful about is measuring the success of OT monitoring purely by the number of assets discovered or alerts generated.

Those numbers have their place.

But they don’t necessarily tell you whether the organisation is better prepared to deal with a cyber incident.

If the SOC receives hundreds of alerts but cannot determine which ones matter, the monitoring programme still has work to do.

Equally, reducing the number of alerts isn’t automatically an improvement if important activity is being missed.

The objective isn’t simply to generate fewer alerts.

It’s to generate meaningful alerts that can be investigated and acted upon appropriately.

That requires good detection logic, operational context, clear responsibilities and the ability to involve engineering and operations when needed.

It also requires feedback.

If engineering confirms that an alert was caused by legitimate maintenance, does that information make its way back to the SOC?

Can the detection be refined?

Can the analyst be given better context next time?

And if an alert identifies a genuine problem, do we capture what was learnt and improve the response process?

That’s how monitoring becomes more useful over time.

Not simply by generating more information, but by improving what we understand and what we do with it.

Final thought

We’ve made progress in OT visibility and monitoring.

That’s something worth recognising.

But the next step isn’t necessarily another dashboard or another source of alerts.

It’s making better use of what we can already see.

Understand what matters.

Agree which events of interest you actually care about.

Give the SOC the operational context it needs.

Make sure engineering and operations are part of the response process.

Agree who makes the decisions.

And practise what happens when an alert turns out to be something that genuinely needs action.

Because seeing more is useful.

Knowing what to do next is where it starts to make a difference.

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.