Date: 10/6/2026

Cybersecurity

Your resilience may depend on a supplier you do not control

A cyber incident does not have to enter your network to stop your operation. Six kinds of supplier dependency, and the thirteen points that make the decision.

TL;DR

A cyber incident does not have to enter your network to stop your operation. If the supplier of your control system is down, their engineer cannot dial in, your licence server gets no answer, and nobody knows how the installation fits together. Your firewall works, your backups are fine, and your production is still down. This article makes that dependency concrete, per supplier.

Most continuity plans deal with what goes wrong in your own environment: a server failing, ransomware, a data centre without power. That is useful, and it is not where things have gone wrong most often in recent years.

Increasingly, an organisation stops because something happened somewhere else. At a software vendor, a logistics partner, a cloud service, a maintenance company. Nobody enters your network. Nothing at your end has to be infected. And the line still stops.

That is not a network question. It is a continuity question, and it belongs with someone who can decide.

Six kinds of dependency, and they need different measures

“Supplier risk” is one phrase for very different things. It pays to separate them, because the measure differs per kind.

Remote support. A fault you cannot fix yourself, and the engineer who can is at a company that is temporarily not there.
Licence server. Software that validates periodically and stops when no answer comes. This is the quietest of the six: everything works, until suddenly it does not.
Spare parts. One supplier, lead time in weeks, and a part you do not buy elsewhere.
Data feed. Prices, planning, measurements or certificates that come from outside and that a process is waiting for.
Documentation. The current drawings and configuration sit with them, not with you. Without that information, recovering is guesswork.
Specialist knowledge. Two people in the world really know this system, and they both work there.

The last two are almost never counted as supplier risk, and in practice they are the hardest to solve. You can keep a part in stock. Knowledge you cannot.

The question that makes it concrete

Not “how secure is this supplier”, because you will not know and it is not the question you can answer. Instead:

How long can we continue if this party is not there tomorrow, and what do we do then?

That question forces a number, and a number forces a decision. Two hours is a different conversation from two weeks. If nobody knows the number, that is your first finding.

What you want to record per supplier

Thirteen points, and they fit on one page. This is not about completeness but about the points that change the decision:

supplier and the contact you can reach at night;
component or service they provide;
critical process that depends on it;
remote access: do they have a path inwards, and which;
data dependency: which feed comes from them;
tolerable interruption: how long can you continue;
alternatives: is there a second party, and has that ever been tested;
stock: do you hold parts, and for how long;
documentation: do you have the current version, or only they;
knowledge dependency: can you manage without their people;
fallback: what do you concretely do, today, without them;
emergency contact: how do you reach them outside office hours;
owner: who carries this risk, by name.

Do not start with all suppliers. Start with the five you suspect will hurt if they disappear. Usually there is one among them nobody has ever thought about.

What NIS2 does and does not say here

NIS2 names supply chain security explicitly in Article 21 as part of the measures an organisation must take, alongside business continuity and crisis management. In the Netherlands that is implemented in the Cyberbeveiligingswet.

What it does not say, and what you should therefore not claim:

No method is prescribed. This list is a CyberBusters method, not a legal requirement.
It does not apply to every organisation. Whether you fall under NIS2 or the Dutch act depends on sector and size, and that is a legal assessment.
It is not only about your supplier's security, but also about your dependency on them. That second part is often skipped because it looks less like a security question.

For the continuity side, ISO 22301 is the common framework. It is not a NIS2 requirement, but it gives you the vocabulary to hold this conversation in a structured way.

The same question for a PLC vendor, a SaaS provider and an AI model

This is where it gets interesting, and why this article is not only about NIS2.

A control systems vendor, a SaaS provider and the company behind your AI model look like three different conversations. The questions are identical: what do we depend on, what can they reach at our end, what can change at their end without us noticing, what happens if they are not there, who carries that dependency, and where is it written down.

With an AI model there is one addition a PLC does not have: it can change without you doing anything. A model version is updated, the behaviour shifts, and your process gets different outcomes than last week. That is not a fault and it does not show up on a monitoring dashboard.

That is the same pattern as in a decision about a vulnerability and in oversight of an AI application. Why those three are the same question is in the decision pattern behind OT, AI and NIS2.

Frequently asked questions

Is this not simply business continuity management?

Largely yes, and that is exactly the point. What goes wrong in practice is that supplier risk sits with security and continuity sits with another department, so the question “how long can we continue without them” is asked nowhere. The subject is not new; the gap it falls into is.

Do we have to do this for all our suppliers?

No. Start with the suppliers a critical process depends on, and there are usually fewer than ten. A list of two hundred completed forms is administration, not control.

What if a supplier will not share information?

Then that is a finding in itself, and a useful one. You do not need to know how their security works to determine how long you can manage without them. That second part you can work out yourself, and it drives your measure.

Does a cloud service count as a supplier?

Yes, and usually as one of the most important. The question does not change: which process depends on it, how long can you do without, what is the alternative, and who carries that. That the service rarely fails does not make the question less relevant; it only makes the answer less practised.

What is a reasonable tolerable interruption?

You do not set it with a standard but with the process. Ask what happens after an hour, after a day, after a week: at what point does it cause damage you cannot make up. That moment is your limit, and it differs per process inside the same organisation.

Does a completed sheet demonstrate that we comply with NIS2?

No. It helps you hold the conversation and record the decision, which makes demonstrating easier. But conformity is demonstrated against the requirements as they apply to your organisation, with evidence a regulator assesses.

Free: Critical Supplier Dependency Sheet

One page per critical supplier: what you depend on, how long you can do without, what the alternative is and who owns the decision.
No registration required. No mandatory email address.

Download