ISO/IEC 27090 is the first ISO/IEC standard dedicated to the security of artificial intelligence systems: guidance on the threats and compromises that are specific to AI, such as data poisoning, model theft, and adversarial manipulation, and how to address them across the AI lifecycle.
It is currently under publication (the final stage before release). It is guidance, not a certifiable standard like ISO/IEC 27001, but it matters because it is the first time an ISO document names the AI-specific attack surface that traditional security testing was never built to cover. This article explains what 27090 addresses and, practically, how AI red teaming tests for the threats it names.
What Is ISO/IEC 27090?
ISO/IEC 27090 is being developed by ISO/IEC JTC 1/SC 27, the same subcommittee behind the ISO 27000 information-security family. Where ISO/IEC 27001 governs an information security management system in general, 27090 focuses specifically on the security threats and compromises that arise because a system uses AI. It is aimed at any organization that develops or uses AI, of any size, and it looks at risk across the AI lifecycle rather than at a single point in time.
A short note on status: as of now the standard is “under publication,” the final production stage before formal release. Treat it as forthcoming guidance. We will update this article when it is published.
The AI Threats ISO/IEC 27090 Addresses
The value of 27090 is that it puts a recognized name to the attack surface that appears the moment a system learns, reasons, and acts. The threats it addresses are the ones that do not exist in a traditional application, including:
- Data poisoning:corrupting training or retrieval data so the model behaves the way an attacker wants.
- Model theft and extraction: stealing or reconstructing a proprietary model through its outputs or access.
- Adversarial manipulation and evasion: crafted inputs that make the model misclassify or misbehave.
- Prompt injection and model abuse: manipulating a model, or an AI agent, into ignoring its guardrails or taking unintended actions.
- Sensitive-data and model-information disclosure: leaking training data, system prompts, or PII through the model.
These are lifecycle risks. They appear in how a model is trained, how it is deployed, how it ingests untrusted input in production, and how it connects to tools and data. That is exactly why they need a dedicated standard, and dedicated testing.
Why ISO/IEC 27090 Matters Now
AI has moved from pilots into production decisions, customer-facing chatbots, and autonomous agents that take actions. Regulators and boards have noticed: the EU AI Act, the NIST AI Risk Management Framework, and the OWASP Top 10 for LLM Applications all point in the same direction. ISO/IEC 27090 adds the ISO imprimatur to that direction.
For security and governance teams, it becomes a reference point for what “securing an AI system” actually means, and a yardstick your customers and auditors will increasingly expect you to have measured against.
The gap it exposes is this: a standard can tell you which AI threats to address, but only testing tells you whether your system is actually resilient to them.
Bluefire Redteam’s verdict: ISO/IEC 27090 is a genuinely useful step, it is the first time the AI-specific attack surface gets a common, ISO-level name our clients’ boards and auditors already recognize. But a standard describes risk; it does not prove resilience. In our AI red teaming engagements for global customers, the systems that fail are almost never the ones missing a policy. They fail because a prompt injection chained through a tool call, a poisoned document in a RAG pipeline, or an over-permissioned agent turned a “safe” model into an unauthorized action. 27090 will tell you what to address. Only attacking the system tells you whether you actually have.
Where ISO/IEC 27090 Fits With NIST AI RMF, the EU AI Act, and OWASP
These frameworks are complementary, not competing. The NIST AI Risk Management Framework gives you a risk-management process. The EU AI Act sets legal obligations for high-risk and general-purpose AI. The OWASP Top 10 for LLM Applications and the emerging OWASP guidance for agentic applications give developers a concrete threat checklist. ISO/IEC 27090 sits alongside them as ISO-level guidance on AI-specific security threats. The common thread across all four is that they describe risk; proving you have mitigated it is an adversarial testing exercise.
How AI Red Teaming Tests for the Threats ISO/IEC 27090 Names
This is where a standard becomes action. AI red teaming is the adversarial assessment that proves whether your AI system actually resists the threats 27090 describes. Mapped to the threat categories above:
- Data and model poisoning: we test whether training or retrieval data can be corrupted to change model behavior.
- Model theft and extraction: we test whether the model can be reconstructed or its sensitive information extracted through its interfaces.
- Prompt injection and model abuse: our AI red teaming services probe direct and indirect prompt injection, jailbreaks, and guardrail bypass.
- Agent and tool abuse: for autonomous systems, AI agent penetration testing tests tool abuse, excessive agency, and whether an attacker can drive the agent to take unauthorized actions.
- Sensitive-data disclosure and insecure output: our LLM application penetration testing tests for data leakage and output-handling flaws across the model and the application around it.
Every engagement is human-validated and exploit-proven, and findings are mapped to the OWASP LLM Top 10, MITRE ATLAS, and the NIST AI RMF, the same threat landscape ISO/IEC 27090 formalizes.
How to Prepare for ISO/IEC 27090
- Inventory your AI. List every model, LLM feature, chatbot, and agent, and what each can access or do.
- Map the threats to your systems. Use the 27090 threat categories (and the OWASP LLM / agentic lists) to identify which apply to each system.
- Test adversarially, not just on paper. Run AI red teaming against your highest-risk systems to prove resilience, not just document controls.
- Remediate and retest. Close the findings and validate the fixes hold.
- Keep pace with change. AI systems change constantly; point-in-time testing drifts, so recurring testing matters.
ISO/IEC 27090 - FAQ
- What is ISO/IEC 27090?The first ISO/IEC standard dedicated to the security of AI systems: guidance on AI-specific threats such as data poisoning, model theft, and adversarial manipulation, and how to address them across the AI lifecycle.
- Is ISO/IEC 27090 published yet?It is currently under publication, the final stage before formal release. Treat it as forthcoming guidance and check the ISO website for the published date.
- Is ISO/IEC 27090 a certification like ISO 27001?No. It is guidance on AI security threats, not a certifiable management-system standard. You do not get "certified to 27090"; you use it to understand and address AI-specific risk.
- What threats does ISO/IEC 27090 cover?AI-specific threats including data poisoning, model theft and extraction, adversarial manipulation and evasion, prompt injection and model abuse, and sensitive-data disclosure, across the AI lifecycle.
- How is ISO/IEC 27090 different from the NIST AI RMF and the EU AI Act?They are complementary. NIST AI RMF is a risk-management process, the EU AI Act is law for high-risk and general-purpose AI, and ISO/IEC 27090 is ISO-level guidance on AI security threats. All describe risk; testing proves resilience.
- How do we test our AI against the threats in ISO/IEC 27090?Through AI red teaming: adversarial, human-validated testing of your LLMs, agents, and the applications around them, mapped to the same threat categories 27090 formalizes.