The Cloud: The Risk Many Companies Are Recognizing Too Late

Our industry grinds to a halt if the cloud goes down.

Logistics, manufacturing… within hours, or at most days, completely paralyzed.

And the ability to still manage operations? That disappears just as quickly.

This isn’t doomsday thinking.

This is one of the key findings of a report by RVO, conducted by Energy Innovation NL.

We have outsourced something fundamental without calling it that.

Industrial companies are digitizing at a rapid pace. Completely understandable. Competition demands it. Efficiency beckons.

But in the meantime, the core of operations is shifting unnoticed toward the cloud. Not just in our own systems, but especially in the surrounding ecosystem: monitoring, reporting, supplier platforms.

And that is where the real risk lies.

Because that ecosystem rarely operates in a single location.

It relies heavily on a handful of providers: Microsoft Azure, Amazon Web Services, and Google Cloud.

Often supplemented by intermediaries such as Cloudflare.

Dependency on the same infrastructure of up to 70% to 80% is no longer an IT choice.

That is concentration risk.

And no, “hyperscale” does not mean “untouchable.”

In recent years, all major cloud providers have experienced outages lasting hours. Entire services were inaccessible. Customers were simply unable to do anything. Add to that the current geopolitical reality—in which digital infrastructure is also a tool of power—and the playing field changes fundamentally.

Then the question is no longer whether things will go wrong.

But how hard it will hit once they do.

Because if your production, logistics, and decision-making depend on systems over which you have no direct control… then you’re renting continuity.

And renting remains a form of dependency.

In this blog, I’ll show you where the real risks lie, what questions you need to ask yourself right now, and more importantly: how to prevent your operations from grinding to a halt.

Where the real problem lies

Not every production line just stops.

It keeps running as long as it can.

The problem arises the moment you have to intervene.

Suppose: you’re bottling cola. Everything’s running smoothly. No problem.

Until you have to switch to orange soda.

Then the line has to be reconfigured.

And increasingly, that’s done via the cloud.

Is the cloud unavailable?

Then your line comes to a standstill.

And that costs money.

It gets even worse if your monitoring is also in the cloud.

Because then you don’t even know when you need to intervene.

The line keeps producing cola.

For too long.

Too much.

Inventories pile up.

Shelf life is at risk.

You reach the point where your revenue turns into waste.

And we’re still talking about a relatively simple process.

As soon as your process control itself becomes dependent on the cloud, the risk increases exponentially.

Think of a brewing kettle.

The temperature needs to go up.

That signal comes via the cloud.

If that signal doesn’t come?

Then things go wrong.

Not just a little. But immediately.

100,000 liters of beer per kettle could be lost.

In a single mistake. In a single disruption.

Replace beer with chemicals, steel, or paper…

and you have the same problem, with equally severe consequences.

These are not exceptions.

These are logical outcomes of the design of our systems, in which critical steps have become dependent on external systems.

And that is exactly where the problem lies.

You are dependent on suppliers who time and again demonstrate that they can be unavailable for hours on end.

Not because they are bad.

But because every complex system fails.

And when they fail, then… your operation fails along with them.

And that is the real problem and risk.

As soon as the cloud can access it, attackers can too

OT becomes even more vulnerable as soon as it needs to be controlled from the cloud.

That is the harsh reality.

Because if your cloud can access it, attackers can, in principle, try to as well.

And that is exactly where the problem lies.

Much of OT was built in a time when threats were much smaller.

Much smaller.

The underlying principles were different.

Long lifespan. Closed environments. Hardly any external connections.

Security was often an afterthought, because it simply seemed less urgent.

But we now live in a different world.

As soon as you digitize via the cloud, you usually can’t avoid connecting OT to the internet.

And then you’re connecting old, vulnerable technology to an outside world that has become far more aggressive, smarter, and ruthless.

That’s not a minor detail.

That’s a structural risk.

The more OT you make accessible via the cloud, the larger your attack surface.

The less you put there, the less you have to expose.

Sometimes the wisest digitalization choice isn’t to connect more, but to be more selective about what really needs to be online and what definitely shouldn’t.

“Just take it out of the cloud” sounds nice but isn’t that simple anymore

The most obvious solution seems simple:

take it out of the cloud.

No dependency, no risk.

Done.

Only it doesn’t work that way anymore.

More and more providers are offering their software exclusively as a cloud service.

No installation. No local version. No choice.

So you may want to get out…

but your chain is already locked in.

Then the question isn’t: do I leave the cloud?

but: where do I allow the cloud and where absolutely not?

The first benefit lies in what you don’t move to the cloud.

Keep critical process control local.

Ensure your core operations can continue to run without external dependencies.

Do you have to choose anyway?

Then look beyond functionality and price.

A supplier based in the EU with European ownership reduces your geopolitical risk.

Not perfect. But better.

But it doesn’t stop there.

Screening suppliers isn’t a quick check-the-boxes exercise.

It’s a strategic choice.

Where does their platform actually run?

Who has access?

What happens in the event of an outage?

And above all: what happens if you want to leave?

Document agreements in such a way that they can’t be quietly altered.

Not just in the terms and conditions, but contractually enforceable.

Legislation like NIS2 helps, but it’s mainly limited to security.

Not to continuity. Not to sovereignty.

And that’s exactly where the real risk lies for many organizations—and most likely for you as well.

So if you can’t avoid the cloud—and that’s often the case—

make sure you know what happens if things go wrong.

Not just on paper, but in practice.

In your own practice.

Simulate an outage.

Pull the plug.

Then you’ll immediately see what remains intact.

And what only works as long as everything goes smoothly.

The question isn’t whether you’re at risk, but where.

Downtime isn’t neutral.

Downtime costs production, margin, delivery reliability, and trust.

So the question isn’t whether you’re at risk, but where.

And whether you’ve identified that in time.

Sciante helps companies and IT managers like you identify where operational and digital vulnerabilities lie.

Not with thick reports destined for a drawer, but with practical insight into what could bring you to a standstill and how you can reduce that risk to an acceptable level.

Want to have a focused discussion about this?

Then schedule a no-obligation meeting with me.

Together, we’ll identify your biggest risks, determine what’s best kept in-house, assess what your suppliers really need to prove, and figure out how to prevent your production from grinding to a halt or completely derailing.