ISO/IEC 27090 in Ten Minutes: What the New AI Security Standard Asks of You
The first international standard on security threats to AI systems, explained in ten minutes: what it is, what it is not, the twelve threats, how it fits ISO/IEC 27001, and where to start.
Published 2026-10-19 · By Shahzad Asghar
ISO/IEC 27090:2026 was published on 14 October 2026. It is the first international standard written specifically about security threats to artificial intelligence systems: not the servers and networks around a model, which ISO/IEC 27001 already covers, but the model itself, the data it learned from, the prompts it receives and the output it produces. I obtained the standard the week it appeared, read it clause by clause, and turned it into a free ten-lesson course and a set of implementation templates. This post is the ten-minute version: what the standard is, what it is not, what it asks of you, and where to start.
Minute one: what it is
The full title is "Cybersecurity, Artificial intelligence (AI), Addressing security threats and compromises to AI systems". It was produced by ISO/IEC JTC 1/SC 27, the committee responsible for the ISO/IEC 27000 family, and runs to 56 pages in its first edition.
It is a guidance standard. It describes threats, their consequences across the AI life cycle, and the ways to detect and mitigate them. It contains recommendations rather than auditable requirements, so there is no certificate for it. Its two normative references are ISO/IEC 22989:2022, which defines AI vocabulary, and ISO/IEC 23053:2022, the framework for AI systems that use machine learning. If your organisation already runs an information security management system, 27090 slots into it as the AI-specific layer.
Minute two: what it is not
Three things people assume about 27090 are wrong.
It is not a certification. You certify against ISO/IEC 27001, and you may add ISO/IEC 42001 for an AI management system. 27090 tells those systems what AI-specific threats to assess and treat.
It is not a law, and it gives no presumption of conformity with the EU AI Act or the Cyber Resilience Act. Following it will make a regulatory conversation easier because you will have a threat catalogue, an assessment per system and evidence of controls, but the legal obligations sit elsewhere.
It is not a privacy standard. A companion document, ISO/IEC 27091, is in development for privacy in AI systems. 27090 is about confidentiality, integrity and availability.
Minute three: how it is organised
The body of the standard has three working clauses and two annexes that matter.
| Part | What it does |
|---|---|
| Clause 5 | Applies information security concepts to AI: which assets exist (training data, model, inputs, outputs, the serving system) and what confidentiality, integrity and availability mean for each |
| Clause 6 | The threat catalogue: nine threats described in detail, each with its consequences, how to detect it and how to mitigate it |
| Clause 7 | Mitigation principles, including how controls interact with each other and how to keep them effective as the system and the attacks change |
| Annex A | Maps each attack to the stage of the AI life cycle in which it occurs and the asset it hits first |
| Annex B | Conventional attacks in their AI form: model theft, leakage of training data, leakage of input data |
The structure is deliberate. Clause 5 gives you the vocabulary, clause 6 the risks, clause 7 the treatments, and the annexes the mapping that lets a security team place each risk in an existing programme.
Minutes four and five: the twelve threats
This is the heart of the standard and the part worth memorising. Nine threats are described in detail in clause 6 and three more in Annex B.
| # | Threat | What is hit first | Security objective |
|---|---|---|---|
| 1 | Data poisoning | Training data | Integrity |
| 2 | Evasion | Model | Integrity |
| 3 | Membership inference | Training data, through the model | Confidentiality |
| 4 | Model inversion | Training data, through the model | Confidentiality |
| 5 | Model exfiltration | Model | Confidentiality |
| 6 | Direct model poisoning | Model | Integrity |
| 7 | Sensitive model output | Output | Confidentiality |
| 8 | Prompt injection | Service and input | Integrity |
| 9 | Output containing injection attacks | Output | Integrity of downstream systems |
| B1 | Direct model theft | Model | Confidentiality |
| B2 | Leakage of training data | Training data | Confidentiality |
| B3 | Leakage of input data | Input | Confidentiality |
A few of these deserve a sentence each, because they are the ones a non-specialist has usually not met.
Data poisoning corrupts the model before it exists, by tampering with what it learns from. Evasion crafts an input that a trained model misreads. Membership inference and model inversion both pull information about the training data back out of a deployed model, one by asking whether a record was in the set, the other by reconstructing it. Prompt injection hides instructions inside content a language model reads, so the model does what the attacker wrote rather than what the operator intended. Output containing injection attacks is the mirror image: the model emits text that a downstream system executes, such as a script or a database command.
The course gives each threat its own treatment, with detection and mitigation: see the lessons on poisoning, evasion and model theft, inference and inversion and prompt injection and output attacks.
Minute six: the life cycle and who is responsible
27090 does not treat an AI system as a product that is secured once. It follows the life-cycle stages defined in ISO/IEC 22989, from inception through design, data preparation, training, verification, deployment and operation to retirement, and Annex A places each attack in the stage where it occurs.
That matters because responsibility is split. The organisation that builds a model, the provider, is responsible for the robustness of the model, the integrity of its training data and documentation of its limits. The organisation that deploys it is responsible for integration security, access control, monitoring and acceptance. Most organisations are both: they build some systems and buy others, including AI features inside ordinary software. The standard's practical demand is that every system has a named owner for each responsibility, which is why an inventory is the first step.
Minute seven: mitigations, and why they interact
Clause 7 is shorter than clause 6 but more subtle. Its point is that controls for AI systems interact. A rate limit on an inference endpoint slows model extraction but does nothing for prompt injection. Input validation catches some injections but can degrade a model's usefulness if it is too strict. Logging with the model version and the prompt template version is what lets you tell a change in behaviour from an attack, so almost every other control depends on it.
The controls that address the most likely attacks for the least effort are the ones to adopt first: provenance checks on training and retrieval data, input filtering and output checks around language models, rate and output limits on endpoints, logging that records model and template versions with every request, and human review where the output has consequences. The standard also expects controls to be revalidated after any change to the model, the data or the surrounding system, because an attack that failed against last month's build may succeed against this one.
Minute eight: fitting it into ISO/IEC 27001
If you already run an ISO/IEC 27001 programme, you do not need a second one. 27090 is applied by extending what exists.
The risk assessment gains AI assets: the model, the training data, the retrieval corpus, the prompts and the outputs. Each system is assessed against the twelve threats rather than against generic threats. The gaps are mapped to ISO/IEC 27002:2022 controls, and most of them already exist in the programme and only need their scope widened: asset inventory, access control, logging, monitoring, supplier relationships, secure development, change management. The result is an evidence package an auditor already knows how to read.
Template 3 in the implementation pack does this mapping row by row.
Minute nine: where to start
The order that works is the order the templates follow.
- Inventory. List every AI system and AI feature, including those inside purchased software. Give each a business owner, a technical owner and a risk tier: high where personal or confidential data, external exposure or decisions about people or money are involved.
- Assess. Run a threat assessment workshop on the highest-tier system first, scoring each of the twelve threats for likelihood and impact and recording existing controls and gaps.
- Close gaps. Carry the treatments into a control mapping against ISO/IEC 27002, with evidence and owners, and track the coverage percentage.
- Govern. Adopt a short AI security policy with a responsibility matrix, so the roles above survive staff changes.
All four documents, plus an owner nomination form, a workshop agenda and a purchase request for the standard, are free to download in Excel, Word and PDF on the templates page.
Minute ten: should you buy it?
Yes, if you are implementing it. This post and the course summarise the standard; they do not reproduce it, because the text is copyrighted and sold through the ISO Store and national standards bodies. An implementation team needs the clause wording, Annex A and Annex B to finalise its templates and to answer an auditor's question about where a control came from. For everyone else, the course covers what you need to understand the standard and ask the right questions of the people who implement it.
For the broader picture of where AI exposure sits in an organisation and what evidence an assurance review should ask for, see AI security and assurance. For the governance structure that 27090's threat work feeds, see the NIST AI RMF playbook.
Frequently asked questions
What is ISO/IEC 27090?
ISO/IEC 27090:2026 is an international standard, published on 14 October 2026 by ISO/IEC JTC 1/SC 27, that addresses security threats and compromises specific to artificial intelligence systems. It describes the consequences of those threats across the AI life cycle and explains how to detect and mitigate them. It is guidance, not a certification standard.
Can an organisation be certified against ISO/IEC 27090?
No. ISO/IEC 27090 contains recommendations rather than auditable requirements, so there is no certification scheme for it. Organisations certify against ISO/IEC 27001 and may add ISO/IEC 42001 for an AI management system; 27090 supplies the AI-specific threats and mitigations those systems should cover.
What are the twelve threats in ISO/IEC 27090?
Nine are described in clause 6: data poisoning, evasion, membership inference, model inversion, model exfiltration, direct model poisoning, sensitive model output, prompt injection and output containing injection attacks. Three conventional attacks in their AI form appear in Annex B: direct model theft, leakage of training data and leakage of input data.
How does ISO/IEC 27090 relate to ISO/IEC 27001 and 27002?
It is applied inside an existing ISO/IEC 27001 programme. The risk assessment is extended with AI assets and the twelve threats, and the gaps are mapped to ISO/IEC 27002:2022 controls, most of which already exist and only need wider scope.
Does ISO/IEC 27090 help with the EU AI Act?
Indirectly. The standard gives no presumption of conformity with the EU AI Act or the Cyber Resilience Act, but a threat catalogue, a per-system assessment and evidence of controls make the security parts of those obligations far easier to demonstrate.
Where can I learn ISO/IEC 27090 in more depth for free?
The ISO/IEC 27090 course on this site covers the standard in ten lessons with a quiz after each and a certificate at the end, and the templates page provides the inventory register, threat and risk assessment, control gap analysis and security policy in editable form.
Written by Shahzad Asghar — Senior IT Strategy and Portfolio Officer at UNRWA, with 20+ years building AI and data systems across UNHCR, UNICEF, and UNOCHA. His team built UNHCR’s first global IVR appointment system, serving 700,000+ refugees. He created the Last-Mile AI Framework. Read more about this UN AI expert