ISO 27001 and AI vendors: three controls worth mapping today

Reading time: ~7 min

Who this is for: the CISO, compliance lead or IT manager at an essential entity that holds (or is planning) ISO/IEC 27001 certification and is bringing an AI vendor into the organisation – and who wants to know which of the standard's controls this decision touches most directly.

This is not certification advice. It points to where an AI deployment intersects with the information security management system. The scope of certification and the interpretation of controls are settled with your certification body and lead auditor.

Table of contents

1. Why an AI vendor is an ISO 27001 problem, not just an IT one
2. Control 1 – supplier relationships
3. Control 2 – information classification and flow
4. Control 3 – logging and monitoring
5. How this ties into NIS2
6. Disclosure and biases
7. What I do not cover here
8. Related

---

1. Why an AI vendor is an ISO 27001 problem, not just an IT one

ISO/IEC 27001 has no concept of "AI," and it does not need one. The standard talks about information assets, risk and controls – and an AI vendor is simply a new element that touches all three at once. The trouble is that teams deploying AI often treat it as "another IT tool," whereas from the perspective of the information security management system (ISMS) it is a new supplier processing potentially sensitive data, a new channel for that data, and a new surface of risk.

You do not need to map the entire annex of controls to get moving. Three control areas carry the greatest risk of a gap between "we hold the certificate" and "we actually have control over what our AI vendor does." It is worth reviewing them before you sign the contract – not during the recertification audit.

2. Control 1 – supplier relationships

The most important area. ISO 27001 expects the organisation to manage the information-security risk arising from supplier relationships – including setting requirements, monitoring whether they are met, and addressing the whole chain (the supplier's subcontractors too).

The practical questions an auditor will ask about an AI vendor:

• Did the vendor go through a risk assessment as part of the chain, or did it slip in sideways as a tool licence?
• Does the contract address information security, the location of processing and sub-processors – or is it silent?
• Do you know who your AI vendor's sub-processor is? With public model APIs the answer is often "the cloud provider the model runs on" – and that is part of the chain too.

This is exactly the point at which a seemingly technical decision becomes a matter for the ISMS. The absence of a documented vendor assessment is not a neutral state – it is a gap the auditor will flag.

3. Control 2 – information classification and flow

ISO 27001 requires information to be classified and protected according to its sensitivity. An AI deployment tests this control in a new way: data that previously did not leave a given zone may now enter the model's context – and with a public API, leave the organisation's environment entirely.

The control question is not "do you use AI," but "do you know what class of information enters the AI system, and is its handling consistent with your classification policy." If documents marked confidential flow into a prompt sent to an external API while the policy does not provide for it, you have a gap between declared and actual protection. This is one of the most common quiet problems in fast AI rollouts.

4. Control 3 – logging and monitoring

The standard expects event logging and the ability to detect and analyse incidents. An AI system adds a specific difficulty here: you have to be able to reconstruct what data entered the system and what came out of it – especially when it is the AI component that is the source or vector of an incident.

The minimal questions worth resolving at the design stage, not after an incident: are the queries and the context reaching the model logged, where are those logs stored and for how long, and who has access to them. Bear in mind that the prompt logs of an AI system can be one of the most sensitive collections in the whole organisation, because they accumulate out-of-context fragments of many documents at once – so they are themselves subject to the classification and access controls from points 2 and 3.

5. How this ties into NIS2

The good news: these three areas are not work done "alongside" NIS2 – they largely overlap. The duty to oversee the supply chain, awareness of data flow, and the ability to reconstruct events are requirements that both frameworks impose in a similar form. An organisation that maps its AI vendor onto these ISO controls produces a large part of the evidence the NIS2 regime expects as well.

This is the heart of a sensible approach to compliance: not to duplicate work, but to produce one coherent decision trail that serves several frameworks at once. The architecture of an AI deployment affects how hard that trail is to produce – a deployment in which data does not leave the environment simplifies some of the questions about the vendor and the flow, at the cost of taking on responsibility for your own infrastructure. This is not a recommendation of one option, but the observation that the choice of architecture and the cost of auditability are linked.

// disclosure & biases6. Disclosure and biases

The author works on CortexMine, a productized on-prem AI platform for European manufacturers – a category that naturally simplifies some of the questions about the supply chain and data flow. I therefore have an interest in presenting these controls as significant. I have tried to describe them independently of the deployment model: the same three areas have to be mapped for a cloud deployment as for on-prem – only the distribution of the evidentiary work differs. This content is not certification advice.

7. What I do not cover here

• The full list of Annex A controls – I deliberately pick the three with the highest risk of a gap; I do not walk through the whole standard.
• The numbering of specific controls – I refer to them functionally; the exact designations and their interpretation are confirmed by a lead auditor against the current version of the standard.
• The certification process step by step – that is material for a certification body, not for this portal.
• Mapping onto the AI Act and GDPR – a separate, larger topic; here I stay with ISO 27001 and its intersection with NIS2.

8. Related

• Management board personal liability under the amended Polish NIS2 act: what it means for AI decisions
• NIS2 and AI vendors in the supply chain: obligations of essential entities
• Vendor lock-in in AI: three layers, two contractual traps