AI can write your policies in seconds. Attackers know that AI can also be fooled, poisoned and stolen.
Last week, ISO published a standard on exactly that: ISO/IEC 27090:2026, Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems.
In my work, I no longer see a single organization that doesn’t develop, build or use AI systems. So technically, every ISMS is affected, and this standard is relevant to almost everyone.
Here’s what’s inside, and the one thing you need to know before you add it to your ISMS.
What ISO 27090 covers
The standard is guidance on understanding, detecting and mitigating security threats that are specific to AI systems, across their whole life cycle: from training data to the deployed model.
It describes a range of attack types, among them:
Poisoning: someone manipulates training data or the model so the system learns the wrong thing.
Evasion: carefully crafted inputs make the model misjudge what it sees.
Membership inference and model inversion: an attacker works out which data the model was trained on, or reconstructs it.
Model stealing: someone copies a trained model through queries that look perfectly legitimate.
Prompt injection and output injection: attacks on AI systems in operation, through what goes in and what comes out.
For each threat, you get a short description, the possible consequences and how to detect and mitigate it.
The standard also makes clear that established security practices remain essential. AI adds risks on top of the ones you already manage. It doesn’t replace them.
The catch: it describes controls, but it’s not a control standard
ISO/IEC 27000:2026 sorts the standards around ISO 27001 into categories. One of them is standards that give guidance on controls you can determine as necessary under ISO 27001, clause 6.1.3 b). That category lists ISO/IEC 27002, 27010, 27011, 27017 and 27019. ISO 27090 isn’t on that list.
These standards are built around controls. ISO 27002 gives you 93 controls, each with attributes, a purpose and implementation guidance. The sector standards, like ISO 27017 for cloud services, add guidance for their context.
ISO 27090 is built around threats. But read the mitigations for each threat, and what you find are clearly controls:
So you can’t take ISO 27090 and tick off its “controls” in your SoA. There’s no control list to tick off. It describes mitigations, and you decide which of them you need.
o which is it? A threat catalogue for your risk assessment, or a control catalogue next to ISO 27002? The standard clearly describes controls. But in the terms of ISO 27000, it isn’t one of the standards with candidate controls, at least not today.
Where it fits in your ISMS
Remember last week’s issue on the Statement of Applicability? Your risks and your controls come first. Annex A comes second, as a safety net. Here’s how the standards around ISO 27001 connect to that sequence:
My answer: both. And the two go hand in hand. You have to know your threats to determine the controls you need. That’s why ISO 27090 connects to both clause 6 and Annex A. Use it at both points:
Risk assessment (6.1.2): use its threat descriptions to identify risks for the AI systems in your scope. This is where poisoning or model stealing get into your risk register.
Risk treatment (6.1.3 b): use its mitigations as a source for your controls. ISO 27001 explicitly allows controls to be designed as required or identified from any source.
Cross-check (6.1.3 c): compare your controls with Annex A, as always, and record them in your SoA.
Here’s what that looks like for Barvello Coffee Systems, the fictional company from my courses. It runs a customer support chatbot from a vendor.
Threat (from ISO 27090): prompt injection
Risk R-AI-01: a customer manipulates the chatbot into showing another customer’s order data
Controls in the SoA:
None of these rows says “implement ISO 27090”. Each control is specific, testable and traceable to a risk, and Annex A does what it was designed for: the cross-check.
If you’re working with ISO 42001, the logic is the same: ISO 27090 feeds your AI risk assessment. It doesn’t replace the controls you determine.
Try it this week: list the AI systems in your ISMS scope, including the ones you buy, like a chatbot on your website or a copilot in your office suite. For each one, go through the five threats above and ask two questions: could this happen to us, and which control do we already run against it? Every “yes, and none” belongs in your risk register.
This Friday: How to use ISO 27090 with ISO 27001
On Friday, October 23, at 3 PM CEST (9 AM ET), I’m going live on Substack.
We’ll look at the standards that feed your controls and how they work together:
What ISO 27001 actually requires when you determine your controls, and why Annex A is a cross-check, not the source
How ISO 27002 and the sector standards (27011, 27017, 27019) relate to ISO 27001 and to each other
How to bring ISO 27090 into the mix: from an AI threat to a risk to a control in your SoA
What I look at as an auditor when an ISMS scope includes AI systems
Bring your questions. There’s a live Q&A at the end. It’s free.
See you on Friday, Aron
P.S. Is there an AI system in your ISMS scope today? Just reply with a number: (1) yes, we build one, (2) yes, we use one from a vendor, (3) no, (4) not sure. I read every reply.