ISO/IEC 27090:2026 explained

What the standard is

ISO/IEC 27090 is guidance on the security of AI systems: the threats that are specific to them, and what to do about those threats. Edition 1 was published in October 2026 by ISO/IEC JTC 1/SC 27, the subcommittee responsible for information security. It is guidance rather than a certifiable management-system standard, which is the first thing worth knowing, because it changes how you use it.

That distinction matters in practice. ISO/IEC 27001 certifies an information security management system. ISO/IEC 42001 certifies an AI management system. ISO/IEC 27090 does neither: there is no certificate against it. It tells you what can go wrong with an AI system and how to reduce the chance, and it expects you to act on that inside a management system you already operate.

What it covers

The substance is a catalogue of twelve threats to AI systems, with guidance on detecting and mitigating each. The threats group into three broad kinds, and the grouping is the quickest way to understand the scope.

Attacks on the data or the model itself

Poisoning the training data so the model learns the wrong thing, crafting inputs that cause a trained model to misclassify, and extracting a model that someone else paid to build. These attack the asset.

Attacks that extract information the model should not reveal

Determining whether a particular record was in the training set, reconstructing training data from the model, and causing a system to emit sensitive information in its output. These attack confidentiality through the model rather than around it.

Attacks through the interface

Instructions hidden in content that the system treats as input, and manipulation of what the system produces. These are the threats that arrived with systems that take instructions in natural language and act on them.

The standard then addresses mitigations and, importantly, how controls interact: a control that reduces one threat can increase exposure to another, and the guidance treats that interaction explicitly rather than presenting a flat checklist. The free ten-lesson course works through all twelve in detail.

Who it applies to

Responsibility is distributed across the AI life cycle, and this is where organisations most often misplace it. If you train a model you hold different obligations from an organisation that fine-tunes one, which in turn differs from one that buys a product with a model inside it. Most organisations are in the third group and assume the guidance is therefore not for them, which is the wrong conclusion: a deployer still owns the threats that reach its users and its data.

• Providers who build or train models, and carry the data and model-integrity threats most directly.
• Deployers who integrate a model into a product or process, and own the interface and output threats.
• Operators who run the system day to day, and own monitoring, logging and revalidation.
• Buyers, who own none of the engineering and all of the consequences, and whose main instrument is procurement.

Where it fits with what you already run

ISO/IEC 27090 is designed to be used inside an existing information security programme, not beside one. If you hold ISO/IEC 27001, the practical route is to treat AI systems as a class of asset in your existing inventory, run the threat catalogue against them, and extend your existing controls rather than writing a parallel set. If you are implementing ISO/IEC 42001 for AI governance, this is the security counterpart to it: 42001 asks whether you govern AI responsibly, 27090 asks whether you have secured it.

For organisations in scope of the EU AI Act, the relationship is indirect but useful: the Act imposes obligations and this guidance helps evidence that the security ones were addressed with reference to an international standard. It is not a compliance route in itself, and nothing here is legal advice.

What it does not do

• It does not certify anything. There is no ISO/IEC 27090 certificate, and any claim of one should be treated with suspicion.
• It does not replace ISO/IEC 27001 or ISO/IEC 42001; it is used within them.
• It does not cover safety, fairness or accuracy. Those are real AI risks and they belong to other standards.
• It does not tell you which products to buy, and it names no vendors.

How to start

The first task is almost always an inventory, because most organisations cannot list the AI systems in use, including the models embedded in software they already licence. Until that list exists, a threat assessment has nothing to assess. After it, the sequence is to tier the systems by consequence, run the catalogue against the highest tier first, and map what your existing controls already cover before adding anything.

The free templates below follow that order, and are free to download and use.