ISO/IEC 27090 is out: how the new AI security standard fits with ISO/IEC 42001

On 14 October 2026, ISO and IEC published ISO/IEC 27090, the first international standard in the 27000 family written specifically about attacks on AI systems. Within a day, the same question started appearing in security and governance teams: if we already run, or plan, an AI management system under ISO/IEC 42001, what does 27090 add?

The short answer: they do different jobs. ISO/IEC 42001 tells an organisation how to govern AI. ISO/IEC 27090 explains how AI systems get attacked and what to do about it. One is the management system; the other is security guidance that feeds it.

What ISO/IEC 27090 is

ISO/IEC 27090:2026 is a guidance document from the committee that maintains ISO/IEC 27001 and 27002. It is 56 pages and applies to any organisation that builds or uses AI, whatever its size or sector, and not only to generative AI.

Three points matter most:

It is guidance, not requirements. There is nothing to certify against. It informs decisions; it does not set pass/fail criteria.

It protects AI, it does not use AI. The subject is the security of AI systems themselves, not AI-powered security tools.

It builds on existing security practice. Conventional controls (access management, secure development, supplier security, logging) still apply. 27090 adds the threats those controls were not designed for.

The threats it covers, in plain terms

AI systems can be attacked through their data, their model and their inputs and outputs. The standard brings these together across the life cycle:

Data poisoning: corrupting training data so the model learns the wrong behaviour, or a hidden trigger.

Model theft: copying a model by sending it many ordinary-looking queries and learning from the answers.

Evasion: crafting inputs that push the model to a wrong decision at run time.

Training-data exposure: working out whether a record was in the training set, or reconstructing sensitive training data from outputs.

Input and output attacks: prompt injection, outputs that leak sensitive information, and outputs that carry an attack into the next system.

Two ideas stand out. First, legitimate access is not enough protection: model theft can look like normal use, so detection matters as much as access control. Second, retraining reopens the door: data collected in operation often becomes tomorrow's training data, so poisoning is not only a development-time risk.

What ISO/IEC 42001 is

ISO/IEC 42001:2023 sets requirements for an AI management system. It follows the same structure as ISO/IEC 27001: context, leadership, planning, support, operation, performance evaluation and improvement, plus an annex of AI controls. It is certifiable.

Its scope is wider than security. A 42001 system has to deal with how AI affects people and society, transparency, data quality, accountability and the full AI life cycle. Security is one of many risk areas inside it.

Side by side

The last row is the useful one. 27090 relates to 42001 much as 27002 relates to 27001: the management system says you must assess and treat risk; the guidance helps you know what the risks are and what good treatment looks like.

Where they meet

Risk assessment (42001 clause 6.1). A 42001 AI risk assessment needs a realistic list of what can go wrong. For security, 27090's threat categories are that list. Use them as the security lens of the assessment, so poisoning, model theft, evasion, data exposure and prompt injection are each considered for every AI system in scope.

Risk treatment and the statement of applicability. 42001 asks you to choose controls and justify them. Start with the information security controls you already run under ISO/IEC 27001, then add AI-specific measures where 27090 shows a gap: provenance checks on training data, rate limits and monitoring on model queries, output filtering, and adversarial testing before release.

Operation and change (42001 clause 8). 27090's point about retraining belongs in your change process: treat every retraining or model update as a change that needs the same data checks as the first release.

Monitoring (42001 clause 9). 27090 stresses logging and detection because some AI attacks are hard to prevent. Make suspicious query patterns and unexpected model behaviour measurable, and report them in the 42001 management review.

Three misreadings to avoid

1. "27090 is a new certificate." It is not. Certification stays with 42001 (AI management) and 27001 (information security).

2. "Our 42001 system already covers AI security." It requires you to consider security risk, but it does not describe the attack techniques. Without a threat reference, AI security risks tend to be assessed in generic terms.

3. "This is only for teams building models." The standard applies to organisations that use AI too, including AI bought from suppliers. Procurement and supplier assessments need the same threat lens.

Where to start this quarter

1. List every AI system you build or use, including AI features inside supplier products.

2. Map where data and models come from and how they change in operation and retraining.

3. Add the 27090 threat categories to your AI risk assessment (or your ISO/IEC 27001 risk register if 42001 is not in place yet).

4. Check existing controls first, then record the AI-specific gaps and owners.

5. Decide how you would notice an attack: what is logged, who watches it, who responds.

6. Put security, data, AI development and procurement in one room for the first assessment. Each sees a different part of the attack surface.

Takeaway

ISO/IEC 42001 is the system that makes an organisation accountable for its AI. ISO/IEC 27090 is the security knowledge that makes the security part of that system specific. Teams already certified to ISO/IEC 27001 have most of the foundation; 27090 shows where AI needs more.

For teams without 42001 yet, step 3 lands in the ISO/IEC 27001 risk register and Statement of Applicability. Both are in the free ISMS Starter Kit for ISO/IEC 27001:2022, with no sign-up.