NIS2 in Belgium: Is Your AI Supplier in Your Supply Chain?

Probably yes, but only if they are your direct supplier. The Belgian NIS2 law puts supply chain security inside your own duty of care, and it reaches the relationship between you and your direct suppliers and service providers. The party holding most of the answers about an AI system, the model provider, usually sits one tier beyond that. Your questionnaire reaches the wrong desk.

This is written for the IT manager, informatiemanager or security officer at a Belgian organisation of roughly 250 to 5,000 employees that has been registered as an essential or important entity, and that has put an AI assistant, a retrieval system or an agent into production alongside an existing ICT partner. You already have a framework choice, an audit calendar and a supplier questionnaire. What you probably do not have is a version of that questionnaire that survives contact with an AI supplier.

One thing first, because Flemish readers are routinely served Dutch material that does not apply to them. The Netherlands has its own transposition, the Cyberbeveiligingswet, in force since 15 August 2026. Belgium is a different regime with different dates and a different framework, and it moved first: the Law of 26 April 2024 entered into force on 18 October 2024, making Belgium the first Member State to transpose the directive. If you are reading an article that says your obligations started in August 2026, you are reading about the country next door.

Does the Belgian NIS2 law reach your AI supplier at all?

Not directly, in most cases. The law binds entities that meet a size threshold and provide a service listed in its annexes, using the definitions in Commission Recommendation 2003/361/EC. An Annex I service at large-enterprise size makes you essential; an Annex I service at medium size, or any Annex II service, makes you important. A twenty-person AI studio building a retrieval system for your document archive is neither.

It reaches them through you instead. Essential and important entities must secure their supply chain, and the Belgian framing is specific: the duty covers security-related aspects of the relationship between the entity and its direct suppliers or service providers. That word direct is doing real work, and it is the same limit the Dutch law draws. Your AI supplier is in scope of your duty because you contracted them. Whoever they buy their model from is not.

So the enforcement route is commercial, not regulatory. Nobody from the CCB will inspect your AI supplier. An inspector will look at what you asked for, what you were told, and what you did about the gaps.

Why does the CCB point your suppliers at CyberFundamentals Basic?

Because Belgium built a floor the Dutch regime does not have. The CyberFundamentals framework, CyFun, is the CCB's tiered control set, and a validated implementation earns a presumption of conformity with the risk-management obligations: until shown otherwise, you are presumed to have met them. The CCB advises every organisation that may find itself in a NIS2 entity's supply chain to comply at least with CyFun Basic, and notes that a NIS2 entity could in theory impose a given CyFun level on its direct suppliers.

That advice has teeth now. At the one-year mark the CCB reported 1,500 essential and 2,500 important entities registered, with 75 percent having already selected a framework and a majority of those choosing CyFun. Four thousand organisations with a framework and an audit date generate a lot of supplier questionnaires, and the ones landing in AI suppliers' inboxes this year are CyFun-shaped.

There was a hard checkpoint on 18 April 2026. Essential entities had to show the CCB inspection service one of three things: a CyFun Basic or Important verification obtained or actively in progress, or a signed agreement with an accredited assessment body; or an ISO/IEC 27001 scope, Statement of Applicability and most recent internal audit report, with full certification due by April 2027; or a self-assessment plus a formal request for direct inspection, a route the CCB notes may lead straight to supervisory measures. That date has passed. If you are in scope, the questionnaires are no longer hypothetical.

The inspection service returned to the subject on 11 August 2026, in a communication to essential entities under article 48 of the NIS2 law. Its theme was the cyber risk arriving with frontier AI systems, and it named supply chain security among the processes that advanced AI changes, alongside governance, risk assessment, monitoring and incident response. The letter went to entities directly rather than being published in full, so treat the summary on the CCB news page as the public record of it. The point here is that the regulator has already put AI and supply chain security in the same sentence.

Which CyFun questions can an AI supplier actually answer?

More than people expect. Strip the questionnaire down to what a first-tier supplier controls and a competent AI supplier should answer without hesitation:

• How they authenticate into your environment, with which account type, and whether that credential is shared with any other client.
• Which of their staff can read the prompts and documents your users send, under what logging, and for how long.
• Their own basic hygiene: multi-factor authentication, patching cadence, backup and restore, and joiner-mover-leaver for the people on your account.
• Their subcontractor list, and whether any of it changed since the contract was signed.

• The route and the clock for telling you about an incident on their side, which has to fit inside your own reporting obligations.

That last one is where most AI contracts are silent and where the cost of silence is highest. Under the Belgian regime a significant incident requires an early warning to the CCB within 24 hours of becoming aware of it, an incident notification within 72 hours, an interim report on request and a final report within a month. A supplier who tells you on Tuesday about something they saw on Friday has consumed your 24-hour window before you knew it opened. That clause is worth more than the certificate.

Which questions can only the model provider answer, and will not?

Here is the structural problem, and it is not your supplier being evasive. A questionnaire built for a hosting or software supplier assumes the party you contracted operates the thing you are asking about. With an AI system, four of the most load-bearing questions are about infrastructure your supplier rents:

• What happens to a prompt after it leaves your supplier's application: how long it is retained, whether it enters abuse monitoring, and whether a human can read it.
• Which region a specific inference call actually ran in, as opposed to which region the account is configured for.
• How much notice, if any, is given before a model version changes underneath a stable API.
• Whether a model update counts as a change your supplier is contractually obliged to tell you about.

A model provider publishes terms for all customers and negotiates individually with very few. Your supplier cannot make those terms say something else, and a small AI supplier has no more leverage with a frontier lab than you do. Pressing harder on the first tier produces a longer answer, not a better one.

So the honest verdict is that a supply chain duty stopping at the direct supplier stops one party short of the answers. That is not a drafting flaw to argue around. It is the shape of the obligation, and the useful response is to stop asking the first tier to warrant facts it does not control.

What do you put in the contract instead of a certificate?

Three things, and none of them requires your supplier to hold a CyFun label they were never going to buy. First, a flow-down obligation: the supplier names the model providers and subprocessors behind the service, keeps that list current, and tells you before it changes. You are not making them responsible for the upstream party's security. You are making them responsible for the transparency you cannot get yourself.

Second, notification symmetry. The supplier tells you about an incident, a material terms change, or a model version change within a window that leaves your own 24-hour early warning intact. Write the hours down. A clause saying "without undue delay" does not survive contact with a Friday afternoon.

Third, and this is the one most often skipped, a named change category for model behaviour. A model that starts answering differently without a deployment is not an availability event, and it will not appear on anyone's monitoring. We have argued elsewhere that nobody gets paged when an AI system is up and wrong; the contractual version of that argument is that if model behaviour is not a change, nobody has to tell you it changed.

What you are building here is a record that you asked, were told, and acted. Under ex-ante supervision for essential entities, that record is the thing an inspector can see. A certificate your supplier does not hold is not.

Does CyFun 2023 or CyFun 2025 apply when you send the questionnaire?

Both, for now, and it is worth getting right before you send anything. The CCB released CyFun 2025 in October 2025, aligned more closely with the NIST Cybersecurity Framework 2.0 and with NIS2. Its headline changes are directly relevant here: more focus on supply chain security, more focus on operational technology, and governance measures added from the Important assurance level upward.

The CCB has said both versions remain available during a transition period. Accredited assessment bodies publishing their own transition guidance put the end of the choice at 18 April 2027, with 2023-based statements valid until 18 April 2028 at the latest. Treat those two dates as the certification bodies' reading rather than as law you can quote back at an inspector, and confirm them with your own assessor. The planning consequence holds either way: if your own conformity work is heading for CyFun 2025, ask your suppliers the 2025 supply chain questions now rather than re-asking them next year.

Note also that you may justify a CyFun assurance level below your NIS2 classification on the basis of a risk analysis, and that the inspection service can sanction you for conforming to a lower level than your risk actually warrants. The same logic should govern what you demand of an AI supplier. A Basic-level expectation on a supplier whose system touches your customer records is a decision you will have to defend, not a saving.

Where this leaves an IT organisation that already has partners

You do not need a new ICT partner to do any of this, and we are not offering to be one. Crux Digits builds and integrates AI systems alongside the ICT partner or internal IT team you already have; we do not run service desks, infrastructure or estate management, and we are not a conformity assessment body, so we cannot verify anyone against CyFun. What an AI supplier owes you here is answerable evidence about its own half of the system and honesty about the half it rents.

The practical order of work is unglamorous. Take your existing supplier questionnaire, split it into what the first tier controls and what it rents, get firm answers on the first half, get the flow-down and notification clauses on the second, and keep the correspondence. If the AI system also falls under the AI Act, the obligations run in parallel rather than replacing each other, and the reporting clocks are not the same length.

If you want the supplier questions settled before go-live rather than after the first audit letter, that is a conversation worth having while the architecture is still movable.

Frequently asked questions