ISO/IEC 27090 and Security Threats to AI Systems
An AI model runs on the same hardware and in the same software and network environment as any other application. It inherits their vulnerabilities. On top of that come attacks that would not exist without the model: manipulated training data, crafted inputs, or outputs that reveal training content. ISO/IEC 27090 deals with this second group.
ISO/IEC 27090 covers the security threats and compromises that are specific to AI systems. Its full title is “Cybersecurity – Artificial Intelligence – Addressing security threats and compromises to artificial intelligence systems.” Its aim is to help organizations understand what such attacks can do across the entire lifecycle of an AI system.
The standard gives the spread of AI as its motivation. AI systems are in wide use, so attacks on them become more likely. This matters most where a malfunction can put people at risk. In those cases, the consequences can include physical or psychological harm to individuals. The standard names a second problem: there is little understanding of what goes on inside an AI system. This shows above all when someone has to explain and diagnose a specific model behavior.
Contents
- What ISO/IEC 27090 covers and who it is for
- Conventional information security remains the foundation
- The threat catalog is the core of the standard
- The attack surface extends far beyond the code
- Countermeasures do not work in isolation
- What the standard is good for and where its limits are
- Where ISO/IEC 27090 fits among related standards
What ISO/IEC 27090 covers and who it is for
In terms of content, the standard covers a narrow slice: what is specific to AI systems. Its audience, by contrast, is broad. It addresses every organization that develops or uses AI systems, regardless of size or legal form, including companies, public authorities, and non-profit organizations.
The standard gives recommendations, not requirements. The draft uses “shall” in only two places. First, you must implement the security controls of ISO/IEC 27002. Second, you must take the AI-specific attacks into account 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 also counts malfunctions such as hallucinations, not only attacks. Membership inference and model inversion therefore appear in both documents, each time from a different angle.
Conventional information security remains the foundation
Conventional attacks hit AI systems just like any other information system. You must therefore implement the controls of ISO/IEC 27002, tailored to your needs and your risk assessment. If you already work to ISO/IEC 27001, you have this foundation in place. According to the standard, however, it is not enough to protect the full machine learning (ML) lifecycle.
The standard recommends treating an AI system as a software component, not as a standalone model. It usually sits inside another system, an application, or a file anyway. If the confidentiality of your model matters to you, start with the software stack. Protecting it against direct model theft can achieve more than elaborate AI-specific techniques against exfiltration through the interface.
AI governance and zero trust
To keep your AI systems under control, the standard recommends an AI governance program with three parts. These are an inventory of AI systems and their use, a risk analysis, and controls that treat the risks you find. For implementation, it refers to ISO/IEC 42001; for the governance perspective, to ISO/IEC 38507.
The standard takes the zero trust principles from ISO/IEC 27002, clause 8.27, and applies them to the AI lifecycle with examples. Training data should enter the training pipeline only after someone has checked its origin and integrity. An AI agent should receive its permissions per action and for a limited time, not broadly and permanently.
Supply chain, threat modeling, and red teaming
The standard treats the supply chain as a topic of its own. Modern AI systems typically combine contributions from several suppliers. Who contributed which part is often harder to trace than with conventional software. Vulnerabilities can arise at any point, and their effects can be so subtle that standard security tests do not find them. The standard names pretrained models, purchased datasets, notebook platforms, and MLOps tools.
The standard recommends threat modeling as part of risk management across the entire lifecycle. The threat catalog can help you compile the scenarios. If you already perform a threat analysis and risk assessment (TARA), extend your existing method with the AI-specific attack paths instead of building a second one. Red teaming asks the same question from the other side and imitates the behavior of real attackers.
The threat catalog is the core of the standard
The catalog sorts attacks by what they hit first: the model, the training data, the test data, the model output, or the service itself. It also sorts them by whether confidentiality, integrity, or availability suffers first. For each type, it records whether it affects generative or predictive AI and whether an attacker is behind it or it happens by accident.
The overview lists twelve types. The standard covers nine of them in detail. Three more are in an informative annex because they are AI variants of conventional attacks: direct model theft, training data leakage, and input data leakage. For each of the nine types, the standard describes separately how to detect and mitigate it. For that, you need the document itself.
| Attack type | What happens | Security objective affected |
|---|---|---|
| Data poisoning | The model learns from planted data and then makes wrong decisions, either for specific triggers or across the board. With continuous learning, inputs during operation are enough | Integrity of the training data and of the outputs; for untargeted variants, also availability |
| Evasion | A minimally altered input is enough to make the model misclassify. Humans do not notice the perturbation, but the wrong decision happens anyway | Integrity of the test data and of the model output; possibly also availability of the system using the model |
| Membership inference | An attacker uses the model's responses to find out whether a specific data sample was part of the training. With personal data, this becomes a data protection incident | Confidentiality of the training data |
| Model exfiltration | The attacker queries the model many times through the interface and uses the responses to build a functionally equivalent model. The original remains untouched | Confidentiality of the model |
| Model inversion | Carefully chosen inputs and the corresponding confidence scores allow parts of the training data to be reconstructed, such as facial features from a recognition system | Confidentiality of the training data |
| Direct model poisoning | The attack targets the model itself rather than the training data, through the code of the training pipeline, a supplied model, or tampering during development or operation | Integrity of the model |
| Sensitive model output | The model outputs sensitive content contained in its earlier inputs, such as personal data from training or user prompts. This can happen in normal operation or be provoked by an attacker | Confidentiality of the training data; this is how the standard classifies the case, although user prompts can also be affected |
| Prompt injection | Instructions smuggled into the prompt, directly or through an external data source, trigger unintended behavior | Integrity of the test data and of the model output; also confidentiality of internal system information |
| Output contains injection attacks | The model returns text that contains classic injection patterns such as cross-site scripting; it becomes dangerous only in the downstream system | Not assigned by the standard (consequence: malicious code execution in the system that processes the output) |
Our own compilation based on ISO/IEC FDIS 27090:2026.
The attack surface extends far beyond the code
Taken together, the nine types show where an AI system is vulnerable. Code remains a target; the standard explicitly names manipulation of the code in the training pipeline. Then come the data, the model itself, and the interface. If you focus mainly on the perimeter and the source code, you miss these points.
For the model itself, the supplier is the critical point. A model trained with manipulation keeps its behavior even if you train or fine-tune it further. At the interface, a single external source is enough if the application inserts its text into the prompt. If that text contains a hidden instruction, the user can receive wrong or offensive responses. According to the standard, if you cannot trust the training data, you should not trust the text output either.
Model exfiltration works through valid queries and therefore looks like normal use. The same applies to membership inference. The standard therefore recommends logging model use in a way that allows incidents to be reconstructed and patterns of misuse to stand out.
Countermeasures do not work in isolation
Controls can weaken each other. A control that intervenes in training can conflict with others, increase susceptibility to other risks, and reduce model performance. In one example in the standard, training on adversarial data clearly increased susceptibility to patch attacks. Before deployment, test all controls together, not only the new one.
Their effect also fades. Model performance can degrade over time, and where training is part of a countermeasure, that countermeasure can lose effect too. The standard recommends ongoing monitoring, retraining where needed, and revalidation before the system goes back into operation.
Unlike in conventional systems, the sensitive data of AI systems usually sits in the development environment, not in production. That is where you need to start. Retrieval-augmented generation (RAG) data stores in operation need 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 an audit checklist. It is binding only in the two places mentioned above. It explicitly describes its content as examples, not as a reference, and recommends relating the threats to the specific system on a risk basis. You will not find a list to tick off.
Much depends on noticing an attack in the first place. According to the standard, controls would be neither useful nor appropriate without effective detection. It is particularly clear about data poisoning. Whether someone has poisoned data or models remains an open research question, and automated methods generally cannot reliably distinguish maliciously inserted data from harmless outliers. The standard also qualifies input filtering right away. Inputs outside the training distribution are not necessarily attacks, and attackers can design their inputs specifically to evade detection.
Some of the recommended techniques are not yet established. The standard says so itself and points out that some of them cost performance or make the system more complex. They suit only certain cases, such as protecting high-risk systems, and some assume 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. It also states plainly what can be detected today and what cannot. If you already run an information security management system (ISMS), that is enough to extend your existing processes in a targeted way. It is not enough for an AI security program that does without your own risk decisions.
Where ISO/IEC 27090 fits among related standards
The following overview lists only relationships that the standard itself establishes.
| 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; for the controls of ISO/IEC 27002, the standard uses binding language. For zero trust and secure architecture, it refers to ISO/IEC 27002, clause 8.27; for logging and monitoring, to clauses 8.15 and 8.16 |
| ISO/IEC 42001 | AI management system. Provides the implementation guidance for the AI governance program and covers the management processes for responsible AI |
| ISO/IEC 23894 | Risk management for AI. Named, alongside relevant ETSI documents, as a possible framework in which an organization embeds the security controls for the AI system |
| ISO/IEC 22989 | Normative reference. Provides the terms, concepts, and lifecycle stages to which ISO/IEC 27090 maps the attacks |
| ISO/IEC 23053 | Second normative reference. Provides the framework for ML systems, including the ML pipeline, on which ISO/IEC 27090 bases its lifecycle mapping |
| ETSI EN 304 223 | Baseline Cyber Security Requirements for AI Models and Systems. ISO/IEC 27090 refers to it in several places, including for possible supply chain controls and for threat modeling |
| ISO/IEC 27091 | Sister standard, also still at draft stage. Covers the 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 add the catalog to your existing threat analysis and treat the countermeasures as an AI-specific extension of your current controls. For how the other standards in this area fit together, see the overview of standards.
