ISO 27090: What the New AI Security Standard Asks You to Do

ISO 27090 is the ISO/IEC guidance on the security threats that are specific to AI systems: poisoned training data, adversarial inputs, prompt injection, extraction of a model or its training data, and the controls that detect and limit them. Its first edition is ISO/IEC 27090:2026.

This guide explains what the standard actually asks of you, what it does not, how it is organised, and a practical order for putting it in place. It is written for the people who will implement it: security leads, ML engineers and the compliance owners who have to evidence it.

What this guide covers

• What ISO 27090 is, and what it is not
• How the standard is structured
• The threats ISO 27090 covers
• What sets it apart from other AI security guidance
• How to implement ISO 27090 in six phases
• How ISO 27090 relates to ISO 27001, ISO 42001 and the EU AI Act
• Frequently asked questions
• Putting ISO 27090 into practice

What ISO 27090 is, and what it is not

The full title is Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. It comes from the same ISO/IEC subcommittee that maintains ISO/IEC 27001 and 27002, and it applies to any organisation that develops or uses AI, whatever its size or sector.

Three facts shape how you should treat it.

• It is guidance, not a management system. Apart from two requirements in clause 5.1, it is written as recommendations. There is no certification scheme for it, and nobody can certify you against it. Certification stays with ISO/IEC 27001 for information security and ISO/IEC 42001 for AI management.
• It adds to conventional security, it does not replace it. An AI system is still software on infrastructure. The standard is explicit that ordinary information security controls apply first, and that securing the software stack can be a more efficient starting point than an AI-specific defence.
• It is not limited to generative AI. Most of the threats apply to predictive models too: fraud scoring, image classification, recommendation, malware detection.

The two requirements in 5.1 are worth knowing precisely, because they are the only things the standard says you shall do. You apply conventional controls such as those in ISO/IEC 27002, chosen by need and by risk assessment. And you take the AI-specific compromise types into account at every stage of the AI system life cycle, not just at design.

How the standard is structured

After the usual scope, references and definitions, the standard has three working clauses and three annexes. Knowing the layout makes it much easier to use.

Clause 6 is the heart of the document. Its first table groups the compromise types by the asset first hit and the security property first lost. The model, the training data, the test data, the model output and the service itself all appear as targets. That framing is useful on its own: it turns “AI risk” into a list of assets you can inventory and protect.

The threats ISO 27090 covers

The standard’s Table 2 lists twelve compromise types, each described in detail. Nine have their own subclause in clause 6; three more, which are AI-flavoured versions of familiar incidents, sit in Annex B. Its Table 1 also names jailbreaking, a form of prompt injection, and insecure code generation.

• Data poisoning: unwanted data inserted into training (or, where the system keeps learning, into its live input) to degrade it or plant behaviour.
• Evasion: inputs altered, often imperceptibly, so the model gets them wrong.
• Membership inference: working out from queries whether a given record was in the training set.
• Model exfiltration: rebuilding a model’s function by querying it with ordinary inputs.
• Model inversion: reconstructing training data from the model’s outputs.
• Direct model poisoning: tampering with the model, its code or its pipeline rather than its data.
• Sensitive model output: the model disclosing confidential material it saw.
• Prompt injection: content in the input that makes the system act against its builders’ intent, jailbreaking included.
• Output containing injection attacks: generated output that attacks whatever processes it, such as cross-site scripting.
• Direct model theft, training data leaks and model input leaks (Annex B).

For each one, ISO 27090 explains the failure it causes, how hard it is to detect, and the mitigations available, including the zero trust measures that apply. It is candid that some of those mitigations are still research-grade or cost real accuracy and performance.

What sets it apart from other AI security guidance

Two parts of the standard deserve particular attention.

Mitigations interfere with each other

Clause 7 makes a point that is easy to overlook. Defences that change how a model is trained can weaken other defences or the model’s own accuracy, and their effect decays as the model and its data change. The practical consequence is that you should test your mitigations as a portfolio, every time one changes, rather than adding them one at a time and assuming they stack. We cover this in when AI security controls work against each other.

Agents are a privilege problem

The guidance on least privilege for AI systems and agents is one of the most detailed sections in the document. Privileges belong to the agent or service that uses a model to act, not to the model. They should be scoped to the task, expire when it ends, sit inside clear delegation boundaries, and come with audit trails and the ability to step privileges down when behaviour looks wrong. See our guide to AI agent security.

How to implement ISO 27090 in six phases

Because the standard is guidance, the work is deciding which recommendations apply to you and turning those into controls you can evidence. This order avoids starting with specialised AI-specific defences before the basics exist.

1. Know your AI. Build an inventory of AI systems, including AI bought as a service and AI features inside other products, with the whole boundary of each: model, data sources, retrieval stores, tools and consumers of the output.
2. Assess. Run a gap assessment against every recommendation, and add the AI-specific compromise types to your existing information security risk assessment.
3. Baseline. Apply conventional controls to AI systems: access control, encryption, logging, environment separation, secure development. This is where the cheapest risk reduction lives.
4. Treat. For each compromise type your risk assessment rates credible, apply the matching controls, from the baseline set first and the specialist techniques only where risk justifies them. For third-party models and data, start with AI supply chain security.
5. Operate. Continuous validation against a protected test set, AI-specific detection use cases in the SOC, an incident playbook per compromise type, and agent permission reviews.
6. Improve. Red teaming, mitigation portfolio testing, and closing gaps in provenance.

How ISO 27090 relates to ISO 27001, ISO 42001 and the EU AI Act

The standard sits between two certifiable standards and alongside regulation.

• ISO/IEC 27001 runs the information security management system. ISO 27090 supplies the AI-specific risks and controls its risk assessment and Statement of Applicability need. Our ISO 27001 vs ISO 42001 comparison covers how those two divide the work.
• ISO/IEC 42001 runs the AI management system: policy, objectives, impact assessment, oversight. The 27090 guidance supplies the security depth beneath it. See ISO 27090 vs ISO 42001.
• The EU AI Act requires high-risk AI systems to be resilient against data poisoning, model poisoning, adversarial examples and confidentiality attacks under Article 15. The standard does not mention the Act, but its clause 6 lines up closely with those attack classes. The high-risk obligations now apply from 2 December 2027 for Annex III systems. Our EU AI Act Article 15 guide maps the two.

For a generative AI programme, our guide to generative AI risk assessment shows where these threats enter the risk register.

Frequently asked questions

Can my organisation be certified to ISO 27090?

No. It is guidance with only two requirements and no certification scheme. Use it to strengthen and evidence AI security inside an ISO/IEC 27001 or ISO/IEC 42001 programme, both of which can be certified.

Does ISO 27090 apply if we only use AI through a vendor’s API?

Yes, though not all of it. Prompt injection, output handling, sensitive output, agent privileges, data leakage, supplier assurance and logging all apply to systems built on a hosted model. Training-time threats such as data poisoning of your own datasets may not, and the reason should be recorded.

Is ISO 27090 only about large language models?

No. It covers AI systems generally. Several threats, such as evasion, membership inference and model inversion, apply at least as much to predictive models as to generative ones.

Where can I read the official overview?

ISO publishes an introduction, ISO/IEC 27090 explained. The standard itself is sold by ISO and national standards bodies.

Putting ISO 27090 into practice

ISO 27090 tells you what can go wrong and what helps. What it leaves to you is the policy, the risk method, a control standard per threat, test libraries, registers and the evidence an auditor or a customer’s security reviewer will ask for.

Our ISO 27090 Toolkit provides those as 61 editable documents and workbooks, organised on the standard’s own clauses, with a gap assessment pre-loaded with every recommendation and a crosswalk to ISO/IEC 27002, ISO/IEC 42001, EU AI Act Article 15, NIST AI 100-2 and the OWASP Top 10 for LLM Applications. Whether you use it or build your own, start with the inventory and the gap assessment: everything else in ISO 27090 depends on knowing which AI systems you have and which threats are credible for each.