ISO/IEC 27090:2026 Explained: What the New AI Security Threats Standard Covers

What ISO/IEC 27090:2026 is

ISO/IEC 27090, “Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems,” was published on 14 October 2026 by ISO/IEC JTC 1/SC 27, the joint technical committee responsible for IT security techniques. It is a first-edition, 56-page document, and its job is narrow and useful: take the security threats that are specific to AI systems — as opposed to the generic IT security threats every system already has to manage — and give organizations a structured way to identify, assess and mitigate them.

It draws its AI terminology from two existing standards, ISO/IEC 22989 (AI concepts and terminology) and ISO/IEC 23053 (framework for AI systems using machine learning), rather than defining its own vocabulary from scratch. That matters for anyone trying to map it against other standards in the same family — the terms line up by design.

What it is not

Two things worth being precise about, because both get confused in vendor marketing. First, ISO/IEC 27090:2026 is not a certifiable management-system standard — unlike ISO/IEC 42001, there is no accredited certification scheme against it, and no auditor issues a “27090 certificate.” Second, it is not a pure control-list standard either, in the sense that ISO/IEC 27002 or the sector-specific guidance standards (27010, 27011, 27017, 27019) are — ISO/IEC 27000:2026’s own category scheme classifies 27090 as a guidance-on-threats document, not a controls catalogue. It is closer to a threat intelligence reference, written so that the risk-assessment step of an existing management system has somewhere specific to point.

The nine threat types it catalogues

Clause 6 of the standard works through nine AI-specific threat types, each with its own subclause (6.2 through 6.10):

• Data poisoning — corrupting training data so the model learns the wrong thing.
• Evasion — crafting inputs specifically designed to be misclassified at inference time.
• Membership inference — determining whether a specific record was part of the training data, a privacy risk as much as a security one.
• Model exfiltration — theft of the model itself, including through repeated querying that reconstructs it.
• Model inversion — reconstructing sensitive training data from a model’s outputs.
• Direct model poisoning — tampering with model parameters or weights directly, rather than via training data.
• Sensitive model output — a model disclosing information it should not, whether from training data or from context provided at inference.
• Prompt injection — instructions smuggled into a model's input that override its intended behavior.
• Output injection — a model's output being used, downstream, in a way that lets it act as an attack vector against systems that consume it.

Clause 5: applying ordinary information security practice to AI

Before getting to AI-specific threats, Clause 5 makes the case that most of an organization’s existing information security discipline still applies and should be extended to AI systems rather than treated as a separate problem: a governance programme that explicitly covers AI, zero trust principles applied to AI components and their data flows, secure software engineering practices applied to model development, supply chain scrutiny for the data, pretrained models and libraries an AI system depends on, threat modeling exercises that include the AI-specific threats in Clause 6, and red teaming that specifically targets AI behavior rather than only the surrounding infrastructure.

How it fits with ISO/IEC 27001

For an organization running an ISO/IEC 27001 information security management system, ISO/IEC 27090:2026 is reference material for three specific places in the standard: it feeds the risk assessment (clause 6.1.2) with AI-specific threats to consider, it informs risk treatment decisions (6.1.3 b) by cataloguing mitigations that can become controls, and it gives a cross-check for the Statement of Applicability (6.1.3 c) — confirming whether AI-specific risks have been considered and, if excluded, why. It also points toward three existing ISO/IEC 27002 controls that are directly relevant to AI systems: 8.15 (logging), 8.16 (monitoring activities) and 8.27 (secure system architecture principles).

How it fits with ISO/IEC 42001

The relationship with ISO/IEC 42001, the AI management system standard, is explicitly one of feeding in rather than overlapping. ISO/IEC 27090:2026 feeds your AI risk assessment under 42001; it doesn’t replace the controls you determine through that assessment. Where 42001 asks an organization to assess and treat AI risks (its controls A.6.2.3 and A.6.2.6 are the relevant touchpoints), 27090 is the detailed threat reference that makes that assessment specific rather than generic. An organization pursuing 42001 certification gains a stronger, more defensible risk assessment by citing 27090’s threat catalogue rather than writing its own AI threat list from scratch.

What's coming next in this family

At the time of writing, a companion standard — ISO/IEC 27091, covering AI privacy risks specifically — is at the final-draft-approval stage, which suggests the SC 27 committee is building out a fuller AI security and privacy reference set rather than treating 27090 as a one-off. Organizations building their AI governance roadmap now are better served planning for that companion standard to arrive than treating 27090 as the last word on AI-specific risk guidance.

Frequently asked questions

Related reading