NIS2 audit readiness for AI: the 7 documents an auditor asks for
NIS2 does not ask for a standalone AI policy. It asks that your AI system sits inside seven documents you already produce. Here is the list, with a mapping table.
NIS2 audit readiness for AI: the 7 documents an auditor asks for
Reading time: about 9 minutes. Cluster: compliance. Author: Fryderyk.
The short answer
You do not need a standalone "AI policy" to walk into a NIS2 audit. What you need is the ability to show that your AI tool is covered by the same risk management, supply chain and incident mechanisms as everything else you run. In practice that comes down to seven documents you already produce when you deploy properly: an entry for the AI system in your asset inventory, a risk assessment for that system, a vendor contract with security clauses, a data flow map, a logging and retention policy, an incident reporting procedure that recognises AI, and evidence of management oversight. None of these is "a document about AI". Each is an existing compliance artefact in which the AI system is simply one more line item. If your starting point is drafting a separate artificial intelligence charter, you are probably heading the wrong way.
Contents
- Why an "AI policy" is the wrong starting point
- The seven documents, one by one
- Table: document, basis, who produces it
- The most common mistake: treating AI as a separate category
- FAQ
- Disclosure and biases
- What this note does not cover
- Related notes
Why an "AI policy" is the wrong starting point
The first reaction many teams have to "what about AI under NIS2" is to write a new, separate document titled "Artificial Intelligence Usage Policy". Understandable, but usually off target.
NIS2 has no category called "AI system" that needs its own regime. The directive, and in Poland the National Cybersecurity System Act after its amendment, speaks about risk management measures (Art. 21), supply chain security and incident reporting duties. An AI system, whether an internal assistant built on a language model or a pipeline processing technical documentation, is simply another IT system that falls under the same requirements.
An auditor will not ask "show me your AI policy". They will ask "show me that this system is in your inventory, that you ran a risk assessment for it, that the vendor contract closes the supply chain, and that you know what happens when something goes wrong". A standalone AI charter that is not wired into those mechanisms is a shelf document, not evidence of compliance.
The practical takeaway: instead of building a new regime, extend your existing artefacts with an "AI system" entry. Below are the seven documents where that happens.
The seven documents, one by one
1. AI system entry in the asset inventory
The starting point. If the AI system does not appear in your IT asset inventory, then for audit purposes it does not exist, which is worse than existing with gaps. The entry should cover the system name and purpose, the business and technical owner, the classification of the data processed, the processing location (on-prem, cloud, hybrid) and the related systems it integrates with.
Processing location is the line the auditor lingers on longest, because supply chain assessment and data exposure flow from it. If queries reach a public model API outside the organisation, that is a sub-processor and must be documented as part of the supply chain.
2. Risk assessment for the AI system
This is not a new species of analysis. It is your existing risk methodology applied to a specific system. It should cover at least: the risk of leaking data fed into the model, the risk of unavailability (what happens when the system goes down), the risk of answer quality in processes where an error carries consequences, and the supply chain risk tied to the model or platform vendor.
The value of this assessment is not in its length but in showing a deliberate decision process. The auditor is looking for proof that the organisation weighed the threats and made choices, not that it adopted a tool because it was fashionable.
3. Vendor contract with security clauses
Art. 21 explicitly covers supply chain security, and an AI solution vendor is part of that chain. The contract, whether an MSA or a DPA, should close: the scope of data processing, sub-processors, security obligations, a right to audit or its equivalent in the form of certifications, and the rules for termination and data portability.
Here the vendor lock-in theme returns, which I discussed in a separate note: the absence of data portability clauses is both an operational risk and a compliance gap. For an on-prem deployment some of these clauses look different than for SaaS, because the data does not leave the organisation, but the contract still has to describe model updates, support and exit conditions.
4. Data flow map
One diagram or one table that answers the question: what data, from where, to where, and with what classification moves into and out of the AI system. This is the document that surfaces a problem fastest, because it forces you to state whether technical documentation, personal data or trade secrets leave the controlled environment.
For the auditor, a data flow map is a shortcut to assessing exposure. If every arrow stays inside the organisation, the conversation is short. If one points outward, the questions about basis, safeguards and consistency with point 3 begin.
5. Logging and retention policy
NIS2 expects the ability to detect and analyse incidents, and that requires logs. For an AI system it matters to document what is logged (access, queries, administrative actions), where the logs are stored, for how long and who can access them.
Logging queries to an AI system can be delicate, because the queries themselves may contain sensitive data. That is not a reason not to log, it is a reason to design the scope and retention deliberately. No logs means that in the event of an incident you cannot reconstruct the sequence of events, which is exactly the capability the directive requires.
6. Incident reporting procedure that recognises AI
You already have an incident response procedure. The auditor's question is whether it covers AI related scenarios. What counts as an incident in the AI context, who classifies it, how escalation runs and how it feeds into reporting duties towards the CSIRT.
You do not need a separate procedure. You need evidence that the existing one recognises events such as a data leak through the AI system, the compromise of an account with access to the tool, or a material failure affecting a business process.
7. Evidence of management oversight
After the amendment to the National Cybersecurity System Act, responsibility for risk management rests directly with management, including personal liability. So the last document is evidence that decisions about the AI system were deliberate and approved at the right level: minutes in which the board or the responsible person accepts the risk assessment and the deployment decision, or an entry in an existing decision register.
This artefact is often skipped, and in the new regime it is one of the most important, because it moves the topic from the IT team up to the level where the law places responsibility. I wrote about this at greater length in the note on board liability.
Table: document, basis, who produces it
| Document | NIS2 area / Art. 21 | Who produces it |
|---|---|---|
| AI system entry in inventory | Asset and risk management | IT / system owner |
| AI system risk assessment | Risk management measures | Risk / security team |
| Vendor contract with clauses | Supply chain security | Legal plus security |
| Data flow map | Data security and exposure | Architect / security |
| Logging and retention policy | Incident detection and analysis | Security / IT |
| Incident procedure covering AI | Incident handling and reporting | Security / SOC |
| Evidence of management oversight | Management accountability | Board / responsible person |
None of the entries in the "who produces it" column introduces a new role. These are teams that already exist in an organisation in scope for NIS2.
The most common mistake: treating AI as a separate category
From an audit preparation standpoint the most expensive mistake is conceptual, not technical. It is carving AI out into a separate compliance silo, with its own policy, its own register and its own process, detached from the rest of the security management system.
The consequences are twofold. First, a parallel document trail appears that nobody maintains, so it goes stale quickly. Second, the auditor will assess the AI system through the same mechanisms as the rest of the infrastructure anyway, so the separate silo does not answer their questions, it only adds work.
The opposite approach, folding the AI system into existing artefacts, has an added benefit: when the next AI system appears, you do not start from zero. You extend the inventory, add a risk assessment, update the data flow map. That scales far better than multiplying separate policies.
FAQ
Does NIS2 require a separate AI policy?
Not explicitly. The directive and the act speak about risk management measures, supply chain and incidents. An AI system falls under those requirements as one more IT system, so the key is to fold it into existing documents rather than create a separate regime.
Does an on-prem deployment exempt you from some of these documents?
It does not exempt, but it simplifies. With processing inside the organisation the data flow map is shorter and the supply chain assessment narrower, because data does not reach an external sub-processor. All seven artefacts are still needed, some simply contain less risk to describe.
Which document should you start with?
The inventory. Until the system is formally registered as an asset, the other documents have nothing to attach to.
Is this enough for full NIS2 compliance?
No. This is the layer that concerns a specific AI system. Full compliance covers the organisation's entire security management system. These seven documents answer the question "how do I show an auditor that AI is not a blank spot", not the question of an essential entity's obligations as a whole.
// disclosure & biasesDisclosure and biases
I write from the perspective of someone working on AI solutions that run outside the public cloud, so I naturally lean into on-prem themes and control over data flow. I have tried to separate what follows from the text of the rules from what is an architectural preference. This note is not legal advice. The interpretation of NIS2 and the National Cybersecurity System Act depends on the specific facts and sector, and audit practice is still taking shape. Consult a lawyer specialising in cybersecurity before making compliance decisions.
What this note does not cover
I do not discuss the classification of AI systems under the AI Act here, as that is a separate regime with its own risk categories. I do not go into sector specifics (energy, healthcare, digital infrastructure entities) where additional requirements apply. I also leave out the technical dimension of securing the model itself, and the operational thresholds and timelines for reporting incidents to the CSIRT, which deserve separate notes.
Related notes
Building CortexMine, an on-prem AI platform for European manufacturers under NIS2. Where this bias could affect conclusions, it is flagged inline.
ISO 27001 and AI vendors: three controls worth mapping today
ISO 27001 has no concept of "AI," yet an AI vendor touches three of its controls at once: supplier relationships, information classification and flow, and logging. Which to map today – and how they tie into NIS2.