Date: 9/7/2026

Cybersecurity

One question, three domains: the decision pattern behind OT, AI and NIS2

A vulnerability in a plant, an AI agent with sending rights and a supplier you depend on are the same conversation. Question, context, decision, owner, evidence, review.

TL;DR

A vulnerability in a plant, an AI agent with sending rights and a supplier your production depends on look like three different conversations. They are not. In all three you ask the same six questions: what is it, what is the context, what do we decide, who owns it, where is it recorded, and when do we look again. The subject differs. The question does not.

There is a pattern that comes back in almost every conversation, whether it is about a PLC, an AI application or a supplier who suddenly cannot be reached. It rarely stands out, because the three subjects are handled by different people, in different meetings, using different words.

Yet it is always the same question:

What can it do, what may it do, who owns the risk, who can intervene, and can we show afterwards that the decision was taken in a controlled way?

This article explains that pattern and shows what it looks like in each of the three domains. The individual subjects have their own articles; this is the map over the top.

Six steps, three domains

The same decision pattern in three columns (ISA/IEC 62443, ISO/IEC 42001 and NIS2) with the steps question, context, decision, owner, evidence and review. — The subject differs per column. The question does not. Anyone who can answer these six steps in one domain can ask them in the other two.

Question, context, decision, owner, evidence, review. That is the whole method. It is not complicated; it is simply rarely finished. In practice the conversation usually stops after step three, leaving a decision nobody owns and that is recorded nowhere.

Important: this is a CyberBusters method, not a standards model. What sits under each step does come from standards and legislation, and that is named per domain below.

Step by step

1. Question: what exactly are we talking about?

It sounds obvious and often goes wrong here already. A CVE number without an asset is not a question. An AI application without knowing what it may do is not a question. A supplier without the process attached to it is not a question. Scoping comes first, and in IEC 62443 that is called the *System under Consideration* for a reason.

2. Context: what makes this serious, or not?

This is where a score turns into a risk. Exposure, attack path and operational impact in OT. Data, autonomy and authority in AI. Service impact and how long you can do without under NIS2. Without this step, every decision is a guess with a number attached.

3. Decision: and not “on the list”

Each domain has its own outcomes, but the logic is identical: there are a few possible answers and you pick one. Patch, mitigate, monitor or accept. Allow, restrict or escalate. Take a measure, fall back or accept. An open finding is not a decision.

4. Owner: a person, not a department

This is the step most often missing, and the only one you cannot outsource to a document. Who owns the residual risk if we do not patch? Who may stop the AI? Who may decide at three in the morning? If the answer is a department name, there is no owner.

5. Evidence: otherwise it does not exist

What did you know, what did you weigh, what did you decide, and when. Without a record you cannot show afterwards that thought went into it, and then an auditor sees no difference between a considered decision and coincidence. Nor will you, six months later.

6. Review: a date, not an intention

Every decision was taken with the knowledge of that moment. Exposure changes, suppliers change, models get updated. A decision without a review date is a decision that slowly becomes untrue without anyone noticing.

What it looks like in OT

A vulnerability in an industrial environment. The question is not “is there a CVE”, but whether anyone can realistically reach it and what it costs to do something about it. The decision ends in patch, mitigate, monitor or accept, with an owner and a review date.

Worked out in OT vulnerability management is not IT patch management. The step before it, scoping and dividing the environment, is in a VLAN is not an IEC 62443 segmentation strategy.

Standards basis: the ISA/IEC 62443 series, with 62443-3-2 for zones and conduits and 62443-2-3 for patch management in an IACS environment.

What it looks like in AI

An AI application. The question is what the system may observe, recommend, decide and execute. The context is what data it sees and how much it does on its own. The decision is allow, restrict or escalate, with someone who can stop it and a record of what was agreed.

Worked out in human oversight is a control, not a slogan.

Standards basis: ISO/IEC 42001 for the management system and ISO/IEC 23894 for risk management. Whether the EU AI Act sets requirements for your application is a legal question and depends on the risk class.

What it looks like under NIS2

A dependency. The question is what you depend on and which process hangs off it. The context is what stops and how long you can sustain that. The decision is a measure, a fallback or an explicit acceptance, with a director who owns it and an exercise that shows it works.

The background and the governance side are in the Dutch Cybersecurity Act is in force.

Basis: NIS2 and the Dutch Cyberbeveiligingswet. Mind the scope: not every organisation falls under it, and that is a legal assessment, not a technical one.

Why this is one story and not three

Because an organisation that masters this pattern in one domain learns it faster in the other two. The words differ, the skill does not: scope, weigh, choose, assign, record, revisit.

And the reverse: an organisation that finishes it nowhere recognises itself in all three domains. The OT connection nobody can justify, the AI workflow nobody owns, the risk nobody has accepted. That is the same failure three times, not three problems.

Frequently asked questions

Is this pattern a standard or a framework?

No. It is a CyberBusters method. The content of each step comes from standards and legislation (ISA/IEC 62443, ISO/IEC 42001, NIS2), but the pattern itself is a way of laying those over each other, not something written in a standard.

Can you demonstrate conformity with this?

No. Conformity is demonstrated against a specific standard, with evidence an auditor assesses. This pattern helps make those decisions traceable, which makes demonstrating easier, but it is not evidence in itself.

Do you have to tackle all three domains at once?

No, and usually that is not a good idea. Start where the consequences are largest and where you already know something. The gain is that the second domain goes faster because the questions are familiar.

Where do you start if you are starting from nothing?

At step four. Take three things running today: a connection, an AI application, a supplier, and find out who owns them. If you cannot answer that within a day, you know where the work is.

How does this relate to ISO/IEC 27001?

ISO/IEC 27001 is a management system for information security and covers much of this pattern at organisational level. What is added here is the translation into decisions in a plant and about AI applications, where availability, safety and autonomy produce different trade-offs than office automation does.