ISO/IEC 27090 Explained: The AI Security Standard (2026 Guide)
ISO/IEC 27090:2026 is ISO’s guidance on security threats specific to AI systems. See the nine threat types it covers, how it works with ISO 27001 and ISO 42001, and what it does not cover. Published 14 October 2026.
ISO/IEC 27090:2026 is the international standard that explains security threats specific to AI systems, such as data poisoning, model theft and prompt injection, and how to detect and reduce them. ISO published Edition 1 on 14 October 2026 (56 pages, prepared by ISO/IEC JTC 1/SC 27). It is a guidance document, not a management system standard, and no certification scheme for it exists as far as we know. Organisations that need a certificate still audit against ISO/IEC 27001 or ISO/IEC 42001, and use 27090 to inform the AI-specific part of their risk work.
AI security training
PECB Certified Artificial Intelligence Security Professional (CAISP)
PECB designs the self-paced format and Reconn delivers it. Enrolment includes a free 1-on-1 session with a PECB Certified Trainer, WhatsApp and email support until you clear the exam, and one free retake within 12 months. CAISP is its own PECB credential, not an ISO/IEC 27090 certificate.
reconn.io | Dubai | Remote delivery worldwide
Key takeaways
- ISO published ISO/IEC 27090:2026 on 14 October 2026 as Edition 1, 56 pages, from ISO/IEC JTC 1/SC 27.
- It covers security threats that are specific to AI systems across the whole life cycle, and builds on ISO/IEC 27001 and 27002 instead of replacing them.
- Clause 6 names nine types of compromise, from data poisoning to model output that carries injection attacks.
- Most of the text uses "should" and "can". Clause 5.1 has two "shall" statements: implement ISO/IEC 27002 style controls based on a risk assessment, and take AI-specific compromises into account across the life cycle.
- Detection is a recurring theme. Some attacks use queries that look legitimate, so access control alone does not stop them.
- It is not certifiable and it is not proof of legal compliance with any regulation.
What ISO/IEC 27090 covers
The scope is security threats and compromises that are specific to AI systems: what the consequences are, and how to detect and mitigate them across the system's life cycle. It applies to organisations of any size or type that develop or use AI systems, including companies, public bodies and not-for-profits. It is not limited to chatbots or generative AI.
The document has three working parts. Clause 5 applies information security to AI: an AI governance programme, zero trust principles, software engineering practice, supply chain management, threat modelling and red teaming. Clause 6 describes the types of compromise, and for each one gives a description, the failures it can cause, how to detect it and how to mitigate it. Clause 6 also covers limiting data, controlling unwanted model behaviour in operation, and data and system provenance. Clause 7 deals with how mitigations interact: conflicts between them, continuity across the life cycle, deterioration over time, logging and monitoring, protecting development environments, detecting malicious input, throttling model use and keeping models small. Three annexes cover a mapping of attacks to the life cycle and to assets (informative), AI-specific versions of conventional attacks such as denial of service, supply chain attacks and backdoors (informative), and federated machine learning.
One point from the introduction changes how teams should think about retraining. Data collected while a system runs can later be used to update the model, so corrupted inputs can become training data. Poisoning is therefore not only a development-stage problem.
The nine threat types in plain English
Clause 6 gives each threat its own sub-clause. The table lists them with a plain description and an example. The examples are ours, written to make the definitions concrete.
| Clause | Threat | What happens | Example |
|---|---|---|---|
| 6.2 | Data poisoning | The attacker manipulates data to change how the system behaves. | Mislabelled samples slipped into a scraped dataset, so a fraud filter later waves through a pattern it should block. |
| 6.3 | Evasion | The attacker alters inputs to push the system into a wrong answer. The changes can be invisible to people. | Small pixel changes that make an image classifier misread a road sign. |
| 6.4 | Membership inference | The attacker works out whether a specific record was in the training data. | Testing whether a named patient's record was used to train a clinical model. |
| 6.5 | Model exfiltration | The attacker rebuilds a working copy of the model by sending inputs and studying the outputs. | A competitor scripts thousands of queries against a public pricing API and trains a clone. |
| 6.6 | Model inversion | The attacker reconstructs training data, or large parts of it, from inputs and outputs. | Repeated probing of a face recognition model to rebuild an image it was trained on. |
| 6.7 | Direct model poisoning | The attacker tampers with the model itself during development or operation. | A modified weights file pulled from a shared repository and deployed unchecked. |
| 6.8 | Sensitive model output | The model's output reveals part of an earlier input, such as training data or another user's prompt. | An assistant repeats a customer record that was in its training set. |
| 6.9 | Prompt injection | The attacker crafts content that ends up inside an instruction to the system and triggers behaviour its builders did not intend. | A hidden instruction inside a PDF that a summarisation tool reads. |
| 6.10 | Output containing injection attacks | The model's output carries an attack into whatever component consumes it next. | Generated text containing script that a web page renders without escaping it. |
Clause numbers follow the structure of the standard. Descriptions are paraphrased, not quoted.
AI management system
PECB ISO/IEC 42001 Lead Implementer (online)
eLearning with mentorship: a free 1-hour live session with a PECB Certified Trainer, unlimited email and WhatsApp support until you clear the exam, and one free retake, all within 12 months of enrolment. Use it to build the management system that ISO/IEC 27090 threat guidance feeds into.
reconn.io | Dubai | Remote delivery worldwide
How life cycle stages map to controls
The standard frames attacks as happening during development and training, during inference and operation, or both. The table below is our reading of where its controls land at each stage. Annex A of the standard has its own, more detailed mapping.
| Life cycle stage | Main exposures | Controls the standard points to |
|---|---|---|
| Data collection and preparation | Poisoned or unvetted data, unclear origin, sensitive data kept longer than needed | Integrity checks on datasets, labelling and classification, access control and data loss prevention, provenance records, data minimisation and retention limits |
| Model development and training | Direct model poisoning, tampered tooling, weak development environments | Protected development environments, secure engineering practice, threat modelling, verification that the model has not been altered |
| Supply chain and third-party components | Backdoored or poisoned pre-trained models, open-source components, vendor-hosted models | Supplier review, provenance of models and data, extending security requirements to third parties, controls from the AI management system |
| Deployment and integration | Model output reaching downstream systems, over-broad permissions | Least privilege for the model, zero trust principles, treating output as untrusted input to the next component |
| Operation and monitoring | Extraction, inference and inversion through normal-looking queries, evasion, prompt injection | Logging and monitoring of model use, throttling, detection of unusual or adversarial inputs, incident playbooks |
| Retraining and updates | Operational data feeding future training, mitigations that stop working as the model changes | Review of data before it re-enters training, red teaming after changes, re-testing mitigations over time |
Information security foundation
PECB ISO/IEC 27001 Lead Implementer (online)
eLearning with mentorship: a free 1-hour live session with a PECB Certified Trainer, unlimited email and WhatsApp support until you clear the exam, and one free retake, all within 12 months of enrolment. 27090 assumes a working information security baseline, and this is the standard that provides it.
reconn.io | Dubai | Remote delivery worldwide
How 27090 fits with other standards
ISO/IEC 27001 and ISO/IEC 27002
▼The introduction of 27090 recommends following the established practices in both. Clause 5.1 points to the organisational, people, physical and technological controls in ISO/IEC 27002, and specifically to logging and monitoring (8.15 and 8.16) and secure system architecture and engineering principles (8.27), which is also where zero trust is described. For an ISMS, the practical home for 27090 is the risk assessment: AI-specific threats go into the risk register and the reasoning behind control selection. If you are starting from scratch, our ISO 27001 guide, the gap analysis walkthrough and the certification process guide cover the management system side. People who will run the programme can see what the Lead Implementer course covers.
ISO/IEC 42001
▼ISO/IEC 42001 sets requirements for an AI management system and can be certified. 27090 does neither of those things. It is guidance on threats to AI systems, and it points to 42001 for how to run an AI governance programme. Its supply chain discussion also refers to controls A.6.2.3 and A.6.2.6 in Table A.1 of 42001. Read the two as layers: 42001 for governance, 27090 for the threat detail. Our ISO 42001 guide and implementation guide cover the management system, and the Lead Implementer and Lead Auditor pages explain the two PECB certification routes.
ISO/IEC 23894 and other risk guidance
▼Clause 5.1 says AI security measures can be folded into AI risk management as described in ISO/IEC 23894 or in relevant ETSI documents, and it names ETSI EN 304 223 among AI security standards to be aware of. The AI governance programme guidance also refers to ISO/IEC 38507. None of these replace 27090. They sit around it.
ISO/IEC 22989 and ISO/IEC 23053
▼These are the only two normative references. ISO/IEC 22989 supplies AI concepts and terminology and 23053 describes a framework for machine learning systems. The standard also leans on ISO/IEC 5338 for AI life cycle processes, which is how it frames attacks during development and training versus operation.
What published research shows
The threats in clause 6 are not hypothetical. Researchers have demonstrated each of the main ones against real datasets, services or products. The table matches four well-known studies to the 27090 threat headings. The mapping is ours.
| 27090 threat | Study | Year | What it showed |
|---|---|---|---|
| Data poisoning (6.2) | Poisoning Web-Scale Training Datasets is Practical, Carlini and colleagues | 2023 | Showed that attackers can practically tamper with web-crawled training datasets. The authors estimated that about 0.01% of two large image-text datasets could be contaminated for roughly $60. |
| Model exfiltration (6.5) | Stealing Machine Learning Models via Prediction APIs, Tramèr and colleagues | 2016 | Showed that an attacker with only query access can replicate a confidential model with near-perfect fidelity, including against two commercial prediction services. Hiding confidence values did not fully stop it. |
| Sensitive model output and model inversion (6.8, 6.6) | Scalable Extraction of Training Data from (Production) Language Models, Nasr and colleagues | 2023 | Showed that large volumes of training data can be pulled from many language models, including a production chatbot, just by querying them. |
| Prompt injection (6.9) | Not what you have signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, Greshake and colleagues | 2023 | Showed that instructions planted in retrieved content can steal data, change application behaviour and steer which external APIs an application calls. |
Two reference documents help when you want shared vocabulary beyond ISO. NIST publishes AI 100-2 E2025 (March 2025), a taxonomy and terminology of adversarial machine learning attacks and mitigations organised by learning method, life cycle stage and attacker goals and knowledge. The 2025 edition of the OWASP Top 10 for LLM applications ranks prompt injection first. Neither is a certifiable standard, and neither replaces the ISO text.
EU AI Act Article 15 and 27090
Article 15 of the EU AI Act covers accuracy, robustness and cybersecurity for high-risk AI systems. Paragraph 5 says technical solutions for AI-specific vulnerabilities should include, where appropriate, measures to prevent, detect, respond to, resolve and control attacks on training data (data poisoning), on pre-trained components (model poisoning), inputs built to make a model err (adversarial examples or evasion), confidentiality attacks and model flaws.
Those threat families overlap with several 27090 headings: data poisoning, direct model poisoning, evasion, and the confidentiality-style threats of membership inference, model exfiltration and model inversion. That makes 27090 a useful vocabulary for the technical side of the conversation.
It does not settle the legal question. 27090 is voluntary guidance, following it does not by itself show compliance with the regulation, and whether Article 15 applies depends on whether a system is high-risk and on the organisation's role. Check the regulation text and your current application timeline directly.
Five questions to answer before deployment
A short list to work through before an AI system goes live. None of it is a substitute for a full risk assessment.
- Which AI systems are in scope, including the ones suppliers run for us? The governance guidance starts with an inventory of AI systems and their use. You cannot threat model what nobody has listed.
- Where does the training and retraining data come from, and can we prove it? Poisoning and data leakage both start here. Operational data that later feeds retraining is part of the same question.
- What would extraction or inference look like in our logs, and does anyone look? These attacks can use queries that look normal, so detection has to be designed. Rate limits help but do not replace it.
- What can the model reach if its output is wrong or hostile? Think about data, tools and downstream systems. Least privilege and treating output as untrusted both limit the damage.
- Who tests it adversarially before go-live, and who retests after changes? The standard treats red teaming and threat modelling as ongoing work, and warns that defences can degrade as models change.
Who owns what
The standard is written for a mixed audience, and ownership usually splits across teams. This is a suggested split, not one taken from the text.
| Role | Typically owns | Question they answer |
|---|---|---|
| Security team (CISO office) | Threat modelling, logging and monitoring, incident response, security testing and red teaming | What would an attack on this system look like in our telemetry? |
| AI and ML engineering | Secure development practice, model integrity, input and output handling, mitigation design | Which defences are built in, and how do they hold up after retraining? |
| Data owner or data governance | Provenance, labelling, retention, what data is allowed into training | Where did this data come from, and may we use it? |
| Procurement and vendor management | Supplier due diligence for models, data and hosted AI services | What do we know about the people and data behind this component? |
| AI governance lead | AI system inventory, risk analysis, link to the AI management system | Which systems exist, who owns them, and which risks are accepted? |
| Internal audit or compliance | Evidence that the chosen controls operate | Can we show the controls ran, not just that they were written down? |
A worked example
Take a mid-sized insurer running two AI systems: a claims triage model that scores incoming claims, and a customer assistant that answers policy questions using retrieved documents. This is a made-up example, not a client engagement.
Start with the inventory and the data. Claims outcomes retrain the triage model every month, so what adjusters record becomes training data. That is a poisoning path through ordinary operations. The team adds review of data before it re-enters training and keeps provenance records for each retraining run.
Next, the exposed surfaces. The quote tool calls the triage model through a public interface. Someone could query it at volume to copy it. The team applies throttling and logs query patterns by account, because extraction through legitimate-looking queries is hard to spot after the fact.
The assistant reads uploaded claim documents. A document could contain hidden instructions, which is prompt injection. It could also repeat another claimant's details in a reply, which is sensitive model output. The team limits what the assistant can retrieve per user, filters inputs, and treats everything the assistant writes as untrusted when it reaches the case management screen, which covers output that carries injection attacks.
Finally the team schedules red teaming before go-live and after each major retrain, and records which mitigations depend on each other. The result is a short risk register entry set tied to the existing ISMS, not a new management system.
What ISO/IEC 27090 does not solve
It is guidance, and it is not a certificate
▼ISO describes 27090 as security guidance, not requirements for an AI management system, and no certification scheme for it exists as far as we know. Clause 5.1 does use "shall" twice: ISO/IEC 27002 style controls shall be implemented based on a risk assessment, and AI-specific compromises shall be taken into account across the life cycle. Everything else reads as recommendation. Organisations that want an auditable certificate use ISO/IEC 27001 or ISO/IEC 42001. Following 27090 does not show compliance with any law, including the EU AI Act.
Detection is still hard
▼The introduction is direct about this: some threats are difficult to detect, and building controls without detection would not be adequate. Model exfiltration is the clearest case, because the attack is carried out through legitimate querying of the model. Conventional measures such as rate limiting help, but models can be stolen even when they are in place.
Mitigations pull against each other and wear out
▼Clause 7 covers conflicting interactions between mitigations, continuity across the life cycle, and the deterioration of models and mitigations over time. A defence that works at launch can weaken after retraining. Plan for retesting, not a one-off sign-off. The text describes a defence-in-depth approach and does not promise immunity.
Agentic systems and jailbreaks have no clause of their own
▼The nine headings in clause 6 do not include agent tool use or jailbreaking as separate items. Prompt injection (6.9) and output that carries injection attacks (6.10) are the nearest fits. Teams building agents should use 27090 as a baseline and run their own threat modelling and red teaming on top. The reason is easy to see in the indirect injection research above: once retrieved content can steer which APIs an application calls, a model that can take actions turns a bad output into a bad action. That is our reading, not a statement from the standard. The governance, zero trust and least-privilege guidance still applies to agents. ISO/IEC 27091, which covers privacy risks in AI systems, was still at final-draft approval stage on ISO's catalogue when this article was written.
Sources and verification
Publication details were checked against ISO's catalogue entry on 20 October 2026, and clause references follow the standard's contents list. Descriptions of the standard are paraphrased, not quoted. Research summaries come from each paper's abstract page. Where the mapping between a study and a 27090 heading is ours, the text says so.
- ISO/IEC 27090:2026, ISO catalogue entry, used for publication details, scope, relationship to 27001 and 27002
- ISO/IEC 27090 explained, ISO, used for audience, threat areas, relationship to 42001, normative references
- ISO/IEC 27091, ISO catalogue entry, used for status of the privacy sibling document
- Poisoning Web-Scale Training Datasets is Practical, used for data poisoning research
- Stealing Machine Learning Models via Prediction APIs, used for model extraction research
- Scalable Extraction of Training Data from (Production) Language Models, used for training data extraction research
- Not what you have signed up for: indirect prompt injection, used for prompt injection research
- NIST AI 100-2 E2025, used for adversarial machine learning taxonomy
- OWASP Top 10 for LLM applications, used for ranking of prompt injection
- EU AI Act, Article 15, used for AI-specific vulnerabilities requirement
Further reading
- NewPECB Certified AI Security Professional (CAISP): Why It's a Must for Anyone Entering AI Security
- NewPECB Certified EU AI Governance Professional: What It Covers, Who Needs It and How the Exam Works
- AI governanceAI Governance Framework Comparison: ISO 42001 vs NIST AI RMF vs EU AI Act vs OECD
- ISO 42001ISO 42001: The Complete Global Guide to Artificial Intelligence Management Systems
- ISO 42001ISO 42001 Implementation Guide: Step-by-Step Methodology
- ISO 42001ISO 42001 Lead Implementer Certification: The Complete Guide
- ISO 42001ISO 42001 Lead Auditor Certification Training: Complete Guide to the AI Management System Course
Frequently asked questions
What is ISO/IEC 27090?
▼ISO/IEC 27090:2026 is an international standard that gives guidance on security threats specific to AI systems, their consequences, and how to detect and mitigate them throughout the AI system life cycle. It applies to any organisation that develops or uses AI systems.
Is ISO/IEC 27090 published?
▼Yes. ISO lists Edition 1 as published, with a publication date of 14 October 2026. It runs to 56 pages and was prepared by ISO/IEC JTC 1/SC 27.
Can you get certified to ISO/IEC 27090?
▼No certification scheme for ISO/IEC 27090 exists as far as we know, because ISO presents it as guidance. Organisations that need an auditable certificate use ISO/IEC 27001 for information security or ISO/IEC 42001 for AI management. No training course or credential is an ISO/IEC 27090 certificate.
How is ISO/IEC 27090 different from ISO/IEC 42001?
▼ISO/IEC 42001 sets requirements for an AI management system and can be certified. ISO/IEC 27090 is guidance on security threats to AI systems themselves and on detecting and mitigating them. Used together, 42001 provides governance and 27090 informs the threat analysis.
Does ISO/IEC 27090 cover prompt injection?
▼Yes. Clause 6 has a heading for prompt injection and another for model output that contains injection attacks. It does not have a separate clause for jailbreaking or for agent tool use.
Does ISO/IEC 27090 replace ISO/IEC 27001 or ISO/IEC 27002?
▼No. ISO says it complements them. Its introduction recommends following the established practices in both, and it adds guidance on threats that are specific to AI data, models and workflows.
Does following ISO/IEC 27090 make an organisation compliant with the EU AI Act?
▼No. ISO/IEC 27090 is voluntary guidance, and following it does not by itself show compliance with any law or regulation, including the EU AI Act. Legal duties depend on the system and the organisation's role, so check them against the regulation itself.
Does ISO/IEC 27090 cover AI agents?
▼It has no dedicated clause for agents or tool use. Its guidance on prompt injection, output that carries injection attacks, AI governance, zero trust and least privilege applies to agents, but teams building them should add their own threat modelling and red teaming.
What does published research say about the threats in ISO/IEC 27090?
▼Peer-reviewed and preprint research has shown each major threat in practice: web-scale training datasets can be poisoned cheaply, models can be copied through prediction APIs, training data can be extracted from production language models, and instructions hidden in retrieved content can steer an application. Sources are listed at the end of this article.
Is there a PECB course for ISO/IEC 27090?
▼No. The related PECB routes available through Reconn are the ISO/IEC 42001 Lead Implementer and Lead Auditor courses, the ISO/IEC 27001 Lead Implementer course, and the PECB Certified Artificial Intelligence Security Professional (CAISP) credential. Each is its own certification with its own exam. Reconn adds a free one-to-one session with a PECB Certified Trainer and WhatsApp and email support until you clear the exam.
About the author
Shenoy Sandeep is the Founder of reconn, an AI-first cybersecurity firm based in Dubai, UAE. With 20+ years across cybersecurity focussing on offensive security and threat intelligence portfolio, and over 10 years in Enterprise AI, AI governance and data protection, he has assisted over 25+ startups in scaling their business in the Middle East and African region.
Training and mentoring is Shenoy's passion project and reconn has associated themselves with PECB, the global leaders in personal certifications for AI, cybersecurity, data protection, privacy and business continuity professionals. He is a PECB-certified trainer and one of the world's early PECB-certified AI professionals, also specializing in ISO/IEC 42001. AI Governance, ISO/IEC 27001, ISO/IEC 27701, ISO 42001, ISO 22301, ISO 9001, ISA/IEC 62443, GDPR and US Data Privacy Laws.
Via Reconn, Shenoy runs an advisory service assisting organisations in the EMEA with compliance and certification on ISO 42001, ISO 27001, ISO 27701, ISO 22301 and local data protection and privacy laws. His current interests include AI Governance, Agentic AI using M365 Copilot Cowork, OpenAI, Claude and frameworks / regulations : NIST-AI RMF, EU AI Act, NIS2, DORA, EU/UK GDPR, UAE PDPL and SDAIA PRPL. We also provide advisory, implementation and training on Microsoft 365 Copilot Cowork Enterprise suite for AI AGENTIC solutions and services.
