If you operate or build AI systems, use ISO/IEC 27090 as the AI-specific threat and control layer inside your existing ISO/IEC 27001 or ISO/IEC 42001 programme, not as a separate compliance project.
Summary
ISO/IEC 27090:2026 is published guidance on AI-specific security threats. It is not certifiable. Use it to extend your ISO/IEC 27001 risk process and your ISO/IEC 42001 AI management system. Start with an AI inventory, threat models for high-impact systems, provenance records, agent permissions and test evidence. It supports, but does not by itself prove, EU AI Act Article 15 cybersecurity conformity.
ISO/IEC 27090:2026 is now a published International Standard. ISO lists it as published with a publication milestone of 14 October 2026, and it was prepared by ISO/IEC JTC 1/SC 27, the committee that handles information security. This article explains what the standard covers, what it does not do, and where it fits next to ISO/IEC 27001 and ISO/IEC 42001.
About the author
Written by Alexis Hirschhorn, trainer at Abilene Academy. Certified ISO/IEC 42001 Lead Implementer, Certified Artificial Intelligence Professional, CISSP, CISM, CISA, ISO/IEC 27001 Senior Lead Auditor and PECB Certified Trainer. About 25 years of hands-on experience in information security, cloud security and AI governance, advising multinationals, government bodies and international organisations. Profile: https://www.abileneacademy.ch/en/about/team/alexis-hirschhorn
Practitioner quotations in this article reflect Abilene Academy training experience and are not ISO positions. ISO/IEC 27090 is a published standard, and the ISO catalogue is the authority on its status and content.
Status
ISO/IEC 27090:2026, Edition 1, published October 2026. 56 pages. Guidance on security threats and compromises to AI systems. Committee: ISO/IEC JTC 1/SC 27.
Not certifiable
You cannot be certified to ISO/IEC 27090. You can use it inside a certified ISO/IEC 27001 information security management system or ISO/IEC 42001 AI management system, and show auditors and customers how you handled AI threats.
Why a security standard for AI now
Most AI systems in companies were not built by the security team. They arrive as a feature in a SaaS product, a model behind an API, an agent connected to a ticketing tool, or a coding assistant in the engineering team. Each one adds attack paths that a classic vulnerability scan does not see: poisoned training data, prompts that smuggle instructions, and model outputs that trigger something downstream.
27090 gives security teams a shared vocabulary and a threat list for these paths. It does not tell you to buy a tool. It tells you which compromises to consider, how each one shows up, how to detect it, and how to reduce it.
Shadow AI makes the inventory urgent. In a WatchGuard survey conducted in April 2026, 64% of employees said they use unauthorised AI tools for work. The sample was 684 employees at small and mid-sized organisations, and the findings are self-reported. Source: WatchGuard, 2026 Cybersecurity Hygiene Report.
What ISO/IEC 27090 is, and what it is not
The standard has a short normative framing, a main body of guidance and three informative annexes. Clause 5 covers how to apply information security to AI, including governance, zero trust principles, software engineering practices, supply chain management, threat modelling and red teaming. Clause 6 describes the types of compromise, from data poisoning to prompt injection. Clause 7 covers mitigations, including how they can conflict and how they lose effectiveness over time.
"Treat every model artefact, dataset, prompt template and tool permission as an attack surface. If it can change model behaviour or reach a downstream system, it belongs in the threat model."
Alexis Hirschhorn, trainer at Abilene Academy
How ISO/IEC 27090 fits with the standards you already use
Standard: ISO/IEC 27001:2022 (management system requirements)
Standard: ISO/IEC 27002:2022 (control guidance)
Standard: ISO/IEC 42001:2023 (AI management system requirements)
Standard: ISO/IEC 23894:2023 (AI risk management guidance)
Standard: ISO/IEC 27090:2026 (security guidance for AI)
Standard: ETSI EN 304 223 (European baseline for AI cyber requirements)
Two boundaries matter. First, 27090 is about protecting AI systems, not using AI to defend networks. Second, it does not guarantee that a system is immune to attack. Its controls reduce risk, and the residual risk still has to be owned and accepted.
The AI threats you need to understand first
Clause 6 gives each compromise a description, the failures it causes, how to detect it and how to mitigate it. The table uses plain language. The clause references come from the standard; the framework mappings are our reading and should be checked against current versions.
Threats in ISO/IEC 27090 with an example
Threat: Data poisoning
Threat: Evasion
Threat: Membership inference
Threat: Model exfiltration
Threat: Model inversion
Threat: Direct model poisoning
Threat: Sensitive model output
Threat: Prompt injection
Threat: Output contains injection attacks
Two gaps are worth knowing. The table of contents has no separate heading for jailbreaks, and agentic and tool-abuse risks are handled more briefly than in dedicated catalogues. For those, use the OWASP Top 10 for LLM Applications and the MITRE ATLAS knowledge base alongside 27090.
Why it matters now: the regulatory clock
A standard is only useful when someone is asking for the evidence. Four regimes are doing that now.
EU AI Act, Article 15
High-risk AI systems must be resilient against attempts to exploit data poisoning, model poisoning, adversarial examples and confidentiality attacks. Clause 6 of 27090 covers each of these by name. Source: Regulation (EU) 2024/1689, Article 15, and the European Commission AI Act Service Desk.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the stand-alone high-risk obligations under Annex III to 2 December 2027 and those under Annex I to 2 August 2028. The EU AI Act high-risk timeline sets out the full dates. The deferral changes when a regulator can act. It does not reduce the risk your systems carry.
NIS2 requires essential and important entities to manage supply chain and development security, and AI services fall inside those measures when they are part of the service. Manufacturers have had to report actively exploited vulnerabilities since 11 September 2026 under the Cyber Resilience Act, so a prompt injection flaw in a product that is exploited in the wild can become reportable. See CRA reporting duties for the timelines.
In Switzerland, the FDPIC has stated that the revised FADP applies directly to AI-supported processing of personal data. Membership inference, model inversion and sensitive output are therefore confidentiality failures under the data security duty, and they belong in the data protection impact assessment.
"In Switzerland, an AI feature that processes personal data is a processing activity like any other. The innovation does not remove the duty to document the purpose, data flows, security risks, retention and accountable owner."
From the threat list to evidenced controls
A useful test is whether a control leaves evidence an auditor can sample. The table shows where each threat enters the lifecycle and which 27090 control applies.
Where AI threats enter the lifecycle and which 27090 control applies
Stage: 1. Data
Stage: 2. Training
Stage: 3. Evaluation
Stage: 4. Deployment
Stage: 5. Monitoring
Stage: 6. Retirement
A maturity model for AI security controls
Do not try to implement the whole catalogue at once. Work through three stages, and treat each as a set of evidence you can show.
Maturity stages for ISO/IEC 27090 controls
Stage: Minimum
Stage: Established
Stage: Advanced
Why the inventory comes first
Shadow AI is widespread in both surveys we checked. An AI inventory must include embedded AI features, browser extensions, coding assistants and employee-selected tools, not only the models the organisation deliberately deployed.
Data exposure
In a PagerDuty survey of 1,250 office professionals at organisations with revenue of at least USD 500 million, 43% said they had entered emails or other correspondence into public AI tools, 34% had entered customer data, and 31% had entered financial information or confidential documents. Employees may already be placing customer data and confidential documents into tools outside your managed environment.
Sources for the figures above: WatchGuard, 2026 Cybersecurity Hygiene Report (April 2026 survey, self-reported); PagerDuty Shadow AI Survey (June 2026).
Worked example: an AI support agent with CRM access
This is a composite example, not a client case. Consider an AI assistant that answers customer tickets and can create notes in the CRM. It is a common setup, and it shows most of the 27090 threats in one system.
Inventory. The system is listed with its owner (the customer operations lead), its model and vendor, its data sources (ticket text, CRM records), its tools (create note, update status), and its human approvals. Embedded AI features in the ticketing platform are listed too.
Threat model. Four threats matter most: indirect prompt injection through customer emails (6.9), excessive CRM permissions for the agent (5.3, 6.11.3), sensitive output that exposes another customer's record (6.8), and tool calls that nobody logs (7.5).
Controls. The agent gets its own credential with the minimum CRM scope. Changes to customer records require human approval. Output is sanitised before it reaches the CRM interface (6.10). Tool calls are logged with the user, input and result. Rate limits apply to the endpoint (7.8). Red-team tests run quarterly, using injected email content.
Evidence an auditor would sample. The agent's credential scope in the access register. Three sampled tool-call logs, showing one approval and one refused action. The most recent red-team report with its injection test cases and remediation tickets. The change record showing when the agent's permissions were last reviewed.
Residual risk decision. Injection can still cause the agent to draft a wrong note, but it cannot change a customer record without approval and cannot read other customers' records. The owner accepts the residual risk of a wrong draft, records that decision, and sets a review date tied to the next model or permission change.
Agents and tools: where the blast radius matters
Agentic AI is where the standard is thinnest. 27090 applies zero trust to agent operations and recommends least model privilege. That is sound, but it does not give a complete list of tool-abuse scenarios. The practical questions are concrete: which tools can the agent call, with which credentials, what needs human approval, and what happens when an instruction arrives inside retrieved content. The OWASP Top 10 for LLM Applications (2025 edition) lists excessive agency as a core risk, which is the same concern: model output that can trigger tools, write data or send messages needs its permissions limited as tightly as any other service account.
"A prompt-injection classifier is a useful control, but it is not an authorisation model. Design the agent for the day the model is fooled: restrict its credentials, separate its permissions from the user's, require approval for irreversible actions, and make every tool call observable."
Alexis Hirschhorn, trainer at Abilene Academy
Agent governance
In Okta's AI Agents at Work 2026 research, 92% of executives said autonomous AI agents were already in widespread (58%) or moderate (35%) use in their organisation. 58% of executives reported an AI-related security incident or close call in the previous 12 months. Agents should not inherit broad user privileges by default. Define the agent identity, permitted tools, data scope, approval thresholds, logging and a way to stop it before deployment. These are executive survey figures, not audited incident counts.
Our Certified Artificial Intelligence Security Professional course works through this in labs: prompt injection testing, red teaming against LLM applications, and threat analysis anchored in MITRE ATLAS and the OWASP LLM Top 10. It is taught in English and French.
What real incidents teach
Four public cases show how the threats in 27090 play out. Each is summarised from the original research or vendor report, with the source linked.
Zero-click prompt injection in an enterprise assistant. Researchers at Aim Labs described a crafted email that made a Microsoft 365 Copilot-style assistant leak data from its context without user action, documented as CVE-2025-32711 and analysed in arXiv 2509.10540. The attack chained several bypasses, including a classifier evasion, a link redaction bypass and an image request to an allowed domain. Microsoft fixed it server-side. Lesson: output rendering that triggers network requests is a data path.
Malicious models on a public hub. In a JFrog blog post of 27 February 2024, the company reported around 100 malicious models on Hugging Face. One used Python pickle serialisation to open a connection to a remote address when loaded. Lesson: a model file is code. Govern it like a third-party binary, and prefer safe formats such as safetensors.
AI-orchestrated intrusion campaign. In its November 2025 report, Anthropic described an actor it assessed with high confidence as state-sponsored, which used an agentic coding tool to run reconnaissance and intrusion steps against a number of organisations, with humans involved at only a few decision points. The actor presented the work as legitimate testing to get past safeguards. Lesson: jailbreak resistance can fail, so detection and the ability to cut off access matter.
Stealing part of a production model. In arXiv 2403.06634 (ICML 2024), Carlini et al. recovered the projection matrix of production language models through their public API. Lesson: API design is a security decision. Logprobs and logit bias widen what an attacker can learn.
Vendor disclosure is uneven. A study of the disclosure policies of 264 AI vendors (arXiv 2509.06136) found that 36% provided no vulnerability disclosure channel and only 18% explicitly mentioned AI risks. Data access, authorisation and model extraction were the vulnerability types most consistently declared in scope, while jailbreaking and hallucination were most often declared out of scope. Procurement teams should ask a concrete question: what is your AI vulnerability disclosure policy, and are prompt injection, model extraction and data poisoning in scope? The study measures published policies, not vendor behaviour.
How to use 27090 inside ISO/IEC 27001 and ISO/IEC 42001
If you run a 27001 information security management system, add the AI threats to your risk register and to the justifications in your Statement of Applicability. If you run or plan a 42001 AI management system, link the AI impact assessment and the risk process to the threat catalogue. The standard points to 42001 for the management system and to 27002 for control guidance, so the three work as a set.
Auditors of a 42001 system look for traceability: from a model version, through its impact assessment, data decisions, test results and approval, to its monitoring. The ISO/IEC 42001 audit evidence guide sets out the evidence file in detail.
"Readiness is not a state you reach. It is a property of your records. If your evidence only exists because someone assembled it for the audit, you were never ready; you were prepared."
Alexis Hirschhorn, trainer at Abilene Academy
For AI systems, that means the inventory, threat model, data provenance, test results and monitoring records must be maintained as part of normal operation, not assembled before an audit. Use that principle as the test for the evidence checklist below.
- AI system inventory with owners, purposes, data sources and suppliers
- Threat model for each in-scope AI system, based on Clause 6
- Provenance and lineage records for training and fine-tuning data
- Hashes or signatures for model artefacts, and safe serialisation before loading
- Input and output handling rules for each AI feature that reaches a user or a tool
- Red-team or adversarial test report with remediation status
- Logging and rate limits for inference endpoints, with query-pattern monitoring
- Record of trade-off decisions, for example privacy against accuracy, or logging against data minimisation
Teams that want the AI inventory, threat models and evidence trail in one place often use an AI-native GRC platform such as Acuna GRC, which keeps those records linked to the controls they support.
Five questions before deployment
Ask these before any AI system goes live. Each answer should be backed by the evidence in the right-hand column.
Five questions before deployment
Question: What AI systems and embedded AI features exist?
Question: What data can the system access or generate?
Question: What can the model cause another system to do?
Question: How would you detect misuse or compromise?
Question: What evidence proves the control works?
Who should act, and what they own
Who should act first, and the evidence each role owns
Role: CISO / security lead
Role: Product and engineering
Role: AI governance lead
Role: Procurement
Role: Auditor / compliance
What 27090 does not solve
Overclaiming is the most common mistake in writing about this standard. Be clear about the limits. It does not certify an organisation. It does not create an AI Act presumption of conformity; the Article 40 presumption depends on harmonised standards cited in the Official Journal. It does not replace ISO/IEC 27001, 27002 or 42001. It does not provide a complete agent and tool-abuse control catalogue. It does not remove the need for a system-specific risk assessment and a documented residual-risk decision.
Frequently asked questions
Is ISO/IEC 27090 published?
Yes. ISO lists ISO/IEC 27090:2026 as published, Edition 1, with a publication milestone of 14 October 2026. Drafts describe a text that has since changed, so check the published version before you quote it.
Can an organisation be certified to ISO/IEC 27090?
No. It is a guidance standard and no certification scheme exists for it. Certify to ISO/IEC 27001 or ISO/IEC 42001 and use 27090 as the reference for how you handle AI threats inside that scope.
Does ISO/IEC 27090 replace the ISO/IEC 27002 controls for AI systems?
No. The standard says conventional information security controls still apply according to risk. 27090 adds the AI-specific threats and the controls that address them on top.
Does ISO/IEC 27090 cover prompt injection?
Yes. Clause 6.9 covers prompt injection, and its definition includes content incorporated into an instruction, which captures indirect injection through documents, emails and web pages. Clause 6.10 covers outputs that carry an injection payload.
Does ISO/IEC 27090 help with the EU AI Act?
It is relevant guidance for the cybersecurity expectations in Article 15 for high-risk systems. It is not a harmonised standard, so using it does not by itself create a presumption of conformity under the AI Act.
When do AI Act high-risk obligations apply now?
Under Regulation (EU) 2026/1744, obligations for Annex III high-risk systems apply from 2 December 2027, and those for Annex I systems from 2 August 2028. Transparency obligations under Article 50 have applied from 2 August 2026.
Is ISO/IEC 27090 relevant in Switzerland?
Yes. The FDPIC states that the revised FADP applies directly to AI-supported processing. The standard's guidance on privacy attacks supports the FADP's data security and impact assessment duties. Swiss firms serving EU customers also face the AI Act and the CRA.
How is ISO/IEC 27090 different from ISO/IEC 42001?
ISO/IEC 42001 sets requirements for managing AI responsibly across an organisation and is certifiable. ISO/IEC 27090 goes deeper on security threats to AI systems and how to detect and reduce them. Most organisations will use both.
Does the standard address agentic AI?
Partly. It applies zero trust to agent operations and recommends least model privilege. For tool abuse and trust between agents, add the OWASP LLM Top 10 and the MITRE ATLAS technique catalogue.
How we use this in training
In AI security and ISO/IEC 42001 sessions, we ask teams to bring one real AI feature. We map its data sources, model or vendor, tools, human approvals, logs and failure paths. The most common gap is not a missing technical control. It is an unowned AI feature embedded in an existing business system.
Where to train next
Security and SOC teams. The Certified Artificial Intelligence Security Professional course covers the attack techniques in Clause 6, the OWASP LLM Top 10 and MITRE ATLAS, with labs on prompt injection and red teaming. Alexis Hirschhorn teaches it. You can read his trainer profile.
Management system owners. The ISO/IEC 42001 Lead Implementer course covers the AI management system, and the ISO/IEC 27001 Lead Implementer course covers the information security management system that the AI threats feed into.
Risk and compliance leads. The Lead AI Risk Manager course builds the risk process that the 27090 threats plug into.
The AI governance hub lists the full training path.
Sources and verification
Standard status, structure and scope: ISO catalogue entry for ISO/IEC 27090:2026 and the ISO explainer. Clause structure and definitions: the standard's public preview, where permissible. EU AI Act Article 15: Regulation (EU) 2024/1689 and the European Commission AI Act Service Desk. AI Act timing: Regulation (EU) 2026/1744 in the Official Journal. Incidents: the sources linked above, with publication dates. Framework mappings (NIST AI 100-2e2025, OWASP LLM Top 10 2025, MITRE ATLAS) are interpretation and should be checked against the current versions.
This article is a planning summary. The standard's full text is paywalled. Check specific clause requirements against the published version before you rely on them.
