Directive (EU) 2022/2555 in plain language: which articles bind an AI vendor

Directive (EU) 2022/2555, known as NIS2, runs to 46 articles, and most of them are addressed to member states and supervisors rather than to companies. If you sell AI systems into European organisations, only about nine articles ever touch you. Two bind you directly when you are in scope yourself: Article 21 on risk-management measures and Article 23 on incident reporting. Five reach you through your customer's obligations, which is where most vendor work actually comes from. Two more decide whether you are in scope at all. This piece walks each one in plain language and names the artefact it turns into on your side.
First: are you in scope at all?
Scope is settled by Articles 2 and 3 together with Annexes I and II. Article 2 sets the general rule: the directive applies to entities of a type listed in the annexes that reach medium-size thresholds, meaning at least 50 staff or annual turnover and balance sheet above 10 million euro. Article 3 then splits those entities into essential and important, which decides how hard supervision bites rather than what you must do.
For an AI vendor the relevant annex entries are usually Annex I on digital infrastructure, covering cloud computing service providers and data centre service providers, and Annex II on ICT service management, covering managed service providers and managed security service providers. A vendor that hosts and operates an AI platform for customers is commonly a managed service provider. A vendor that only licenses software the customer installs and runs is often outside scope entirely.
The two articles that bind you directly
Article 21: risk-management measures
Article 21(1) requires appropriate and proportionate technical, operational and organisational measures, judged on an all-hazards approach and against the state of the art. Article 21(2) then lists ten minimum areas that every in-scope entity must cover. This list is the backbone of almost every security questionnaire circulating in Europe, because customers copy it directly.
| Article 21(2) | Plain language | Your artefact |
|---|---|---|
| (a) | Risk analysis and information system security policies | Approved security policy set plus a risk register naming model and data assets |
| (b) | Incident handling | Incident response plan with a severity table and a tested escalation path |
| (c) | Business continuity, backup management, disaster recovery and crisis management | RTO and RPO figures per service, plus the last restore test result |
| (d) | Supply chain security, including your own suppliers and service providers | Supplier security standard, subprocessor list, completed assessments |
| (e) | Security in acquisition, development and maintenance, including vulnerability handling | Secure development standard, patch SLA with measured performance, SBOM per release |
| (f) | Policies to assess the effectiveness of the measures | Internal audit or control testing schedule with findings closed |
| (g) | Basic cyber hygiene and security training | Training records by role, refreshed annually |
| (h) | Cryptography and encryption policies | Cryptography standard with algorithms, key lengths and key custody |
| (i) | Human resources security, access control and asset management | Joiner and leaver records, quarterly access reviews, asset inventory |
| (j) | Multi-factor authentication, secured communications and secured emergency communication | Enforced MFA policy with scope, plus an out-of-band incident channel |
Two subsections matter beyond the list. Article 21(3) tells entities to take into account each supplier's specific vulnerabilities and overall security practices, which is the legal source of vendor due diligence. Article 21(4) allows supervisors to require corrective action where measures fall short, which is why an unclosed finding is worse than an open risk.
Article 23: reporting significant incidents
Article 23 sets the reporting chain that everyone quotes. An incident is significant if it has caused or is capable of causing severe operational disruption or financial loss, or has affected or is capable of affecting other persons by causing considerable material or non-material damage. Capability is enough; actual damage is not required.
- Early warning within 24 hours of becoming aware, stating whether the incident is suspected to be caused by unlawful or malicious acts and whether it may have cross-border impact.
- Incident notification within 72 hours, updating the early warning with an initial assessment of severity, impact and indicators of compromise.
- An intermediate report on request from the CSIRT or competent authority.
- Final report within one month of the notification, covering a detailed description, the type of threat or root cause, applied mitigations and any cross-border impact.
- Where the incident is ongoing at one month, a progress report then, and a final report within one month of handling it.
Article 23(1) also requires notifying recipients of your services about significant incidents likely to adversely affect the provision of that service. That duty runs to your customers on your own initiative, not on their request, and it is the clause vendors most often discover late.
The articles that reach you through your customer
| Article | What it says | How it reaches you |
|---|---|---|
| Article 20 | Management bodies must approve the risk measures, oversee implementation and can be held liable; they must follow training | A named executive has to defend the choice of vendor, so approvals and evidence are demanded in writing |
| Article 21(2)(d) and 21(3) | Supply chain security and consideration of each supplier's security quality | The security questionnaire, the audit right, the subprocessor disclosure |
| Article 22 | Coordinated security risk assessments of critical supply chains at Union level | Sector-wide scrutiny of specific technologies and providers, which can shift buying criteria without any change in your contract |
| Article 23 | Your customer's own 24 hour and 72 hour reporting duty | A contractual notification window on you, tight enough to leave them working time |
| Article 24 | Member states may require certified ICT products, services and processes | Certification becomes a tender condition in some member states rather than a differentiator |
| Articles 32, 33 and 34 | Supervisory powers, inspections and administrative fines up to 10 million euro or 2 percent of turnover for essential entities | The reason your customer cannot accept a vague answer, whatever your commercial relationship |
Article 20 is the one to read if you want to understand the tone of the questionnaires. Personal accountability at management level changes behaviour: an executive who can be held liable does not accept we take security seriously as an answer, because that sentence cannot be shown to a supervisor.
Articles you can safely stop reading
- Articles 7 to 13 build national cybersecurity strategies, CSIRTs and single points of contact. Useful context, no obligations on you.
- Articles 14 to 19 set up the cooperation group, the CSIRTs network, EU-CyCLONe and peer reviews. Institutional plumbing.
- Articles 25 to 29 cover standardisation and voluntary information sharing. Relevant if you join a sharing arrangement, otherwise not.
- Articles 30 and 31 concern registration of entities and jurisdiction, worth one read if you operate in several member states.
- Articles 35 to 46 handle relationships with GDPR and DORA, penalties, transposition and repeal of the old NIS Directive.
What to do with this map
Work through Article 21(2) once, item by item, and record the document that satisfies each of the ten. Then write two numbers into your contracts: the hours within which you notify a customer of an incident, and the window in which you provide the facts they need for their own 72 hour notification. Those three pieces of work close the majority of what NIS2 will ever ask of an AI vendor, whether you are in scope yourself or answering for a customer that is.
Nine articles out of forty-six decide your position. Reading the other thirty-seven is education; preparing for these nine is compliance.
Frequently asked questions
- Which NIS2 articles apply to an AI vendor directly?
- Articles 21 and 23 when the vendor is itself in scope, plus Articles 2 and 3 which decide scope, and Article 20 which sits on its management body. Everything else reaches a vendor indirectly, through a customer's supply chain duties or a supervisor's powers.
- Are we in scope if we only license software?
- Usually not. Scope follows the entity types in Annexes I and II. Hosting and operating a platform for customers typically makes you a managed service provider or a cloud computing service provider; shipping software the customer installs and runs itself generally does not, though national transpositions vary.
- Do we have to notify customers of incidents, or only authorities?
- Both, where you are in scope. Article 23 requires notification to the CSIRT or competent authority on the 24 hour and 72 hour clock, and separately requires informing recipients of your services about significant incidents likely to adversely affect the service.
- What makes an incident significant under Article 23?
- Severe operational disruption or financial loss to the entity, or considerable material or non-material damage to other persons. The test includes incidents merely capable of causing those effects, so a contained incident with wide potential impact can still be reportable.
- Does NIS2 or the national law apply to us?
- The national transposition applies. NIS2 is a directive, so obligations bind through each member state's implementing law, and those differ on thresholds, registration and reporting portals. Check every member state where you have an establishment or a customer in scope.
Related articles
NIS2 Supply Chain Audit Checklist: 31 Questions
The 31 questions a NIS2 supply chain audit puts to an AI vendor, grouped by theme, each with the artefact that closes it and the answers that fail.
NIS2 Transposition Gap: Five States, One Chain
How uneven NIS2 transposition across Germany, France, the Netherlands, Poland and Ireland changes what an AI vendor must prove, and how to answer with one evidence pack.
Passing an NIS2 Supplier Audit as an AI Vendor
NIS2 reaches AI vendors through the customer contract. The five evidence artefacts buyers request, the incident clocks, and what to prepare before the questionnaire.
Next step
Need this as an outcome, not an article? NIS2 supplier audit.
Your customer is in scope for NIS2, so you are audited as part of their supply chain. That audit asks for artefacts, not intentions: asset inventory, patch windows, incident timelines, subcontractor list, exit plan.
Explore NIS2 supplier audit


