I have just learned that ISO/IEC 27090 is finally published (14 October 2026).
What is it?
Its full title is ISO/IEC 27090:2026, Cybersecurity, Artificial intelligence (AI), Addressing security threats and compromises to AI systems. In plain words: the threats and compromises that are specific to artificial intelligence systems.
It is 56 pages. It comes from the same committee as ISO/IEC 27001, subcommittee SC 27.
ISO publishes it as an international standard. It is guidance, not a requirements standard for a management system. Nobody is going to be “certified to 27090”. The certifications that still matter are ISO/IEC 27001 for information security and ISO/IEC 42001 for the AI management system.
You can have a well-configured firewall, multi-factor authentication everywhere, up-to-date servers and a certified information security management system (ISMS). Your AI system can still be exposed, because the attack no longer aims at the server. It aims at the training data, the model, the questions people ask it, or what it answers.
The nine threats
| Threat | What happens | Mainly affected |
|---|---|---|
| Data poisoning | Malicious data slipped into training changes how the model will behave later. | Integrity |
| Evasion attack | A slightly altered input fools the model, for example to slip past a detection filter. | Integrity |
| Membership inference | The model’s answers reveal whether a person’s data was used to train it. | Confidentiality |
| Model exfiltration | Repeated queries make it possible to recreate a proprietary model. | Confidentiality |
| Model inversion | The answers make it possible to reconstruct part of the training data. | Confidentiality |
| Direct model poisoning | The model itself is altered or replaced, for example by a version that contains a backdoor. | Integrity |
| Sensitive model output | The model discloses confidential information it learned or received. | Confidentiality |
| Prompt injection | A malicious instruction, typed directly or hidden in a document, an email or a web page, hijacks the model. | Integrity and confidentiality |
| Output contains injection attacks | The model produces code or content that attacks the system displaying or running it. | Integrity |
Annex B adds three more: direct theft of the model, leakage of the training data, and leakage of the model inputs, meaning what you send to it.
Two of the nine do not even need an attacker. Sensitive output and injection through the output can happen by accident, in ordinary use.
Prompt injection is only one threat out of nine. If your AI risk analysis stops there, you are leaving out the data, the model and the supply chain.
Most of the measures are not new either. Limiting the number of queries, logging, validating inputs, treating the model’s answers as untrusted and protecting the development environment is ordinary application security applied to a new subject.
Where it sits next to 27001 and 42001
27001 = the frame. Risk management, governance, audit and continual improvement.
42001 = AI governance. Responsibilities, risks and consequences for the people affected.
27090 = the technical detail of attacks against the AI system.
It replaces nothing. It adds to what you already have. The standard itself classifies each threat by the asset affected and the property compromised (confidentiality, integrity, availability). If you have an ISMS, this goes straight into your risk register. If you are on a 42001 path, it points to specific 42001 controls, notably on human oversight. The rest of that family is in Around ISO 42001.
Who is it for?
The standard is aimed at any organization, whatever its size, that develops or uses AI systems.
Read literally, that means everyone. Your bookkeeper who uses Copilot “uses an AI system”.
Still, the value of the standard for you depends on one question. Do you control any part of the system? The data, the model, the integration, the access, or what happens to the answers?
If the only things you control are which tool you chose and who may use it, the standard has little to offer you. Model security belongs to the provider. Your work is somewhere else.
When should you use it?
Before you read 56 pages, ask these questions for each AI tool you use or build.
- Does the AI read content that comes from outside, such as incoming email, web pages or client documents?
- Can it act without you, such as sending, editing, paying or deleting?
- Can it retrieve more information than the person using it is allowed to see?
- Do you send personal or confidential information to a cloud provider to make it work?
- Is its answer displayed or executed by another system?
- Can its answer leave without a person rereading it?
- Have you trained or adjusted the model with your own data?
One yes and the standard is for you. Otherwise, you can wait.
Here are a few situations.
Your employees use ChatGPT or Claude in the browser
Technically, you use an AI system. In practice, the standard has little to offer you. The main risk is what your employees paste into the tool, which the standard calls model input leakage.
Your priority is an AI use policy, plans where your data is not used to train the model, clear rules on what may go in, and training. This is the same reasoning as the 42001 controls that do not apply when an SMB only uses ChatGPT.
Copilot drafts a reply to your email
Yes, the standard applies to you. The incoming email is external content you do not control. If someone hides an instruction in it, that is indirect prompt injection (6.9).
The EchoLeak case, published in June 2025, shows it clearly. Researchers at Aim Security showed that a simple email containing hidden instructions could lead Microsoft 365 Copilot to pull internal data and send it out of the company. The employee had nothing to click. They only had to ask Copilot an ordinary question. Microsoft fixed the flaw (CVE-2025-32711) and nothing indicates it was exploited. Still, the scenario is exactly the one the standard describes. I already went into more detail in the article on prompt injection.
The draft can contain information drawn from your other emails or documents. The standard uses the example of a consulting firm that gives its AI every report it has produced (B.7). What the AI can retrieve has to match what the person is allowed to see.
Watch out: Copilot connected to SharePoint sees everything the user is allowed to see, including permissions that have been too broad for years. The model is not the problem: your access rights are.
A draft is a good thing. What follows is human oversight, and it becomes critical. The standard warns about the fatigue effect: after enough clicks on “Send”, people stop rereading. It uses the example of an agent connected to messaging.
You build a tool where AI analyzes information and gives you a summary
Yes, even if you train no model. The standard treats AI as a software component built into a system. You integrate a model, so you inherit its risks.
What applies to you:
- A trapped document can distort the summary (indirect prompt injection).
- The summary can reveal information from another file (sensitive output).
- If the summary is shown on a web page, it can contain code that runs (injection through the output). Treat it like user input.
- What you send to a cloud provider’s application programming interface (API) can leak (input leakage).
- The summary can be wrong and convincing. The standard talks about overreliance.
What does not apply to you, as long as you use a provider’s model without adjusting it: training poisoning, inversion, membership inference and model exfiltration. That is the provider’s job.
One point the standard makes explicit (7.6): if your tool searches a document base before summarizing (RAG, retrieval-augmented generation), that base controls the answers as much as training data does. It is protected the same way.
You offer AI to your customers
A conversational agent on your website, an API, or an AI feature in the software you sell. Model exfiltration, injection through the output and query limits apply to you directly. The standard recommends telling people that an AI is involved (6.11.3.4).
You train or adjust a model
All of clause 6 applies, plus protection of the development environment (7.6) and data provenance (6.11.4). Nobody else is going to handle these risks for you.
The link with Bill 25
Three of the nine threats can let personal information out through the model: membership inference, model inversion and sensitive output.
An unauthorized communication of personal information is a confidentiality incident under Quebec’s Bill 25. The fact that the leak goes through a model rather than a database changes nothing. You have to assess it and record it, then notify the Commission d’accès à l’information and the people concerned if there is a risk of serious injury. The plan to have before the incident is here.
A project to acquire, develop or rebuild a system that processes personal information requires a privacy impact assessment (PIA, EFVP in French). If your AI project touches personal information, these threats belong in that assessment. The detail of that duty is in PIA: the assessment to do before you sign.
In practice
If you answered yes to at least one question, here is where to start.
- Inventory your AI systems, including AI features built into software you buy. That is often where the surprise is.
- Start with ordinary security around the model: accounts, access, permissions, updates. The standard says so itself (5.1): that is often a better first investment than sophisticated controls against query attacks.
- Know where your models and your data come from, and who can change them.
- Add the AI-specific scenarios to your existing risk register. Not a second register beside the first.
- Log at least what the standard recommends (7.5): the question, the answer, the date, the time, the user and the model version. Decide who will react if something abnormal shows up.
- Then buy the standard (204 Swiss francs on the IEC webstore) for the team that builds or integrates the system.
In short, ISO/IEC 27090 is not a certification and it is not for everyone. If you only use AI tools, set rules for that use and move on. If you connect AI to your data or to your customers, this is now the reference for what your risk analysis is leaving out.
Do you know how many of your applications added an AI feature in the past year?
Want to know where you stand on this? Let’s talk.