ISO/IEC 27090:2026 was published on 14 October 2026, and it closes a gap that anyone running an AI management system has been working around. It is the first international guidance devoted to the security threats that are specific to AI systems: data poisoning, model theft, prompt injection, evasion attacks, sensitive information exposure, and AI supply chain risk. Below, I explain what the standard covers, why it is guidance rather than a certification, and where it belongs inside the AI management system you already run.

It came from the other committee

ISO/IEC 27090 was developed by ISO/IEC JTC 1/SC 27, the information security committee, not SC 42, where I sit as a United States delegate on the AI standards work. That division of labor matters. SC 42 defines how you govern AI. SC 27 defines how you secure it. The two committees stayed deliberately in their lanes, which is why 27090 reads as a threat catalog rather than a management system.

What the standard covers

ISO/IEC 27090 addresses threats across the AI life cycle: the training data, the model itself, and the risks that arise during development, operation, and model updates. For each, it explains how the vulnerability can be exploited, what the consequence looks like, and which measures help.

One detail deserves attention from anyone who has already sat through an audit. Data collected while an AI system is running is often fed back into retraining. That pipeline is a poisoning route, and most organizations have never assessed it, because they treat training as a historical event rather than a continuing process.

Guidance, not a certification

You cannot certify against ISO/IEC 27090. There is no audit, no certificate, and no accredited certification body for it. That disappoints people who were hoping for another badge, and it should not. The value of this standard is content, not credential. It gives the assessments you already perform the security substance they were missing.

Three standards, three jobs

  • ISO/IEC 27001 secures your information
  • ISO/IEC 42001 governs your AI
  • ISO/IEC 27090 explains how AI gets attacked

Most organizations I work with hold the first, are implementing the second, and had nothing authoritative for the third. Until now the threat content came from vendor blogs and research papers, which is a difficult basis for a conversation with an auditor.

Where it goes in your AI management system

Clause 6 of ISO/IEC 42001 requires an AI risk assessment and an AI impact assessment. In practice the risk register is where implementations are thinnest, because the people writing it are governance professionals rather than security engineers, and the threats are unfamiliar. Prompt injection appears in nobody’s legacy risk library.

Take the threat categories in 27090 and run them against your AI systems one at a time. For each, record whether the threat applies, which control you rely on, and what evidence an auditor could inspect. That exercise alone will fill more of your register than any workshop.

The question worth settling this week

Who owns prompt injection risk in your organization, security or the AI governance committee?

In most organizations the honest answer is that nobody does. Security sees an application-layer problem belonging to whoever deployed the model. The governance committee sees a technical attack belonging to security. The space between them is where the incident happens.

ISO/IEC 27090 will not answer that question for you. What it does is make the question unavoidable, and specific enough that the answer can be written down, assigned to a named owner, and audited. That is usually the moment a governance system stops being documentation and starts being real.