ISO/IEC 27090 classifies attacks on AI systems, from data poisoning to prompt injection, and identifies detection and countermeasures for each type.
ISO/IEC 27090 addresses the security threats and incidents that are unique to AI systems. Its full title is “Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems”. It aims to help organizations understand the potential effects of such attacks across the entire lifecycle of an AI system.
The standard cites the widespread adoption of AI as the reason for its publication. AI systems are in broad use, which increases the likelihood of attacks. The consequences become critical wherever malfunctions can endanger people, potentially causing physical or psychological harm to individuals. The standard also identifies a second problem: a lack of understanding of what happens inside an AI system. This becomes especially apparent when someone must explain or diagnose a particular model behavior.
The document covers only a narrow slice of content: what is specific to AI systems. Its target audience is broad: any organization that develops or uses AI systems, regardless of size or legal form, including companies, public authorities, and non-profit organizations.
The standard provides recommendations, not mandates. It becomes binding in only two places, where the draft uses “shall”. First, you must implement security measures according to ISO/IEC 27002. Second, you must consider AI‑specific attacks across the entire lifecycle.
The sister standard ISO/IEC 27091 comes from the same committee but has a different focus. ISO/IEC 27090 asks how someone can attack an AI system. ISO/IEC 27091 asks about privacy risks and includes misbehaviors such as hallucinations, not only attacks. Membership inference and model inversion therefore appear in both documents, each from a different perspective.
Classical information security remains the foundation
Conventional attacks hit AI systems just like any other information system. Therefore, you should implement the measures from ISO/IEC 27002, tailored to your needs and risk assessment. If you already operate under ISO/IEC 27001, you have that foundation in place. However, in the standard’s view, that alone is not sufficient to fully protect the ML lifecycle.
The standard recommends treating an AI system as a software component rather than as a standalone model. Typically it is integrated into another system, an application, or a file. If the confidentiality of your model is important, it may therefore be more effective to secure the software stack first. Hardening the stack against direct model theft can yield more benefit than elaborate AI‑specific exfiltration defenses at the interface.
AI governance and zero trust
To enable control of your AI systems, the standard recommends an AI governance program with three parts: an inventory of AI systems and their uses, a risk analysis, and measures to manage the identified risks. For implementation it refers to ISO/IEC 42001 and for the governance perspective to ISO/IEC 38507.
It adopts the zero trust principles from ISO/IEC 27002, section 8.27, and applies them to the AI lifecycle with examples. Training data should enter the training pipeline only after someone has verified their provenance and integrity. An AI agent should receive rights for each action on a time‑limited basis, not broad and permanent privileges.
Supply chain, threat modelling and red teaming
The standard treats the supply chain as a distinct topic. Modern AI systems typically combine contributions from multiple suppliers. It is often harder to trace who supplied which component than in classic software. Vulnerabilities can arise at any point and can be so subtle that standard security tests do not detect them. The standard specifically mentions pretrained models, purchased datasets, notebook platforms, and MLOps tools.
Threat modelling is recommended as part of risk management throughout the lifecycle. The threat catalogue can help assemble the scenarios. If you already carry out threat and risk analyses, extend your existing process to include AI‑specific attack vectors rather than building a separate one. Red teaming asks the same question from the attacker’s perspective and emulates real attacker behavior.
The threat catalogue is the core of the standard
The catalogue sorts attacks by what is hit first: the model, the training data, the test data, the model output, or the service itself. It then classifies whether confidentiality, integrity, or availability is affected. It also records whether a type affects generative or predictive AI and whether an attacker is intentional or the case arises accidentally.
The overview lists twelve types. Nine of them are treated in detail in the standard. Three others are in an informative annex because they are AI manifestations of conventional attacks: direct model theft, leakage of training data, and leakage of input data. For each of the nine types, the standard separately describes how to detect and mitigate it. For that you need the document itself.
| Attack type | What happens | Affected security objective |
|---|---|---|
| Data Poisoning | The model learns from injected data and subsequently makes incorrect decisions, either targeted for specific triggers or broadly. For continuous learning, inputs during operation can suffice | Integrity of training data and outputs; for untargeted variants, also availability |
| Evasion | A minimally altered input is enough for the model to misclassify. The change remains inconspicuous to humans, but the misdecision still occurs | Integrity of test data and model output; possibly also availability of the deploying system |
| Membership Inference | An attacker learns via the model’s responses whether a specific data sample was in the training set. For personal data, this becomes a data protection incident | Confidentiality of training data |
| Model Exfiltration | The attacker queries the model repeatedly via the interface and reconstructs a functionally equivalent model from the responses. The original remains untouched | Confidentiality of the model |
| Model Inversion | Targeted inputs and associated confidence values can be used to reconstruct parts of the training data, e.g., facial features from a recognition system | Confidentiality of training data |
| Direct Model Poisoning | The attack targets the model itself rather than the training data, e.g., via the training pipeline code, a supplied model, or tampering during development or operation | Integrity of the model |
| Sensitive Model Output | The model emits sensitive content that was present in earlier inputs, such as personal data from the training set or user prompts. This can happen in normal operation or be provoked by an attacker | Confidentiality of training data; the standard classifies the case this way, although user prompts can also be affected |
| Prompt Injection | Injected instructions in the prompt, directly or via an external data source, trigger unintended behavior | Integrity of test data and model output, additionally confidentiality of internal system information |
| Output contains injection attacks | The model produces text that contains classic injection patterns such as cross‑site scripting; this becomes dangerous only in downstream systems | Not assigned by the standard (consequence: execution of malicious code in the downstream system) |
Own compilation based on ISO/IEC FDIS 27090:2026.
The attack surface goes far beyond code
The nine types together show where an AI system is vulnerable. Code remains a target — the standard explicitly names manipulation of the training‑pipeline code. Additionally, data, the model itself, and the interface are attack surfaces. Those who focus primarily on perimeter and source code may overlook these areas.
The supplier is the critical point for the model itself. A maliciously trained supplied model retains its behavior even if you further train or fine‑tune it. At the interface, a single external source whose text the application incorporates into the prompt can be sufficient. If that text contains an invisible instruction, the user may receive incorrect or offensive responses. If you cannot trust your training data, the standard therefore recommends not trusting text output either.
Model exfiltration proceeds via valid queries and therefore looks like normal use; membership inference does too. The standard therefore recommends logging model usage so incidents can be reconstructed and misuse patterns detected.
Countermeasures do not act in isolation
Measures can undermine each other. If one affects training, it can conflict with others, increase susceptibility to other risks, and reduce model performance. In an example from the standard, training on adversarial data significantly increased susceptibility to patch attacks. Therefore, evaluate all measures together before deployment, not the new one in isolation.
Their effectiveness also decays. Model performance can degrade over time, and where training is part of the countermeasure, its effect can wane as well. The standard recommends continuous monitoring, retraining when needed, and revalidation before returning a system to service.
Unlike classic systems, sensitive data for AI often resides in the development environment rather than in production. That is where you must focus, and RAG data in production requires the same protection as training data.
What the standard is good for and where its limits are
The standard provides orientation, but it is not a checklist. It is binding only in the two places mentioned. It explicitly describes its examples as illustrative rather than normative and recommends that threats be related to each specific system based on risk. You will not find a tick‑box list here.
Much depends on whether an attack is noticed at all. Without effective detection, measures would, in the standard’s view, be neither useful nor appropriate. This is particularly clear for data poisoning. Whether data or models have been poisoned remains an open research field, and automated methods typically cannot reliably distinguish maliciously inserted data from harmless outliers. Input filtering also tempers the standard: inputs outside the training distribution are not necessarily attacks, and attackers can craft inputs to evade detection.
Some recommended procedures have not yet become mainstream. The standard says so and notes that some of these measures have performance costs or make the system more complex. They are suitable only in certain cases, for example to protect high‑risk systems, and sometimes require an already mature security practice.
The value of the standard lies elsewhere. It gives you a common language for AI‑specific threats and a framework for your own threat analysis. And it states plainly what can be detected today and what cannot. If you already operate an ISMS, that is enough to extend existing procedures in a targeted way. For an AI security program that avoids its own risk decisions, it is not sufficient.
How ISO/IEC 27090 fits into the standards landscape
The following overview lists only references the standard itself makes.
| Standard | Role in relation to ISO/IEC 27090 |
|---|---|
| ISO/IEC 27001 and ISO/IEC 27002 | Foundation. The introduction recommends following the security practices established there; the standard makes the measures from ISO/IEC 27002 binding. For zero trust and secure architecture it refers to ISO/IEC 27002, section 8.27; for logging and monitoring to sections 8.15 and 8.16 |
| ISO/IEC 42001 | AI management system. Provides implementation guidance for the AI governance program and addresses management processes for responsible AI |
| ISO/IEC 23894 | Risk management for AI. Cited alongside relevant ETSI documents as a possible framework into which an organization can embed security measures for the AI system |
| ISO/IEC 22989 | Normative reference. Provides terms, concepts, and the lifecycle phases that ISO/IEC 27090 maps the attacks to |
| ISO/IEC 23053 | Second normative reference. Provides the framework for ML systems including the ML pipeline that underpins ISO/IEC 27090’s lifecycle mapping |
| ETSI EN 304 223 | Baseline Cyber Security Requirements for AI Models and Systems. ISO/IEC 27090 refers to this document at several points, including for possible supply‑chain measures and for threat modelling |
| ISO/IEC 27091 | Sister standard, also still in draft. Addresses privacy risks of AI systems; ISO/IEC 27090 refers to it for AI‑specific privacy aspects |
You do not need to build a second security organization for this. You can incorporate the catalogue into your existing threat analysis and treat the countermeasures as AI‑specific complements to your existing controls. For how the other standards in this area fit together, see the overview to standards and norms.
