ISO 27001 applies to an AI company the way it applies to any software company, with three differences in how the ISMS is scoped. The assets include models and weights, training and fine-tuning data, prompts, outputs and embeddings. The risk assessment covers AI-specific threats such as data poisoning, prompt injection, model theft and leakage through outputs. And the model providers you build on are suppliers under A.5.19 to A.5.23, with their terms and certificates reviewed like any other. Those three things, plus the ordinary controls, answer most of a buyer's AI questionnaire. ISO 27001 does not govern whether AI is developed and used responsibly; that is ISO/IEC 42001, which can run on the same management system, and the EU AI Act for systems in its scope. ISO/IEC 27090:2026 gives guidance on the AI-specific security threats within the ISMS.
AI companies reach ISO 27001 for the same reason as everyone else, a buyer asked, and then find that the standard says nothing about models. That is by design: ISO 27001 governs information security regardless of technology, and an AI product is an information system with some unusual assets and threats. This article covers where those show up in the ISMS, what buyers actually ask, and where ISO 42001 and the EU AI Act take over.
Where AI changes the ISMS
- Assets: models and weights, training and fine-tuning datasets, evaluation sets, prompts and system prompts, outputs, embeddings and vector stores, and the pipelines that produce them. Each needs an owner and a classification under A.5.9 and A.5.12.
- Threats: data poisoning, model theft and extraction, adversarial inputs and prompt injection, leakage of training data or other tenants' data through outputs, and compromise of the model supply chain. ISO/IEC 27090:2026 describes them and the measures that address them.
- Suppliers: the model providers, hosting and inference services, data labelling vendors and open-weight model sources. A.5.19 to A.5.23 apply, and the agreements have to say what the provider does with your inputs.
What buyers ask, and where the answer lives
| Buyer question | Where the answer lives in the ISMS |
|---|---|
| Which model providers do you use, and where do they process our data? | The supplier register and agreements (A.5.19, A.5.20, A.5.23); data location in the scope and the risk assessment |
| Is our data used to train your models or your provider's? | The supplier agreement terms (A.5.20) and the acceptable use and classification rules for customer data (A.5.10, A.5.12) |
| How long are prompts and outputs kept, and can they be deleted? | Retention rules and A.8.10 information deletion; the provider's retention terms under A.5.20 |
| How do you keep tenants' data apart in prompts, context and embeddings? | A.8.3 information access restriction, A.8.22 segregation, the secure architecture principles of A.8.27 |
| How do you defend against prompt injection and data exfiltration through the model? | The risk assessment entries, A.8.26 application security requirements, A.8.29 security testing, A.8.12 data leakage prevention |
| Who can access the models, weights and training data? | A.5.15 to A.5.18 and A.8.2 to A.8.4, with the model repository treated like source code |
| How are model and prompt changes controlled? | A.8.32 change management and A.8.25 to A.8.31 applied to the model pipeline, with evaluation results as test evidence |
| What happens when the model misbehaves or is compromised? | A.5.24 to A.5.28 incident management, with model incidents as a category |
| Do you have ISO 42001, and is the system in scope of the EU AI Act? | Outside ISO 27001: the AI management system and the AI Act classification, covered below |
Models, data and prompts as assets
The asset inventory is where the AI company's ISMS first differs. Models and weights are usually the most valuable asset the company owns and are rarely in the inventory; training data often contains personal data or customer data under terms that restrict its use; prompts and outputs are customer data in transit and at rest, and embeddings can reconstruct the text they were made from. Put each in the inventory with an owner and a classification, decide retention and deletion under A.8.10, use masking under A.8.11 in evaluation and development, and treat the model repository with the source-code controls in A.8.4. The Annex A guide lists the controls, and the scope article covers naming the AI service in the scope statement.
Model providers as suppliers
A company building on a hosted model depends on the provider for confidentiality of its inputs, availability of the service and the security of the model itself. Under A.5.19 to A.5.23 that means assessing the provider, reviewing its certifications and reports, putting the security requirements in the agreement, and monitoring the service. The terms that matter are specific to AI: whether inputs and outputs are used for training, how long they are retained, where inference runs, whether the provider's own sub-processors see the data, and how model versions are retired. Providers' ISO 27001 certificates and SOC 2 reports answer the general security questions; the AI terms come from the agreement. The vendor certificate article covers reading the certificate.
AI-specific risks in the assessment
The risk assessment under clause 6.1.2 is where the AI threats go. ISO/IEC 27090:2026, published in October 2026, is guidance rather than a certifiable standard, and it gives a vocabulary for them: poisoning of training data, theft or extraction of models through queries, adversarial inputs that change behaviour, prompt injection that turns the model against its operator, leakage of training data or other tenants' data through outputs, and compromise of models and datasets obtained from third parties. Each maps to existing Annex A controls once it is in the register: the secure development controls A.8.25 to A.8.29 applied to the training and evaluation pipeline, A.8.3 and A.8.22 for isolation, A.8.15 and A.8.16 for logging and monitoring of model use, and A.5.21 for the model supply chain.
Where ISO 27001 stops: ISO 42001 and the EU AI Act
ISO 27001 asks whether information is protected. It does not ask whether an AI system should exist, whether its outputs are fair or explainable, who is accountable for its decisions, or what its impact on people is. Those are the subject of ISO/IEC 42001, the AI management system standard, with an AI policy, roles, AI risk and impact assessments under clauses 6.1.2 to 6.1.4, and 38 reference controls in nine objectives in its own Annex A. It shares the harmonised clause structure with ISO 27001, so one management system can carry both, with two Statements of Applicability, one over 93 controls and one over 38, and combined audits. The EU AI Act then applies its own obligations to providers and deployers of systems in its scope, which neither certificate satisfies on its own. Buyers increasingly ask for all three in the same questionnaire. Noru keeps the AI inventory beside the ISMS, with ISO 42001 and the EU AI Act mapped onto the same control library as ISO 27001, so the AI system records, the controls and the evidence serve each framework once; the AI governance solution describes that side.