When it comes to cybersecurity, we usually look for technical vulnerabilities.

Missing patches. Weak configurations. Exposed services. CVEs.

But in OT, sometimes the real vulnerability is much simpler:

Nobody is fully sure who owns the system.

  • Who owns the hardware?

  • Who patches the OS?

  • Who manages the application?

  • Who follows the vendor?

  • Who takes the backup?

  • And if something actually goes wrong, who owns the recovery?

Having different teams involved is not the problem. That is quite normal in industrial environments.

The problem starts when everyone owns a small part, but nobody really owns the full outcome.

And sometimes it goes even further.

A task is assigned. An email is sent. The issue is escalated.

Everyone can prove that they did their part.

But the actual problem is still there.

In OT, ownership should not mean only completing your own step.

Someone still has to follow the issue until the system is safe, available and understood.

Otherwise, responsibility becomes fragmented while the risk stays whole.

Then things start falling into the gaps.

A patch waits because nobody wants to take the risk.

A backup exists, but nobody knows if the restore really works.

A system gets old, but replacement is somehow always another team’s problem.

A vendor sends a security advisory, but it is not clear who should act on it.

And during an incident, sometimes the first problem is not even the technical one.

It is:

Who is supposed to decide?

Another warning sign is when the same few people always close these gaps.

They know who to call, what to check and how to push the issue forward.

That may keep operations running, but it can also hide the real problem.

If the system only works because certain people constantly take extra ownership, then the ownership model itself is weak.

This is why I think ownership in OT is not just an organisational topic.

It directly affects patching, recovery, lifecycle management and incident response.

In an office, unclear ownership can create delays.

In an industrial environment, it can create real operational risk.

The solution does not have to be complicated.

For every critical OT system, responsibilities should be clear before something goes wrong.

  • Who owns the hardware?

  • Who owns the OS and application?

  • Who manages the vendor?

  • Who approves patching and downtime?

  • Who owns backup and recovery?

And most importantly:

Who follows and tests at the final step the issue until the outcome is actually achieved?

Different people can own different parts.

But accountability cannot disappear between them.

For every critical OT asset, we should be able to answer one simple question:

If this system becomes vulnerable, unavailable or compromised tomorrow, who owns the outcome?

If the answer is not clear, I would already consider that a security gap.