Key takeaways
- ISO/IEC 27090:2026 was published on 14 October 2026 by ISO/IEC JTC 1/SC 27. It runs to 56 pages and gives guidance on understanding, detecting, and mitigating security threats specific to AI systems across their life cycle.
- ISO 27090 is a guidance document, not a management system standard. There is no ISO 27090 certification; its value lies in feeding the ISO 27001 risk assessment and the ISO 42001 AI management system you may already run.
- Clause 6 of the standard names nine types of compromise: data poisoning, evasion, membership inference, model exfiltration, model inversion, direct model poisoning, sensitive model output, prompt injection, and output that contains injection attacks.
- An ISO 42001 certificate shows that AI is governed; it says nothing about whether an AI system withstands these nine attacks. ISO 27001 clause 6.1.3 lets you take controls from any source, so 27090 mitigations can be cited directly in your Statement of Applicability.
- Under the EU AI Act, Article 15 requires high-risk AI systems to resist attacks such as data poisoning, model poisoning, and adversarial examples. Those obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems.
If your company holds an ISO 27001 certificate and has shipped an AI feature in the last two years, ISO 27090 answers a question your auditor and your customers will start asking: does your information security management system actually cover the AI? For most companies the answer is "partly". Access control, supplier management, and secure development still apply to an AI system. What is usually missing from the risk register is the set of attacks that target the model itself rather than the infrastructure around it.
This guide explains what ISO/IEC 27090 contains, how it relates to ISO 27001, ISO 42001, and the EU AI Act, and how to bring its threats into an existing ISMS without starting a new compliance program. If you are new to the standard behind your ISMS, start with our complete ISO 27001 guide.
What is ISO/IEC 27090?
ISO/IEC 27090 is an international standard that gives organizations guidance on security threats and compromises specific to AI systems: how they work, what their consequences are, and which measures detect and mitigate them. It applies to organizations of any size that develop or use AI systems, across the full AI life cycle.
The working group behind it, ISO/IEC JTC 1/SC 27/WG 4, started development in 2022. The first edition was published on 14 October 2026, according to the official ISO listing. SC 27 is the same committee responsible for ISO 27001 and ISO 27002, which is why 27090 reads as an extension of familiar information security practice rather than a separate discipline.
Clause 5 covers the security practices that frame everything else: an AI governance program, zero trust principles, software engineering practice applied to AI, supply chain management, threat modelling, and red teaming. Clause 7 then describes mitigations and, usefully, how they interact with each other and with the threats. Informative Annex A maps attacks to the AI system life cycle and to assets, Annex B covers AI-specific versions of conventional attacks, and Annex C deals with federated machine learning.
A common misconception is that 27090 is "the AI version of ISO 27001". It is not. ISO 27001 sets requirements for a management system and can be certified. ISO 27090 is a catalog of threats and countermeasures, closer in spirit to ISO 27002, and nobody can certify you against it.
The nine AI threats ISO 27090 names
Clause 6 of ISO 27090 describes nine types of potential compromise to AI systems. What they share is that conventional controls such as firewalls, encryption, and access management can be fully in place while the attack still succeeds, because it works through data and inputs the system is designed to accept.
- Data poisoning attack: manipulated training data changes how the model behaves.
- Evasion attack: inputs crafted to make the model produce a wrong result, such as a fraud check that waves a transaction through.
- Membership inference: an attacker determines whether a specific record was part of the training data.
- Model exfiltration: the model itself, or a functional copy of it, is extracted, often through queries that look legitimate.
- Model inversion: information about the training data is reconstructed from the model's outputs.
- Direct model poisoning: the model's parameters or a pre-trained component are tampered with directly.
- Sensitive model output: the model returns confidential or personal data it should not reveal.
- Prompt injection: instructions hidden in an input, a document, or a web page override the system's intended behavior.
- Output contains injection attacks: the model's output carries a payload that harms a downstream system, such as a script rendered in a browser.
Two of these deserve particular attention for companies that build on third-party models. Prompt injection matters as soon as an AI system reads content you do not control, such as customer emails, support tickets, or uploaded files. Data and model poisoning matter whenever a system retrains on operational data, because today's inputs become tomorrow's training set.
ISO 27090 vs ISO 42001 vs ISO 27001
ISO 27001 governs information security, ISO 42001 governs how an organization manages AI, and ISO 27090 describes how AI systems are attacked and defended. The first two are certifiable management system standards; 27090 is guidance that feeds both.
The mistake most teams make here is assuming an ISO 42001 certificate covers AI security. It does not. 42001 asks whether you have an AI policy, impact assessments, defined roles, and controls over the AI life cycle. It does not test whether your model leaks training data under a membership inference attack. The two standards fit together cleanly: 42001 decides which AI systems you run and why, 27090 describes how they are attacked, and the ISO 27001 risk process decides which mitigations you apply. How an AI management system is built and certified is covered in our overview of ISO 42001.
The EU AI Act adds a legal layer for high-risk AI systems. Article 15, as set out in the Regulation, requires them to achieve an appropriate level of accuracy, robustness, and cybersecurity, and names data poisoning, model poisoning, adversarial examples, and confidentiality attacks as threats to address. ISO 27090 is not a harmonised standard under the AI Act, so applying it does not create a presumption of conformity. It is still one of the most specific published references for the threats Article 15 names. After the Digital Omnibus on AI, the high-risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for systems embedded in Annex I products. Which systems count as high-risk is explained in our guide to high-risk AI under the EU AI Act.
How to bring ISO 27090 into your ISO 27001 ISMS
You do not need a separate AI security program. ISO 27001 already contains every hook 27090 needs: an asset inventory, a risk assessment under clause 6.1.2, risk treatment and the Statement of Applicability under clause 6.1.3, and supplier and development controls in Annex A. The work is to extend each of them to the AI systems in your scope.
Step 1: Inventory your AI systems as assets
Start by listing every AI system inside the ISMS scope, including features built on external model APIs, internal assistants, and machine learning models in production. For each one, record the model source, the training or fine-tuning data, the retrieval sources it reads, and who can query it. This extends Annex A control 5.9, the inventory of information and other associated assets. Annex A of ISO 27090 maps each attack to the life cycle stage and asset it targets, so a complete inventory tells you which threats apply.
Step 2: Add the nine threats to your risk assessment
Next, run each AI system through the nine compromise types in Clause 6 and add the relevant ones to your risk register with likelihood and impact, exactly as you would for any other threat. Clause 5.6 of 27090 recommends threat modelling for this step. Not every threat applies everywhere: a company that consumes a hosted model and never trains its own faces little direct data poisoning risk, but a high prompt injection risk if the model reads customer content.
Step 3: Select controls and cite 27090 in the Statement of Applicability
ISO 27001 clause 6.1.3 states that the controls in Annex A are not exhaustive and that organizations can identify controls from any source. That makes 27090 citable directly. Most AI threats map onto existing Annex A controls, extended in scope; a few need additional controls of your own. The table below shows our mapping. It is a working interpretation, not part of either standard, so validate it against your own scope.
The full list of ISO 27001 Annex A controls, and what an auditor expects as evidence for each, is covered in our separate guide.
Step 4: Extend supplier checks to model providers
Few companies train foundation models themselves, which moves much of the AI risk to suppliers. Clause 5.5 of ISO 27090 treats supply chain management as its own topic. In practice that means adding questions to your supplier assessments under A.5.19 and A.5.20: whether the provider uses your inputs for training, how pre-trained components are verified, how model updates are announced, and what testing the provider performs against evasion and prompt injection.
Step 5: Test the AI system, not only the infrastructure
A standard penetration test checks the servers, the APIs, and the authentication around an AI feature. It rarely tests whether the model can be talked into ignoring its instructions. Clause 5.7 of 27090 recommends red teaming for exactly this reason. Schedule it as part of acceptance testing under A.8.29, and repeat it when the model, the system prompt, or the retrieval sources change.
Example: an 80-person SaaS company adds an AI support assistant
Consider a hypothetical 80-person SaaS company, ISO 27001 certified since 2024, that launches a support assistant built on a hosted large language model. The assistant reads customer tickets and answers from the company's help center and past ticket history.
Running the assistant through Clause 6 produces three new entries in the risk register. Prompt injection rates high, because every ticket is untrusted input. Sensitive model output rates high, because past tickets contain other customers' data. Output containing injection attacks rates medium, because answers are rendered in the support agent's browser. Data poisoning rates low, because the company does not train the model.
The treatment touches four existing controls rather than creating new ones. Retrieval is restricted to the requesting customer's own tickets (A.5.15), output is filtered before rendering (A.8.26), the model provider's contract excludes training on company data (A.5.20), and a red-team test is added to the release checklist (A.8.29). The Statement of Applicability cites ISO 27090 Clause 6.9 and 6.8 as the source for the new scope. At the next surveillance audit, the auditor sees AI threats handled inside the existing ISMS rather than in a side document nobody maintains.
How Kertos helps you cover AI in your ISMS
Kertos runs ISO 27001 and ISO 42001 on one platform, so the AI systems in your AI management system and the risks in your ISMS live in the same place instead of two spreadsheets. AI systems are inventoried once, and risks identified for them, including the nine compromise types from ISO 27090, sit in the same risk register as the rest of your information security risks, with the controls that treat them linked to policies and evidence.
For the AI management system, Kertos provides pre-mapped ISO 42001 controls, a gap analysis, and an AI risk library aligned with the EU AI Act and ISO/IEC 23894. Kertos's certified experts help you decide which threats apply to your systems and how to document the treatment so it holds up in an audit. If you want to see how an AI feature fits into an existing ISMS, book a demo and bring one of your AI use cases along.
Frequently asked questions
What is ISO/IEC 27090?
ISO/IEC 27090:2026 is an international standard that gives guidance on understanding, detecting, and mitigating security threats specific to AI systems throughout their life cycle. It was published on 14 October 2026 by ISO/IEC JTC 1/SC 27 and runs to 56 pages. It applies to organizations of any size that develop or use AI systems.
Can you get ISO 27090 certified?
No. ISO 27090 is a guidance document, not a management system standard, so there is no certification against it. Organizations use it as a source of threats and mitigations for the risk assessment in an ISO 27001 ISMS or an ISO 42001 AI management system, both of which can be certified.
What is the difference between ISO 27090 and ISO 42001?
ISO 42001 sets requirements for an AI management system: policy, roles, impact assessments, and controls over the AI life cycle, and it can be certified. ISO 27090 describes nine types of attack on AI systems, such as data poisoning and prompt injection, and the mitigations for each. An ISO 42001 certificate does not show that an AI system resists those attacks.
Does ISO 27001 cover AI security?
Partly. ISO 27001 controls such as access control, supplier management, and secure development apply to AI systems, but its Annex A does not name AI-specific attacks like model inversion or prompt injection. Because clause 6.1.3 allows controls from any source, companies can add ISO 27090 threats to their risk assessment and cite the standard in their Statement of Applicability.
Is ISO 27090 required under the EU AI Act?
No. ISO 27090 is not a harmonised standard under the EU AI Act, so applying it does not create a presumption of conformity. It does address the threats that Article 15 requires high-risk AI systems to resist, including data poisoning, model poisoning, and adversarial examples, which makes it a useful reference ahead of the high-risk obligations applying from 2 December 2027.
