NIS2 and AI: mapping Article 21 to concrete controls, one cheat sheet

Fryderyk·published July 6, 2026·updated July 26, 2026·8 min · 1765 words
[compliance]NIS2Article 21AI vendorcompliance
NIS2 and AI: mapping Article 21 to concrete controls, one cheat sheet

NIS2 and AI: mapping Article 21 to concrete controls, one cheat sheet

Reading time: about 10 minutes. Cluster: compliance. Author: Fryderyk.

Short answer first

Article 21 of the NIS2 directive, transposed in Poland through the national cybersecurity act, lists ten areas of risk management measures. None of them names artificial intelligence, yet each maps onto an AI system running inside your organisation. This cheat sheet takes all ten areas and pairs each with the question an auditor will actually ask and the single artefact you need to show. In short: your risk assessment covers the AI system as an asset, incident handling recognises AI-related events, business continuity assumes a model-unavailable scenario, supply chain security closes the vendor contract, and management oversight signs off the deployment decision. The remaining areas, from cryptography to access control, add the technical layers. If you can point to one artefact per area, you are ready for the conversation. If any area is empty, that is your gap.

Table of contents

  1. How to read this cheat sheet
  2. The ten Article 21 areas mapped to AI
  3. Summary table: area, auditor question, artefact
  4. Three mapping traps
  5. Minimum starter set
  6. FAQ
  7. Disclosure and biases
  8. What this note does not cover
  9. Related notes

How to read this cheat sheet

Article 21(2) lists the areas in which an essential or important entity must implement risk management measures. The list is deliberately technology-neutral: it names no specific technology so that it survives market change. That is good news, because you do not have to wait for a separate "AI in NIS2" regulation. The bad news is that the work of translating broad categories into a concrete system falls on you.

For each of the ten areas I give three things: what it means in the context of an AI system, the question an auditor will ask, and the single artefact that answers it. I deliberately reduce each area to one piece of evidence. In practice there may be more, but if you cannot point to at least one, the area is uncovered.

This cheat sheet assumes the AI system is already in your asset inventory. If it is not, start there, because without an inventory entry the other nine areas have nothing to attach to.

The ten Article 21 areas mapped to AI

1. Risk analysis and information system security policies

An AI system is an information system, so it falls here directly. The auditor asks: did you run a risk assessment for this specific system, not just a generic organisational one. Artefact: an AI system risk assessment covering input data leakage, unavailability, output quality in critical processes, and vendor risk.

2. Incident handling

Auditor question: does your incident procedure recognise AI-related events, such as data leakage through a model query or compromise of an account with access to the tool. Artefact: an incident response procedure with explicitly listed AI scenarios and an escalation path to the national CSIRT.

3. Business continuity and crisis management

Question: what happens to the business process when the AI system becomes unavailable. Artefact: a business continuity plan entry describing the process dependency on the AI system and the fallback mode. This is the most frequently skipped area, because teams treat an AI assistant as an add-on rather than an operational dependency.

4. Supply chain security

The model or platform vendor is part of your supply chain. Question: how did you assess their security and what does the contract say. Artefact: a vendor contract (MSA or DPA) with security, sub-processor, and exit clauses. On-prem shortens the chain but does not remove it: model updates, support, and licence terms remain part of it.

5. Security in acquisition, development and maintenance

Question: how do you manage change and vulnerabilities in the AI system across its lifecycle. Artefact: a documented process for updating the model and components, with change impact assessment. A new model is not only better quality, it is also a new risk profile.

6. Policies to assess the effectiveness of risk management measures

Question: how do you know the controls you put in place actually work. Artefact: a record of a review or test of the controls around the AI system, however simple, as long as it is documented. The auditor looks for evidence of a feedback loop, not a declaration.

7. Basic cyber hygiene and training

Question: do users of the AI system know what not to feed it and how to spot misuse. Artefact: training material or a record of a briefing covering the rules of using the AI tool, in particular the data classes that must not be entered.

8. Cryptography and encryption

Question: how is data protected in transit and at rest within the AI system. Artefact: a description of the encryption applied to connections and to stored data, including query logs where these contain sensitive data.

9. Human resources security, access control and asset management

Question: who has access to the AI system and to the data flowing through it. Artefact: an access matrix for the system and the data repositories it integrates with, plus the asset inventory entry. This is where the system register meets the access policy.

10. Multi-factor authentication and secured communications

Question: is access to the AI system and its admin console protected by multi-factor authentication. Artefact: the MFA configuration for user and administrator access, and a description of secured communication channels inside the organisation.

Summary table: area, auditor question, artefact

Article 21 areaAuditor questionArtefact
1. Risk analysisIs there an assessment for this AI systemAI system risk assessment
2. Incident handlingDoes the procedure recognise AI eventsIncident procedure with AI scenarios
3. Business continuityWhat if the AI system is unavailableBusiness continuity plan entry
4. Supply chainHow was the AI vendor assessedContract with security and exit clauses
5. Development and maintenanceHow do you manage model changeUpdate process with impact assessment
6. Effectiveness assessmentHow do you know controls workRecord of a control review or test
7. Cyber hygiene and trainingDo users know what not to enterTraining material for AI users
8. CryptographyHow is data protected in the systemEncryption description, transit and rest
9. Access control and assetsWho can access the system and dataAccess matrix plus inventory entry
10. MFA and communicationsIs access multi-factorMFA and secured channel configuration

Print this table, go row by row, and write the name of your own document next to each one. An empty cell is your pre-audit to-do list.

Three mapping traps

First: treating the AI system as a separate compliance category with its own parallel set of policies. This multiplies work and creates a document flow nobody maintains. AI is a line item in existing artefacts, not a separate silo.

Second: covering only the obvious areas (risk analysis, supply chain) and skipping business continuity and effectiveness assessment. It is precisely these less obvious points that separate an organisation that understands NIS2 from one that ticked a list superficially.

Third: skipping management oversight. After the amendment to the national cybersecurity act, responsibility rests directly with management, so the decision to deploy an AI system should be approved and documented at the right level, not just within the IT team. I wrote about this at length in the note on management liability.

Minimum starter set

If you are starting from zero with limited time, three artefacts close most of the risk and give the auditor something to grip: the asset inventory entry (area 9), the AI system risk assessment (area 1), and the vendor contract with security and exit clauses (area 4). These three are not enough for full compliance, but they cover the questions that come earliest and show that the AI system is not a blind spot. You fill in the rest iteratively, extending existing documents rather than creating new ones.

FAQ

Does Article 21 mention AI at all?

No. The list of areas is technology-neutral and names no specific technology. That is deliberate. An AI system falls under the same ten areas as any other information system, and the organisation's job is to translate the broad categories into concrete controls.

Does an on-prem deployment change this mapping?

It does not change the list of areas, but it changes the weight of some. With processing inside the organisation the supply chain is shorter and data exposure is lower, so areas 4 and 8 carry less risk to describe. All ten stay in play.

How many documents do I really need?

Enough to point to at least one artefact per area. Some artefacts cover several areas at once, for example the asset inventory touches areas 1 and 9. What counts is coverage, not the number of separate files.

No. It is a working tool to organise your preparation. The interpretation of Article 21 depends on sector and facts, and audit practice is still taking shape. Consult a lawyer specialising in cybersecurity for compliance decisions.

// disclosure & biasesDisclosure and biases

I write from the perspective of someone working on AI solutions run outside the public cloud, so I naturally emphasise on-prem and data-flow control. I have tried to separate the text of the rules from architectural preference. This text is not legal advice and does not exhaust the obligations of an essential or important entity. The mapping is my working interpretation, not an official reading.

What this note does not cover

I do not go into the classification of AI systems under the AI Act, which is a separate regime with its own risk categories. I do not discuss the thresholds and deadlines for reporting incidents to the CSIRT, which deserve a separate note. I also leave out sector differences beyond manufacturing and the technical detail of securing the model itself.

FP
// author
Fryderyk Pryjma

Building CortexMine, an on-prem AI platform for European manufacturers under NIS2. Where this bias could affect conclusions, it is flagged inline.

Want to apply this to your case: architecture, compliance, and cost?

→ Book 30 min
// related notes

A vendor's boilerplate DPA stays silent exactly where an auditor looks first. Eight clauses whose absence breaks an NIS2 or GDPR audit: from the sub-processors behind the model API and training use of your data, to logs, breach notice and data deletion.