ISO/IEC 27090 Is Here: The First International Standard for AI Security Threats — What It Is, What It Isn’t, and What to Do

For the first time there is an international standard dedicated to the security of AI systems. ISO/IEC 27090:2026 — "Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems" — has been published. If you run security or AI for an organisation, here is the practical read: what it is, the one thing everyone gets wrong about it, what’s inside, and what to do this week.

Analysis for CISOs, AI leads and GRC teams. Credit to the practitioner community that surfaced the publication; this is PlayCISO’s own summary, and the authoritative text is the standard itself on the ISO catalogue (linked at the end).

The one thing to get right: 27090 is guidance, not a certificate

The most common misread already circulating is that you can "get ISO 27090 certified." You cannot. ISO/IEC 27090 is guidance — it tells your teams how to understand, detect and mitigate AI-specific security threats across the system lifecycle. It is complementary to ISO/IEC 27001 and 27002, and it adds operational depth to ISO/IEC 42001 on training, continuous validation and resistance to attacks.

The certification routes remain:

• ISO/IEC 27001 — your information security management system (ISMS). Certifiable.
• ISO/IEC 42001 — your AI management system (AIMS). Certifiable, Annex SL-structured, with an AI-specific control catalogue in Annex A. (A 42001 certificate is most meaningful from a body accredited against ISO/IEC 42006, which is still maturing — ask your certification body what they hold.)

So the mental model is simple: 27001/42001 are what you certify; 27090 is how you do the AI-security work well inside them.

What’s inside

• Security by design. Build security in from development through operation, apply Zero Trust, and use an AI Bill of Materials (AIBOM) to trace the origin of models and data. If you ship or fine-tune models and cannot name their provenance, that is the first gap. (Our AIBOM generator builds one.)
• AI-specific threats, mapped to CIA. Data poisoning, evasion, membership inference, model inversion, model theft, and prompt and output injection — each mapped to confidentiality, integrity and availability so security teams can fold them into existing risk analysis instead of treating AI as a separate universe.
• Mitigations treated as a whole. Defences interact — and some degrade model performance — so they must be evaluated together, not one at a time. Think rate limiting, logging and monitoring, malicious-input detection, and hiding confidence scores. The honest tension: several safety controls trade accuracy for resistance, so measure the net effect before you ship.
• Clear roles. Providers secure the model and its lifecycle. Deployers secure the integration: data access, API exposure, use cases and monitoring. Most breaches we cover live on the deployer side of that line — the integration, not the model weights.

Why this matters now

AI security has, until now, been a patchwork of vendor blog posts, OWASP lists and internal lore. 27090 gives the field a common vocabulary tied to the CIA triad your risk team already speaks — which is exactly what lets "AI security" stop being a separate silo and become an extension of the ISMS you already run. It will not tell you your specific controls are sufficient (it is guidance, not an audit), but it gives auditors, boards and buyers a shared reference to point at.

What to do in the first week

1. Run the threat catalogue against your risk register. For each of poisoning, evasion, membership inference, model inversion, model theft and prompt/output injection — who owns it, and is it in the register at all? Our LLM Threat-Model Generator and AI Threat-Model tool give you a fast first pass; the AI Security Verification Standard (AISVS) checker turns it into verifiable requirements.
2. Start an AI Bill of Materials. Every model, dataset and major dependency you train on or ship. Provenance is the backbone of both 27090’s "security by design" and 42001’s lifecycle controls — begin with the AIBOM generator.
3. Pick your certification path deliberately. 27001, 42001, or both — and map which clauses live where so you do not double-count. If governance is the gap, the AI Governance Board lab rehearses the decisions.
4. Evaluate mitigations together. Rate limiting, monitoring, malicious-input detection and confidence-hiding interact and can cost accuracy — measure the net effect, don’t stack them blind.

Sources & credit

• ISO catalogue — ISO/IEC 27090:2026, Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems (authoritative source; buy or preview the official text here).
• Credit to the practitioner community on LinkedIn and elsewhere who surfaced the publication and summarised its contents; this post is our own analysis of the standard’s scope and how it fits the ISO/NIST AI-assurance stack.

Published 18 Oct 2026. The standard’s own text is authoritative; where this summary and the standard differ, follow the standard.