ISO/IEC 27090: Identifying, assessing and controlling security threats to AI systems

From project start in 2022 to publication in 2026

The project was approved on 15/09/2022, the Committee Draft consultation began in January 2024, and the DIS ballot on 16/04/2025. The Final Draft was balloted from 23/06 to 19/08/2026 and moved to the status “under publication” on the very day the ballot closed; publication followed on 14/10/2026 with stage code 60.60. The ballot result is not public, but the transition without referral back confirms approval. The title changed along the way: “Guidance for addressing security threats and failures” became “Addressing security threats and compromises to AI systems”, failures became compromises, and the document grew from 46 to 56 pages with 115 bibliography entries.

Publisher and committees

The standard was developed by ISO/IEC JTC 1/SC 27 “Information security, cybersecurity and privacy protection”, whose secretariat is held by DIN (Chair Dr Andreas Wolf); the responsible working group was WG 4 “Security controls and services” under Convenor Faud Khan of Canada's SCC, and no public source names the project editors. The SC 27 Journal of September 2026 describes 27090 as the subcommittee's first standard specifically on the security of AI systems. In Germany, the working committee NA 043-04-27-04 “IT security controls and services” mirrors WG 4; as at 22/10/2026 its project list contains neither an adoption project nor a comment on 27090.

Purchase, language, national editions

The standard is published in English only. ISO charges CHF 204, DIN Media sells the ISO original as ISO/IEC 27090:2026-10 for EUR 218.32 net, and in the IEC Webstore it is listed as publication 117332. There is no German edition: DIN Media and SNV sell only the English ISO original, no ÖNORM adoption is known, and the British adoption BS ISO/IEC 27090:2026 is announced for 31 October 2026. Previews with the table of contents, Introduction, Clauses 1 to 4, 5.1 to 5.3 and the bibliography can be viewed free of charge; Clauses 5.4 to 7, Table 1 and the annexes are available only in the full version, and statements on this page about them rely on the table of contents and FDIS analyses and are marked as such.

Guidance standard, not a management system standard

ISO/IEC 27090 is an International Standard with the character of a guidance document. ISO's own explainer speaks of security guidelines, not of requirements for an AI management system; for those, Clause 5.2 refers to ISO/IEC 42001. There is no “ISO 27090” certificate, no audit “against 27090” and no presumption of conformity under the AI Act or the Cyber Resilience Act. Nevertheless, the standard is not a mere collection of recommendations: Clause 5.1 contains two documented “shall” statements, according to which information security controls, for instance from ISO/IEC 27002, shall be implemented on a risk basis and AI-specific compromises shall be considered across the entire life cycle. In practice this means: no certifiable requirements, but a clear expectation that the threats in Clause 6 are addressed in your own risk management.

Scope: develop or use

Clause 1 describes the subject matter as follows: security-relevant threats and compromises specific to AI systems, their consequences, and detection and mitigation across the entire life cycle — applicable to companies, public authorities and non-profit organisations that develop or use AI systems. The Introduction speaks of developing or deploying, Clause 5.1 of actors along the supply chain. Clause 3 does not define the provider and deployer roles from the AI Act or the stakeholder roles from ISO/IEC 22989; any assignment of mitigations to roles is therefore interpretation. The scope is not limited to generative AI.

Normative and informative references

The standard cites exactly two documents normatively: ISO/IEC 22989 undated, i.e. including future changes such as the ongoing amendment on generative AI, and ISO/IEC 23053:2022. ISO/IEC 27001, 27002, 42001, 23894, 5338 and 38507 appear only in the bibliography, but are explicitly named in 5.1 and 5.2 as the working basis. Clause 3 takes the protection goals from the new ISO/IEC 27000:2026, and threat, attack and vulnerability from ISO/IEC 27002:2022.

What is not covered

• Requirements for an AI management system: Clause 5.2 refers to ISO/IEC 42001.
• Privacy risks of AI systems: the subject of the sister standard ISO/IEC 27091.
• AI as a defensive tool, and threats that merely use AI, such as deepfakes or AI-assisted phishing.
• Attacks by AI on AI, and functional safety, for which ISO/IEC TR 5469 is the relevant document.
• A presumption of conformity under the AI Act or the Cyber Resilience Act: 27090 is not a harmonised standard, and no official mapping to prEN 18282 or ETSI TS 104 223 exists.

27090 and 27091: security and privacy as a pair

ISO/IEC 27091 “Cybersecurity and Privacy — Artificial Intelligence — Privacy protection” has not yet been published; the FDIS ballot had not started as at 22/10/2026. According to DIS-based summaries, it addresses privacy analysis, the privacy of AI models and privacy engineering across the life cycle. The overlap is visible: membership inference and model inversion appear in both standards, in 27090 as a security threat to the confidentiality of training data, in 27091 as a privacy risk. Publication in early 2027 is plausible, but it is not an ISO target date.

Clause 5: 5.1 as the frame, six practices

Clause 5.1 sets the frame: AI systems are integrated software components to which the controls of ISO/IEC 27002 apply on a risk basis, and AI-specific compromises, including those listed in Table 1, are to be considered across the life cycle according to ISO/IEC 22989 and 5338. As an efficient starting point, the standard names hardening the software stack against direct model theft, with ETSI EN 304 223 and the NIST Secure Software Development Framework as examples. Clause 5.2 describes a governance programme with inventory, risk analysis and risk treatment; 5.5 structures supply chain management into five subclauses ranging from general and AI-specific threats to counter-strategies. Clause 5.3 adopts the six zero trust principles from ISO/IEC 27002 8.27, illustrates them with five examples up to the verification of agent actions, and announces that they feed into all mitigation subclauses of Clause 6.

Clause 6: nine types in a uniform pattern

Table 1 is referenced in 5.1 but does not appear there; in our reading it is located in 6.1 and, according to the FDIS analysis, lists twelve attack types, nine from Clause 6 and three from Annex B.

Clause 7 and the annexes

Clause 7 is short at four pages, but in our assessment it is the most important part of the standard for mitigation decisions. Clause 7.2 addresses conflicting interactions; the FDIS analysis cites as an example adversarial training that increased susceptibility to patch attacks, and recommends testing all mitigations together before deployment. Clause 7.3 addresses the continuity of mitigations across the life cycle, 7.4 describes the deterioration of model and mitigations, with monitoring, retraining where needed and revalidation before returning to operation; 7.7 separates out-of-distribution inputs, which are not necessarily attacks, from adversarial inputs. Annex A maps attacks to life cycle and assets, Annex B describes AI variants of conventional attacks, Annex C federated learning.

Terms, abbreviations, bibliography

Clause 3 defines 30 terms, including the three-way division of attacker knowledge into zero-, partial- and perfect-knowledge attacks instead of the black-, grey- and white-box metaphor. The attack types are found in 3.13 to 3.24, with prompt injection defined broadly enough that content acting as or within an input instruction also covers the indirect variant. Not defined are AI agent, compromise and predictive AI. Clause 4 lists 15 abbreviations from AI through DP, JIT, OOD and RAG to RT; MCP is missing, which under the ISO/IEC Directives is a strong indication that the Model Context Protocol does not appear in the text of the standard. Not cited are the NIST AI RMF, NIST AI 100-2, the OWASP Top 10 for LLM Applications, the OWASP Agentic Top 10 and the Model Context Protocol — precisely the documents with which this page supplements the standard.

Core premise of the Introduction

The Introduction sets out four ideas that carry the rest of the standard. First, practice under ISO/IEC 27001 and 27002 remains recommended, because AI systems are software and share all known vulnerabilities. Second, with continuous learning, operational data can become training data, turning operation into a poisoning vector. Third, a model can be exfiltrated via legitimate queries even though all standard controls are intact; rate limiting helps. Fourth, detection is difficult but indispensable, which is why the standard sets defence in depth as its guiding principle and gives each attack type its own detection subclause.

Assets and attacker objectives

According to the FDIS-based analysis of Table 1, the standard sorts its twelve attack types by the asset affected first: model, training data, test data, output and service. Added to this are the software stack into which the AI system is integrated, from 5.1, and the supply chain from 5.5, which according to the FDIS analysis comprises pre-trained models, purchased datasets, notebook platforms and MLOps tools. An AI inventory under 5.2 should therefore record, for each system, the model artefact, data, retrieval sources, system prompts, interfaces, tool permissions and pipeline. In our reading, six attacker objectives lie behind the nine types.

Attacker knowledge and phases

In 3.10 to 3.12, Clause 3 distinguishes attacks without, with partial and with full knowledge of the model, in each case without credentials. This reveals the focus of the first edition: the typical attacker is a deliberately acting outsider. Gary Hinson has criticised that accidental threats, insiders and consequences beyond the organisation itself are under-represented; at least Table 1, according to the FDIS analysis, labels each type as an attacker or accident scenario. Insiders with legitimate permissions and misconfigurations are items you must add to the risk register yourself. In terms of timing, 5.1 orders attacks by whether they take hold during development and training, during inference and operation, or in both phases.

In 5.1 the standard refers to the life cycle under ISO/IEC 22989 and 5338, from inception to decommissioning, and in Annex A assigns attacks to life cycle stages and assets; the columns of that annex are not visible in the previews. The six phases on this page plus the cross-cutting areas of supply chain and governance are a VamiSec working model that follows these two standards but does not reproduce any stage designation from 27090.

1. 1
   Phase 01 · Development/TrainingData and sourcing

   Data Poisoning (6.2) and the Annex B types Direct Training Data Leak and Model Input Leak; sourced datasets form part of the supply chain under 5.5. Anchors: provenance (6.11.4), data limitation (6.11.2).

2. 2
   Phase 02 · Development/TrainingDevelopment and training

   Direct Model Poisoning (6.7) and backdoors (3.24) target the model artefact and the pipeline. Anchors: development environment (7.6), software engineering (5.4), zero trust for training data (5.3).

3. 3
   Phase 03 · TransitionVerification and validation

   This is where susceptibility to evasion, membership inference and model inversion becomes measurable before attackers exploit it. Anchors: red teaming (5.7), threat modelling (5.6), joint testing of all mitigations (7.2).

4. 4
   Phase 04 · Inference/OperationDeployment and integration

   Connecting the model to applications, retrieval sources and tools creates the attack surfaces for Prompt Injection (6.9) and output containing injection attacks (6.10). Anchors: application boundaries and model access including RAG (5.3), input filtering (7.7), throttling (7.8).

5. 5
   Phase 05 · Inference/OperationOperation and monitoring

   Evasion (6.3), Membership Inference (6.4), Model Exfiltration (6.5), Model Inversion (6.6) and Sensitive Model Output (6.8) all run through legitimate queries. Anchors: logging and monitoring (7.5), the detection sections 6.x.3, unwanted model behaviour in operation (6.11.3).

6. 6
   Phase 06 · Both phasesReassessment and decommissioning

   Model and mitigations decay over time (7.4): monitoring, retraining where needed, revalidation before returning the model to service. Retraining with operational data reopens the poisoning vector from 6.2. The publicly available version is silent on decommissioning; ETSI EN 304 223 has a dedicated principle for it.

Continuous learning: operation becomes the training phase

The Introduction and the ISO catalogue page stress the same point: retraining and updates need security attention because operational inputs can become training data. Clause 6.7 provides for direct model poisoning in development or operation, 7.3 addresses the continuity of mitigations, 7.4 describes the decay of model and mitigations, and 5.3 extends zero trust from the management of training data through to agent operation. For CISOs this means: every feedback loop of user data into a model, including via feedback functions, memory stores or RAG indexes, is a transition into the training phase and needs the same approvals as the original data sourcing.

6.2 Data Poisoning: integrity of the training data

Data Poisoning manipulates the data a model learns from and takes hold in development and training, and under continuous learning also in operation. Targeted variants corrupt the integrity of training data and output, untargeted ones hit availability; the standard treats backdoor attacks as a generic term, not as a compromise type of its own. The FDIS analysis describes the detection section as an admission: automated methods do not reliably separate poisoned data from outliers. Mitigation therefore shifts forward, to provenance, integrity checks along the pipeline and limiting the data that enters a model in the first place (6.11.4, 6.11.2). The standard does not treat the poisoning of a retrieval base as a type of its own; OWASP lists LLM05, LLM09 and ASI06 for it, MITRE ATLAS the technique AML.T0080, and the BaFin guidance explicitly names knowledge poisoning of a RAG base. VamiSec recommendation: approve RAG indexes, memory stores and feedback data in the same way as training data.

6.7 Direct Model Poisoning: manipulation of the model itself

Direct model poisoning under 3.18 targets not the data but the model directly, in development or in operation; what is affected is the integrity of the model. In our reading, the mitigation family comprises protection of the development environment under 7.6, signatures and checksums for model artefacts, and execution in a Trusted Execution Environment, which Clause 3 adopts from ISO/IEC 27071. Two cases show the mechanism: PoisonGPT from July 2023, a GPT-J-6B manipulated by model editing under the typosquat “EleuterAI” on Hugging Face, and nullifAI from February 2025, two models with corrupted pickle files and a reverse shell. Both are predominantly proof of concept. The boundary with the supply chain is fluid, which is why Chapter 13 of this page treats model sourcing separately.

6.8 and Annex B: data the model gives away

Sensitive Model Output under 6.8 means that a model discloses confidential training data or, under 3.22, also earlier inputs through its output, during inference; in our reading the mitigation consists of output filters and data limitation under 6.11.2. Annex B adds the conventional routes to the same result: direct theft of training data and the leak of model inputs, defined in 3.20 and 3.21. The most prominent example of 6.8 is EchoLeak, a zero-click vulnerability in Microsoft 365 Copilot through which internal data could be exfiltrated via the output (CVE-2025-32711, fixed May 2025). Membership Inference and Model Inversion are covered in Chapter 7 of this page.

Evasion: deceiving rather than manipulating

Evasion is the classic attack on predictive models: an image, a transaction or a text is altered minimally and the classification flips. The standard places detection in 7.7, which separates out-of-distribution inputs from adversarial inputs. Mitigation includes adversarial training; the abbreviations EOT, RT and IDBT in Clause 4 point to input transformations as a further technique, but their assignment to 6.3.4 is our reading. The decisive point comes from 7.2: according to the FDIS analysis, the standard cites an adversarial training that increased susceptibility to patch attacks and therefore recommends testing all mitigations together before a model goes into operation. No verified production evasion incident has been made public to date.

Model Exfiltration: theft by query

The Introduction cites Model Exfiltration as the prime example of how all standard controls can be intact and the model still lost, because every single query is legitimate. Detection and defence rely on logging and monitoring under 7.5, for which the standard explicitly names ISO/IEC 27002 8.15 and 8.16, on throttling of model use under 7.8 and on optimising model size under 7.9. Alongside these, Annex B places direct model theft under 3.19, which 5.1 cites as the reason to harden the software stack first. The best-known case is an allegation: from 28/01/2025 onwards, OpenAI stated that DeepSeek might have improperly distilled its models; no evidence was published.

Membership Inference and Model Inversion: confidentiality of the training data

Both attacks exploit the fact that models partially memorise their training data and give it away through probabilities, confidence scores or phrasing. In our reading, mitigation applies at three points: differential privacy in training, whose abbreviation DP appears in Clause 4, limiting outputs to what is necessary, and data limitation under 6.11.2. For 2024 to 2026 no production incident is publicly documented; the bibliography points to the research basis with Carlini's work on extracting training data from language models. The AI Act groups these attacks under confidentiality attacks, the BaFin guidance under the umbrella term inference attacks, and recommends differential privacy against inferences drawn from repeated queries.

What the standard says about generative AI

Clause 3 defines foundation model, LLM and generative AI (3.27 to 3.29) and frames prompt injection in 3.23 so as to capture content that acts as or within an input instruction, which includes indirect injection via documents, web pages or emails. Clause 6.9 assigns the attack to inference; what is affected is the integrity of the output and the confidentiality of internal system information such as system prompts. In our reading, mitigation comprises input filtering from 7.7, the separation of instruction and data, and human approval for consequential actions. Clause 6.10 addresses the case in which the model output itself carries injection attacks against downstream systems; in our reading, the defence lies in output encoding and allowlists on the receiving side. RAG appears in Clause 4 and twice in 5.3, where every document query is to be authenticated and authorised individually.

What the standard says about agents, and what it does not

The word agent appears three times in the publicly available parts, exclusively in 5.3: in the example of verifying agent actions, in which every action is verified and authorised individually, access is granted just in time with limited scope and privileges expire once the task is complete, and in the life cycle formula extending to agent operation. The word tool is absent from the publicly available parts, MCP is absent from the list of abbreviations and the bibliography, AI agent is not defined, and neither the OWASP Top 10 for LLM Applications nor the Agentic Top 10 nor NIST AI 100-2 is cited. Heise sums it up: the first edition treats agentic systems with tool access only marginally. That is a consequence of the standardisation cycle: the Committee Draft dates from January 2024, and the wave of agentic incidents began in 2025.

Real-world cases 2025 to 2026: prompt injection is operational

The list of cases for 6.9 and 6.10 is long and predominantly real: EchoLeak in Microsoft 365 Copilot (zero-click, fixed May 2025), ForcedLeak in Salesforce Agentforce, in which CRM data flowed as an image request to an expired allowlist domain (CVSS 9.4), ShareLeak in Copilot Studio (CVE-2026-21520), the research demo Comment and Control from April 2026, in which an injection in the title of a pull request made a coding agent publish its own API key, and the vulnerability in the Claude Code GitHub Action (fixed on 05/05/2026). In March 2026, Unit 42 counted twelve cases of indirect prompt injection in the wild with 22 payload techniques. For 6.10, Amazon Q Developer 1.84.0 is instructive: injected code was meant to start an agent with full tool privileges and without confirmation and delete data, but failed on a syntax error (CVE-2025-8217).

The two mandatory sentences in 5.1 — and what they mean

In the freely accessible parts of the standard, our review found two sentences in the technical text that are worded as binding, both in 5.1 — not counting the formal Foreword boilerplate: information security controls as described in ISO/IEC 27002 are to be implemented on a risk basis, and AI-specific compromises, including those listed in Table 1, are to be considered across the entire life cycle. Everything else in the accessible parts is guidance; a total count for the whole document cannot be given because pages 8 to 50 are only available in the full version. In no case does the standard contain certifiable requirements. The message is clear: first the ISMS, then the AI-specific extension. 5.1 treats AI systems as integrated software components and names hardening the software stack against direct model theft as an efficient starting point.

5.2 Governance programme: inventory, risk analysis, risk treatment

Section 5.2 describes three building blocks: an inventory of AI systems, a risk analysis and the treatment of the identified risks. For governance, the standard refers to ISO/IEC 38507; for implementation as a management system, to ISO/IEC 42001. What it does not do: Clause 3 defines neither the AI Act roles of provider and deployer nor the stakeholder roles of ISO/IEC 22989. Anyone assigning responsibilities does so as their own interpretation and should flag this in the governance document.

What belongs in the AI inventory

• Model source and version: trained in-house, open-source model from a repository, foundation model in your own tenant or external API — the sourcing variant determines the attack surface.
• Training, fine-tuning and retrieval data sources with provenance, approval and owner; 6.11.4 treats the provenance of system and data as a topic in its own right.
• Query and API access: who may query the model and with which limits — the basis for defending against extraction (6.5) and inference attacks (6.4, 6.6).
• Tools, actions and permissions of agentic components; the legal analysis in arXiv 2604.04604 names a complete inventory of external actions and data flows as the first obligation.
• Owner, criticality and regulatory classification: high-risk under the AI Act, critical or important function under DORA, product with digital elements under the CRA.

The blind spot is called shadow AI: in the CSA/Token Security survey of 21/04/2026, 82 per cent of 418 respondents reported unknown AI agents, and according to the IBM report of 30/07/2025, AI access controls were missing in 97 per cent of AI-related security breaches. The studies are vendor-sponsored, but the direction is unambiguous: without an inventory, the risk analysis under 5.2 remains incomplete, and every mitigation only reaches the systems you know about.

Citation note: Table 1 is referenced in 5.1 but does not appear there; its location and content can only be viewed in the full version. This page counts the nine types from 6.2 to 6.10.

Software engineering for AI (5.4): no special path

Section 5.4 transfers established software development practices to AI systems; the standard refers to the NIST Secure Software Development Framework (SP 800-218), and the bibliography also lists the NCSC guidelines for secure AI development. The stance is pragmatic: an AI system is software first, and anyone who does not harden their stack loses the model through conventional routes — Annex B lists direct model theft as an AI-specific variant of a classic attack. In ISO/IEC 42001, the counterpart in our reading is A.6.2.3, the documentation of design and development, which 27090 cites in 5.1.

Data-related defence: provenance, integrity, limitation

Detection: an open research question

On the detection of Data Poisoning (6.2.3), the standard is notably reserved: according to the FDIS-based analysis, it describes the topic as an open research question because automated methods cannot reliably separate poisoned data from outliers. This leads to a weighting we share: prevention through provenance, approval and access carries more weight than after-the-fact detection, and monitoring for model degradation in 7.4 becomes the second line of defence. The Introduction names the mechanism that carries the topic into operations: with continuous learning, operational data becomes training data, and every retraining round is a new poisoning vector.

For Retrieval Augmented Generation, the same principle applies on the knowledge side: in its example on application boundaries, 5.3 describes that every document query is individually authenticated and authorised, and the BaFin guidance speaks of knowledge poisoning of the RAG base (p. 29). Anyone who loads corporate documents unchecked into a vector index builds the poisoning vector themselves.

What the standard says about testing

Clause 5 places threat modelling in 5.6 and red teaming in 5.7 alongside governance and supply chain as foundational practices; every compromise type in Clause 6 carries a subsection on detection. Clause 7 explains why one-off testing is not enough: 7.2 describes interactions between mitigations and gives the example that adversarial training increased susceptibility to patch attacks — the standard recommends testing all mitigations together before deployment. 7.4 adds decay over time, with monitoring, retraining where needed and revalidation before returning to operation.

When to test: triggers instead of a calendar

• Before deployment: test all mitigations together, because they can weaken each other (7.2).
• After a change to the model, system prompt or retrieval source — the three triggers Kertos names for repeating red teaming.
• After every retraining round: revalidation before returning to operation (7.4).
• After a provider's model updates: update announcements therefore belong in supplier requirements — Kertos names them as a contractual point; the BaFin guidance names due diligence and SLAs as practice for sourced models (Chapter IV.2).
• Recurring for mitigations whose effectiveness fades: input filters and anomaly thresholds age with the threat landscape.
• For agentic systems, after every change to tools, permissions or integrations (VamiSec recommendation going beyond 5.3).

The regulatory connection is close: for high-risk AI, the AI Act requires testing as part of risk management in Art. 9(6) to (8); DORA requires a testing programme with penetration tests and source code reviews in Art. 24 and 25, and BaFin describes adversarial testing, adversarial penetration tests with the cloud provider and stress tests as practice depending on criticality. ISO/IEC 27090 supplies the attack vocabulary and the testing logic — not the obligation.

In ISO/IEC 27090, red teaming is not a mandatory or certification test. Scope and frequency are determined by the risk analysis, criticality and, where applicable, the AI Act, DORA or the CRA.

5.3 Zero Trust: five examples that feed into all mitigations

• Protection of training data — the standard places it at the top of the example list.
• Model access controls, including access via RAG.
• Application boundaries: every document query is individually authenticated and authorised — no blanket trust relationship between model and data source.
• Verification of agent actions: individual authorisation per agent action, permissions only for the duration of the task.
• Continuous monitoring from training through deployment to agent operations.

This line matches the government agency papers published since 2025: in their Design Principles for LLM-based systems of 11/08/2025, BSI and ANSSI describe six principles ranging from authentication and authorisation through sandboxing and monitoring to awareness, and state that an LLM must never authenticate by itself; the NSA notes in its MCP security assessment of May 2026 that authorisation is optional in the protocol. In our assessment, ISO/IEC 27090 is not the most detailed formulation of this consensus, but the one that connects best to the ISMS and AIMS.

Operational mitigations per compromise type

Detection and incidents: what the standard says and what the ISMS must deliver

The Introduction states the core: detection is difficult but essential, and model exfiltration succeeds through legitimate queries despite intact standard controls — rate limiting helps. Every compromise type therefore has a detection subsection, and 7.5 bundles logging and monitoring. The structure of the standard has no dedicated section on incident handling; in our view, the ISMS incident management needs three additions: an AI flag for incidents, reporting channels to model providers, and detection rules for query patterns, tool calls and output anomalies.

The real-world operational cases show that the output path is an attack surface: EchoLeak (CVE-2025-32711, CNA CVSS 9.3) allowed internal M365 data to be exfiltrated via Copilot output through a zero-click injection — fixed in May 2025, with no known exploitation; ForcedLeak used an expired allowlist domain in Salesforce Agentforce to exfiltrate CRM data; the Claude Code GitHub Action read environment variables outside the sandbox after an injection in issue text. In all three cases, in our assessment, output filters, allowlists and tool-call logging from 6.8.4, 6.10.4 and 7.5 would have hindered the exfiltration or made it visible. In the financial sector, there is also the action plan that ECB Banking Supervision expects from significant institutions by 31/10/2026 — including logging and continuous verification of APIs and service accounts, although with a view to AI as an attack tool, not to the 27090 threats.

Logging under ISO/IEC 27002 8.15 and RTS RMF Art. 12 serves security; the record-keeping obligations under Art. 12 and Art. 26 AI Act are a separate regime — document both sets of requirements separately.

According to our FDIS-based analysis, 5.5 names pre-trained models, purchased datasets, MLOps tools and notebook platforms as supply chain elements. For the actors along the chain, 5.1 refers to controls A.6.2.3 and A.6.2.6 of ISO/IEC 42001, and Annex B, according to the DIS-based account, also lists supply chain attacks as an AI-specific variant of conventional attacks. The standard thus describes the chain from the data source through the model to the tooling environment, without favouring any particular sourcing form.

Three sourcing variants, three risk profiles

AI-BOM: what the bill of materials should contain

• Models with source, version, hash or signature and licence, including the base models behind fine-tunings.
• Datasets with provenance, approval and intended use (training, fine-tuning, retrieval, test).
• Packages and libraries with version pinning, hash verification and reconciliation against advisories.
• Tools, connectors and MCP servers of agentic systems together with their permissions.
• System prompts, prompt templates and retrieval sources — every change is a test trigger.
• Provider commitments under ISO/IEC 27002 5.19/5.20: use of your inputs for training, verification of pre-trained components, announcement of updates, testing against evasion and injection.

The joint Cybersecurity Information Sheet on AI/ML supply chain risks, listed by the NSA on 13.03.2026, recommends the AI-BOM as a complement to the SBOM. For financial institutions, the BaFin guidance note cites due diligence, SLAs and an exit with export of models, training data and metadata as practice (Chapter IV.2); in its Opinion of 06.08.2025, EIOPA expects insurers to obtain information and assurances from third-party providers. ISO/IEC 27090 supplies the attack vocabulary with which these requirements can be formulated concretely towards the provider.

Real-world cases 2024–2026: the supply chain as the preferred route

Two lessons: first, the infrastructure is responding — since 22.07.2026 PyPI has rejected new files for releases older than 14 days. Second, that is not enough: the October incident ran with a clean Git tag and Trusted Publishing enabled. For operators, this means version pinning with hash verification, an internal mirror with a release delay, short-lived secrets with limited scope — and the realisation that the credentials of AI tools have themselves become a target.

Three standards, three roles — and the sister standard 27091

SoA mechanics: 27090 as a control source

ISO/IEC 27001 permits, in 6.1.3, determining controls from any source; Annex A is a checklist, not a boundary. This is exactly where 27090 becomes connectable: the mitigations from 6.x.4 and Clause 7 can be cited as a source in the Statement of Applicability — for instance 6.8.4 for output filters or 6.9.4 against prompt injection — without a second management system. The control attributes under ISO/IEC 27002 4.2 are suitable for labelling them. No AI amendment to 27002:2022 is registered, nor is a revision of 42001:2023; the only new item is ISO/IEC AWI 42003 as an implementation guide to 42001.

1. 1
   ISO/IEC 27002 5.9 · 42001 A.4.3Inventory AI systems as assets

   Record per system the model source, training and fine-tuning data, retrieval sources, query access and agentic permissions.

2. 2
   ISO/IEC 27001 6.1.2 · 27090 Clause 6Include the nine types in the risk assessment

   Assess per system which compromise types and Annex B variants are realistic — with reference to sourcing variant and life cycle phase.

3. 3
   ISO/IEC 27001 6.1.3Select mitigations and cite 27090 in the SoA

   Document the selected mitigations with clause number, justify those excluded, record interactions under 7.2.

4. 4
   ISO/IEC 27002 5.19/5.20 · 42001 A.10.3Extend supplier assessment to model providers

   Apply the questionnaire from Chapter 13 of this page, store the answers in the AI-BOM, fix commitments on updates and testing contractually.

5. 5
   ISO/IEC 27090 5.7 · 42001 A.6.2.4Test and repeat on change

   Red teaming before deployment and after changes to the model, system prompt or retrieval source; feed reports back into the risk register and SoA.

What auditors will ask in future

On the certification landscape: the accreditation basis for 42001 certification bodies is ISO/IEC 42006:2025. On 22.10.2026, the DAkkS database showed no accredited certification body for ISO/IEC 42001, while 37 bodies are listed for ISO/IEC 27001; internationally, BSI Group (ANAB, UKAS, RvA) and DQS (ANAB), among others, obtained accreditations in March 2026. Anyone pursuing a 42001 certificate should check the accreditor of the chosen body individually.

Phrases such as “ISO 27090 certification”, “27090-compliant” or “audit against 27090” are factually wrong; the correct wording is: mitigations under ISO/IEC 27090 implemented in the ISMS under 27001 or in the AIMS under 42001.

Art. 15(5) AI Act: terms that 27090 fills in

The presumption route via Art. 42 deserves a close look: paragraph 2 refers to certificates under a Cybersecurity Act scheme, yet to date ENISA maintains no candidate scheme for AI. What is practically usable is paragraph 3, inserted by the Omnibus Regulation — high-risk AI within the scope of the CRA is deemed compliant with Art. 15 if the requirements under CRA Art. 12(1) are fulfilled and demonstrated in the EU declaration of conformity. CRA implementation thus carries the cybersecurity side of the AI Act as well; in our assessment, 27090 is the tool with which the requirements of CRA Annex I can be made concrete for the AI component.

A second point concerns roles: under Art. 25 AI Act, a deployer becomes a provider if it markets a high-risk system under its own name, substantially modifies it or changes its purpose; fine-tuning third-party models can cross this threshold, and since 27090 does not define the roles, the assignment of mitigations to your own role must be made explicit in the governance document. On the DACH status: there is no German version, DIN Media and SNV distribute the English original, no ÖNORM adoption is known, and the BSI does not mention the standard in any publication; the British adoption BS ISO/IEC 27090:2026 is announced for 31.10.2026. In May 2026, TÜV Rheinland advised against waiting for harmonised standards — after the rejected enquiry on prEN 18282, that applies all the more.

ISO/IEC 27090 does not create a presumption of conformity under the AI Act or the Cyber Resilience Act; that is the intended role of prEN 18282 from CEN/CENELEC JTC 21, still in draft. Standardisation request M/613 replaces M/593; whether it formally repeals or amends it is not publicly documented.

1. 1
   Days 1–14 · 27090 5.2 · 27001 6.1Clarify mandate, scope and target level

   Senior management confirms the initiative and appoints those responsible; the scope covers all AI systems including API use; derive the target level per system from high-risk classification, criticality and sourcing variant.

2. 2
   Days 15–45 · 27002 5.9 · 27090 5.6Inventory and threat model

   Build the AI inventory with AI-BOM; one threat model per system along the nine types and Annex B; record agents with their tools and permissions separately.

3. 3
   Days 46–90 · 27001 6.1.2/6.1.3 · 27090 Clause 6Risk assessment and SoA

   Assess risks, select mitigations from 6.x.4 and Clause 7, cite 27090 in the SoA; immediate measures: query budgets, logging of inputs, outputs and tool calls, version pinning with hash verification.

4. 4
   Months 4–6 · 27090 5.3, 5.5, 7.5–7.8Harden: zero trust, supply chain, operations

   Rebuild model and data access under 5.3, grant agent permissions just-in-time with scope and expiry; extend supplier assessment to model providers; put input and output filters, throttling and anomaly detection into operation.

5. 5
   Months 7–9 · 27090 5.7, 7.2, 7.4Test: red teaming and interactions

   Red-team the prioritised systems, test mitigations in combination, measure model performance alongside; anchor test triggers for model, prompt and retrieval changes in change management.

6. 6
   Months 10–12 · 42001 A.6.2.6 · 27001 management reviewDemonstrate effectiveness and close the cycle

   Evaluate monitoring and drift reports, feed test results back into the risk register and SoA, report metrics to senior management, derive the roadmap for the following year from the Gap Check.

Metrics the board understands

Objections — and how we respond

The three-tier maturity model from Abilene Academy serves as a plausibility check: a minimum after 30 days with inventory, threat models and logging of inference and tool calls; an established state after 90 days with provenance evidence, red team tests, supplier requirements and AI incident response; an advanced state with continuous monitoring, review of model changes and verification of agent permissions. The principle formulated there — treating every model artefact, every dataset, every prompt template and every tool permission as an attack surface — matches our reading of the standard.

ISO/IEC 27090 is a guidance standard without certifiable requirements. What is binding are the obligations from your own ISMS or AIMS as well as the AI Act, CRA, NIS2 and DORA. The roadmap is a VamiSec recommendation and not legal advice.