Security teams are being asked how they handle AI-specific attacks such as poisoning, evasion and model extraction, and until now there has been no ISO/IEC security standard dedicated to them. ISO/IEC 27090 is the SC 27 document intended to fill that gap: guidance for addressing security threats and compromises to AI systems across their life cycle. On 27 October 2026 the ISO catalogue listed it as ISO/IEC FDIS 27090, Edition 1, at stage 50.00, in the approval phase and not yet published. This guide explains what the official scope says, what is and is not known about its content, how it relates to ISO/IEC 27001, 42001 and 23894, and how to build an AI threat programme now that will map cleanly when the final text appears. It is written for ISMS owners, AI security leads and auditors.
Key takeaways
- It is not published yet. ISO lists ISO/IEC 27090 as a Final Draft International Standard at stage 50.00 (FDIS registered for formal approval). The FDIS ballot is eight weeks, then publication. Check the catalogue before quoting a date.
- It is guidance, not certifiable requirements. The scope is guidance to understand, detect and mitigate AI-specific threats. Certification stays with ISO/IEC 27001 and ISO/IEC 42001.
- Do not trust "27090 clause" claims today. The final text is not public. Any checklist claiming to reproduce its clauses is based on drafts or guesswork.
- You can prepare now. Published taxonomies, especially NIST AI 100-2 E2025 and MITRE ATLAS, cover the same threat families: poisoning, evasion, privacy attacks, supply chain and prompt injection.
- Identity is part of AI security. Pipelines, model registries, inference endpoints and agents run on service accounts, API keys and tokens. Those NHIs are a direct route to poisoning or stealing a model.
What it is and who it applies to
The ISO catalogue gives the title as "Cybersecurity, Artificial intelligence, Guidance for addressing security threats and compromises to artificial intelligence systems". It is developed by ISO/IEC JTC 1/SC 27, the committee responsible for the ISO/IEC 27000 family, and classified under ICS 35.030. The official abstract says the document addresses security threats and compromises specific to AI systems, aims to help organisations understand the consequences of these threats across the AI life cycle, and describes how to detect and mitigate them. It applies to organisations of all types and sizes that develop or use AI systems.
| Item | Status on 27 October 2026 (ISO catalogue) |
|---|---|
| Designation | ISO/IEC FDIS 27090, Edition 1 |
| Stage | 50.00, "Final text received or FDIS registered for formal approval" |
| Committee | ISO/IEC JTC 1/SC 27 |
| Publication date | Not stated |
| Next stages | 50.20 FDIS ballot (8 weeks), 50.60 close of voting, 50.99 approved, 60.00 under publication, 60.60 published |
| Type | Guidance (no certification scheme) |
Two groups should pay attention. Developers and providers of AI systems, including teams that fine-tune or host models, are the primary audience for life-cycle threats such as training data poisoning. Organisations that use AI, including buyers of SaaS AI features and agent platforms, are also in scope, because the abstract explicitly covers organisations that use AI systems.
Structure and key requirements
The full text of ISO/IEC 27090 is not publicly available, and the clause structure of the FDIS is not published on the ISO catalogue page. This guide therefore does not list clause numbers. What can be said with confidence:
- Threat focus: the official scope is threats and compromises specific to AI systems, not general IT security, which remains the domain of ISO/IEC 27001 and 27002.
- Life-cycle framing: the abstract frames consequences across the AI system life cycle, so expect guidance organised around stages from data collection and training through deployment and operation.
- Detect and mitigate: the stated purpose includes detection as well as mitigation, which matters for SOC teams.
- Early drafts: the ISO27k forum's commentary page, describing an early working draft, lists poisoning, evasion, membership inference and model inversion, and model stealing as threat types, and notes that more were expected. Treat this as background on drafts, not as the final content.
Until the standard is published, the most reliable published reference for the same threat families is the NIST taxonomy. NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (final, March 2025), classifies attacks by attacker objective. The table below uses that taxonomy and MITRE ATLAS, which are published and stable, as the working structure for an AI threat register.
| Threat family | NIST AI 100-2 objective | Example ATLAS technique | Life-cycle stage | Typical mitigations |
|---|---|---|---|---|
| Data and model poisoning, backdoors | Availability (NISTAML.01), Integrity (NISTAML.02) | AML.T0020 Poison Training Data; AML.T0018.000 Poison AI Model | Data collection, training, fine-tuning | Training data sanitisation, provenance and integrity attestation, access control on datasets, model inspection, trigger reconstruction |
| Evasion (adversarial examples) | Integrity (NISTAML.02) | AML.T0015 Evade AI Model | Operation | Adversarial training, randomised smoothing, formal verification for narrow cases, input monitoring |
| Membership inference, model inversion | Privacy (NISTAML.03) | AML.T0024.000 Infer Training Data Membership; AML.T0024.001 Invert AI Model | Operation | Differential privacy in training, output restriction, query rate limits |
| Model extraction and stealing | Privacy (NISTAML.03) | AML.T0024.002 Extract AI Model | Operation, storage | Query limits and monitoring, API authentication, access control on weights and registries |
| Prompt injection, direct and indirect | Integrity, Privacy, Misuse (NISTAML.04) | AML.T0051 LLM Prompt Injection; AML.T0056 Extract LLM System Prompt | Operation | Privilege separation, least agency, output handling, human approval for high-impact actions |
| AI supply chain compromise | Supply chain (NISTAML.05) | AML.T0010 AI Supply Chain Compromise | Acquisition, build | Model and dataset provenance, signing, AI-BOM, vetted registries |
| Denial of AI service, energy-latency | Availability (NISTAML.01) | AML.T0029 Denial of AI Service | Operation | Rate limits, cost caps, input size limits |
For depth on each family, see the Adversarial ML Taxonomy Guide, the AI Data Poisoning and Backdoors Guide, the Adversarial Examples and Evasion Attacks Guide and the Model Extraction and Distillation Defence Guide.
Identity and NHI requirements
Whatever the final clause list, most of the mitigations above depend on access control over AI assets, and those assets are accessed mostly by machines. A poisoning attack rarely needs clever mathematics if a CI job's token can write to the training bucket. Build these identity controls into your AI threat programme:
| AI asset | Typical non-human identity | Threat it enables if abused | Control |
|---|---|---|---|
| Training and fine-tuning datasets | Pipeline service accounts, storage access keys | Poisoning, backdoors | Write access only from the ingestion pipeline identity; workload identity federation instead of static keys; integrity hashes recorded at ingest |
| Model registry and weights | CI/CD tokens, registry robot accounts | Model tampering, theft of weights | Separate push and pull identities; signed artefacts; alert on reads from unexpected identities |
| Inference endpoints | API keys issued to applications and customers | Extraction, membership inference, cost abuse | Per-consumer keys with quotas, short-lived tokens, anomaly detection on query volume and diversity |
| Agents and tool integrations | OAuth tokens, service accounts, MCP credentials | Prompt injection turning into real actions | Least privilege per agent, sender-constrained tokens, human approval on high-impact tools |
| Evaluation and red team tooling | Test accounts with broad read | Leakage of test data and prompts | Time-bound access, separate tenancy |
MITRE ATLAS lists AML.T0055 Unsecured Credentials as a technique in its own right, which is a useful way to put credential hygiene into an AI threat model. See the Agentic AI Identity Guide and the LLMjacking Guide.
Implementation steps
- Inventory AI systems first. List every model you train, fine-tune, host or consume, with owner, data sources, endpoints and the identities that touch each. See the AI Register and AI Inventory Template.
- Build an AI threat register on a published taxonomy. Use the NIST AI 100-2 objective categories and ATLAS technique IDs from the table above. Record for each system which families apply, for example extraction only matters if outsiders can query the model.
- Fold AI threats into existing risk assessment. Use your ISO/IEC 27001 risk process and, where you run one, the AI risk process from ISO/IEC 23894 or an ISO/IEC 42001 AI management system. Do not run a parallel spreadsheet. See the ISO/IEC 23894 AI Risk Management Guide.
- Implement access and integrity controls on AI assets. Start with the identity table above: dataset write paths, registry push rights and inference API keys give the best risk reduction for the effort.
- Add AI-specific testing. Pilot adversarial and prompt injection testing on one high-exposure system, then make it part of release criteria. See the AI Red Teaming Guide.
- Add detection. Log inference requests with consumer identity, monitor query patterns and record model and dataset hashes so tampering is visible.
- Gap-assess against the final text when published. Buy the published standard, map each clause to your threat register and controls, and record gaps. Because 27090 is guidance, decide which recommendations you adopt and document why.
Small vs large organisations: a small organisation that only consumes AI through SaaS should focus on supplier assurance, prompt injection and data leakage, and can treat training-time threats as a supplier question. A large organisation that trains or fine-tunes models needs the full life-cycle register, dataset provenance and a model registry with separated identities. Rollback is simple at this stage: the controls are additions to an existing ISMS, so a control that causes friction (for example, strict inference quotas) can be relaxed per consumer without dismantling the programme.
Evidence and assessment
There is no certification against ISO/IEC 27090. Evidence of how you address AI threats will be examined through ISO/IEC 27001 and ISO/IEC 42001 audits, customer due diligence and, for providers in the EU, conformity work under the EU AI Act, whose Article 15 requires high-risk AI systems to be resilient against attempts to alter their use or performance by exploiting vulnerabilities, including AI-specific ones such as data poisoning and adversarial examples. See the EU AI Act High-Risk AI Systems Guide.
- AI threat register: per system, threat family, ATLAS ID, owner, control and residual risk.
- Statement of Applicability entries: showing how Annex A controls such as access control, logging and supplier relationships apply to AI assets. See the ISO 27001 Statement of Applicability Template.
- Test reports: adversarial, extraction and prompt injection tests with dates, scope and remediation.
- Integrity records: dataset and model hashes, signatures and registry audit logs.
- Access reviews: for NHIs with write access to datasets and registries.
Metrics
- Threat register coverage: percentage of AI systems in the inventory with a completed threat assessment.
- Static credential share: percentage of identities with write access to training data or registries that use long-lived keys. Drive it down.
- Testing coverage: percentage of externally exposed models tested for prompt injection or extraction in the last release cycle.
- Integrity verification rate: percentage of model deployments whose artefact hash or signature was verified at deploy time.
- Time to detect anomalous query patterns: from first abnormal volume to alert, measured in exercises.
Mapping to other frameworks
| Framework | Relationship to ISO/IEC 27090 | Where it helps |
|---|---|---|
| ISO/IEC 27001:2022 | Certifiable ISMS; 27090 guidance sits on top for AI-specific threats | Risk process, Annex A controls applied to AI assets |
| ISO/IEC 42001:2023 | Certifiable AI management system, published 18 December 2023 | Governance, AI risk and impact assessment, life-cycle controls. See the ISO/IEC 42001 Guide |
| ISO/IEC 23894:2023 | Guidance on AI risk management, published February 2023 | Method for identifying and treating AI risk |
| NIST AI 100-2 E2025 | Published adversarial ML taxonomy | Threat categories and mitigation options today |
| MITRE ATLAS | Adversary tactics and techniques for AI systems | Threat modelling, red team scenarios, detection |
| NIST SP 800-53 Rev. 5 | Control catalogue | RA-3 Risk Assessment, SA-11 Developer Testing and Evaluation, SR-3 Supply Chain Controls and Processes, SI-7 Software, Firmware, and Information Integrity, CM-8 System Component Inventory |
| NIST CSF 2.0 | Outcome framework | ID.AM-02 inventories, ID.RA-05 risk prioritisation, GV.SC-01 supply chain programme, PR.DS-01 data at rest |
| NCSC Guidelines for secure AI system development | Published November 2023, four life-cycle areas | Secure design, development, deployment, and operation and maintenance practices |
For a wider crosswalk, see the AI Security Frameworks Crosswalk Guide.
Common pitfalls
- Citing an unpublished standard as a requirement: contracts and policies that require "compliance with ISO/IEC 27090" before publication have nothing stable to test against. Reference the published edition once available, with its year.
- Buying draft-based checklists: clause lists circulating before publication may not match the final text. Use the published taxonomies until you hold the standard.
- Treating AI security as model maths only: many real compromises of AI systems start with leaked keys, over-permissioned pipelines or exposed endpoints, not novel attacks.
- Ignoring the "use" side: organisations consuming AI are in scope. Prompt injection and data leakage through SaaS AI features need controls too. See the Third-Party AI Risk Guide.
- Separate AI risk silos: an AI threat register outside the ISMS risk process gets out of date and is invisible to auditors.
- No integrity baseline: without recorded hashes for datasets and models, tampering cannot be proven or ruled out after an incident.
Practitioner checklist
- Check the ISO catalogue entry for ISO/IEC 27090 and record its stage and date.
- Complete an AI system inventory with owners and the NHIs that access each asset.
- Build an AI threat register using NIST AI 100-2 categories and verified ATLAS technique IDs.
- Integrate AI threats into the ISO/IEC 27001 risk process and Statement of Applicability.
- Restrict write access to training data and model registries to named pipeline identities using short-lived credentials.
- Issue per-consumer inference keys with quotas and monitor query patterns.
- Record and verify hashes or signatures for datasets and models.
- Run prompt injection and extraction tests on externally exposed models before release.
- Plan a gap assessment against ISO/IEC 27090 within one quarter of publication.
Standards and references
- ISO: ISO/IEC FDIS 27090 Cybersecurity, Artificial intelligence, Guidance for addressing security threats and compromises to artificial intelligence systems
- ISO: International harmonized stage codes
- NIST: AI 100-2 E2025 Adversarial Machine Learning, A Taxonomy and Terminology of Attacks and Mitigations
- ISO: ISO/IEC 42001:2023 Artificial intelligence, Management system
- ISO: ISO/IEC 23894:2023 Artificial intelligence, Guidance on risk management
- MITRE ATLAS: Poison Training Data
- NCSC: Guidelines for secure AI system development
- ISO27k forum: ISO/IEC 27090 commentary (early drafts)
Related NHI Mgmt Group resources: ISO/IEC 42001 Guide · Adversarial ML Taxonomy Guide · AI Threats and Model Security Guide · ISO/IEC 23894 AI Risk Management Guide. This guide summarises the published status and scope of ISO/IEC 27090 and is not a substitute for the standard itself.