NIS2 and UK NIS for AI systems

DORA displaces NIS2 for the regulated entity, but it does not displace it for the non-financial group companies, shared infrastructure, and AI suppliers sitting around it.

I talk to CISOs who assume NIS2 is someone else’s problem because their firm is inside DORA. In most cases that assumption is right for the regulated bank itself. It is frequently wrong for the group structure around it, and it is almost always wrong for the AI supply chain. The distinction matters because the consequences of getting it wrong (NIS2 Article 20 makes management bodies personally liable for failures) are not the kind of thing to discover during a supervisory examination.

This piece maps the three perimeters where NIS2 and UK NIS still reach into an AI programme, the supply-chain duty that applies most directly, and what the EU Cyber Resilience Act adds for firms that build or buy AI products.

The stake

The relationship between DORA and NIS2 is well established in EU law. DORA is lex specialis: its ICT risk-management and incident-reporting requirements are regarded as more stringent than the horizontal NIS2 baseline, and NIS2 Article 4 disapplies the relevant NIS2 provisions for financial entities that fall under DORA. For a bank subject to DORA, the ICT risk-management duty and the incident-reporting duty run under DORA, not NIS2.

What that sentence does not say is equally important. The displacement applies only to the entities DORA actually covers and the activities it governs. Wherever DORA does not reach, NIS2 fills the gap.

The three perimeters where NIS2 still bites

A non-FS entity in a mixed group. DORA carves out financial entities as it defines them. A banking group typically also contains entities that are not financial entities: an in-house cloud provider, a data-centre operator, a managed-security-service provider that serves the wider group or external clients. NIS2 Article 4 does not carve these out; the carve-out reaches only the entities DORA covers. If such an entity falls under one of NIS2’s high-criticality or other-critical sectors, it is in NIS2 scope on its own footing, regardless of what the rest of the group is doing.

The AI angle is concrete. If the entity that builds, hosts, or operates the group’s AI platform, model gateway, or connector estate is a non-FS group company, that platform’s cybersecurity can land under NIS2 even though the banking entity consuming it sits under DORA.

Shared infrastructure that serves beyond the financial entity. The Article 4 carve-out attaches to entities, not to platforms. Where an AI platform or ICT service run within the group is also provided to non-financial entities that are themselves NIS2 essential or important entities, those customers remain fully under NIS2. Their supply-chain duties reach the shared platform from the customer side, whatever the providing entity’s DORA status.

The firm as customer of NIS2-regulated AI suppliers. This is the perimeter most directly relevant to an AI programme. The firm stays under DORA, but its AI suppliers may be independently in NIS2 scope. Cloud and data-centre providers sit in NIS2’s digital infrastructure sector. Managed-service providers and managed-security-service providers sit in the ICT service management sector. Model and connector providers can qualify under either category depending on their size and how they are characterised.

This does not pull the firm into NIS2. It means the firm’s suppliers carry NIS2 duties whose outputs the firm should be reading and requiring.

The UK position: NIS2 does not apply

The UK left the EU before NIS2 existed, so the UK runs the Network and Information Systems Regulations 2018, made under the older NIS Directive. For a UK bank, operational resilience and ICT risk are primarily supervised through the FCA and PRA rules, not through UK NIS. Financial services is not among the sectors UK NIS designates as operators of essential services: the Schedule 1 sector table covers energy, transport, health, water, and digital infrastructure, not banking.

The residual-perimeter logic still applies in spirit. A non-FS UK group entity, an in-house cloud company, or a UK relevant digital service provider can be in UK NIS scope on its own footing even where the regulated bank is not.

One forward-looking point. The Cyber Security and Resilience Bill would amend and extend the 2018 Regulations, broadly widening regulated scope and strengthening incident reporting. As of mid-2026 it is a Bill before Parliament, not enacted law. The 2018 Regulations remain the operative UK position, and nothing in the Bill should be treated as a current obligation.

The supply-chain duty: Article 21 and AI suppliers

The most immediate NIS2 exposure for an AI programme is the supply-chain-security duty. NIS2 Article 21(2)(d) requires essential and important entities to take appropriate and proportionate measures to manage security risks in their relationships with direct suppliers and service providers. Article 21(3) sharpens this into a due-diligence standard: in assessing which measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier and the overall quality of each supplier’s products and cybersecurity practices, including their secure development procedures.

Read onto an AI supply chain, the consequence is direct. A foundation-model provider, a connector or MCP-server provider whose code runs inside the entity’s trust boundary, and a managed-AI operator are all direct suppliers for Article 21 purposes. The duty is not to sign a contract with a security clause. It is to assess each supplier’s specific vulnerabilities and secure-development quality.

The controls this duty calls for are not new. The technical hardening, MCP server and client hardening, model SBOM, artefact signing and verification, and the third-party model vetting pipeline, is the same supply-chain security design I cover for DORA and AI Act purposes. The governance half, due-diligence criteria, contractual controls, concentration risk, and ongoing oversight, runs through the same third-party management process. NIS2 does not invent a new control set. It changes which legal regime labels the perimeter and, importantly, which management body is on the hook for it.

The EU Cyber Resilience Act: build and buy

The EU Cyber Resilience Act is a product-cybersecurity law. Its unit of regulation is the product with digital elements: networked software, which in practice means most AI products. The central obligations land on the manufacturer: the entity that develops an AI product and makes it available on the EU market under its own name.

For firms that build AI products for external exposure, the CRA manufacturer duties are relevant from two dates. The vulnerability and incident reporting obligation (Article 14) applies from 11 September 2026. The main manufacturer obligations, including essential cybersecurity requirements and conformity assessment, apply from 11 December 2027. The reporting duty bites more than a year before the main obligations, which is the planning point: a firm expecting to be a CRA manufacturer needs its vulnerability-reporting pipeline ready first.

For firms that buy AI products, the CRA gives a concrete assurance signal to demand from suppliers: CE marking, a declaration of conformity, an SBOM, a coordinated-disclosure policy, and a stated support period of at least five years. This feeds into buy-side diligence alongside SOC 2 and ISO 27001 certification, and it standardises an expectation that previously had to be negotiated case by case.

The UK has no equivalent of the CRA. This is a genuine divergence point: a firm building or buying AI products for the EU market faces CRA obligations that have no automatic UK counterpart. Scope the CRA to where the product is made available on the EU market; do not assume a UK build or a UK sale carries a parallel duty.

What to do this week

1. Run the two-question boundary test on your AI programme. First: is the entity that builds, hosts, or operates this AI capability a DORA financial entity, or a different kind of group company? Second: does any non-FS group entity, shared platform, or supplier sit on one of the three perimeters above?
2. Map your AI suppliers against NIS2 scope. Which of your model providers, connector providers, and managed-AI operators are themselves NIS2 essential or important entities? Their NIS2 status is assurance you can require and review.
3. For any in-scope group entity under NIS2, apply the Article 21(3) due-diligence standard to direct AI suppliers. This means assessing their secure-development practices, not just their contractual commitments.
4. If you build an AI product for the EU market, check whether you are a CRA manufacturer and stand up your Article 14 vulnerability-reporting pipeline before September 2026.
5. Add CRA conformity evidence to your standard AI procurement diligence: CE marking, declaration of conformity, SBOM, and support period, alongside your existing vendor assessment criteria.