← All insights ←

ISO/IEC 27090: What the new AI security standard delivers and where it needs the NIST Cybersecurity Framework

By · Published: 27 October 2026

CybersecurityAI GovernanceBoard of DirectorsRisk Management
ISO/IEC 27090: What the new AI security standard delivers and where it needs the NIST Cybersecurity Framework

In October 2026, ISO and IEC published ISO/IEC 27090. It deals with threats that are specific to AI systems. It was developed by ISO/IEC JTC 1/SC 27, the subcommittee that is also responsible for the ISO/IEC 27000 series. For each type of attack, the standard describes the consequences, how the attack can be detected and which mitigations are available. It is a guidance document; unlike ISO/IEC 27001 or ISO/IEC 42001, organisations cannot be certified against it.

At its core is a catalogue of twelve ways in which AI systems can be compromised; nine of them are covered in detail in the main body. They include the poisoning of training data, direct tampering with the model, and inputs that have been imperceptibly altered. The standard also covers reconstructing a model through its interface, drawing inferences about the training data, and prompt injection, where an attacker slips their own instructions into the system through the input text. Two annexes map the attacks to the life cycle of an AI system and to the assets affected, and show what classic attacks look like in AI systems.

Overview of the twelve ways to compromise an AI system under ISO/IEC 27090:2026, grouped by the assets training data, model, inputs and output.
Figure 1: Twelve ways to compromise an AI system under ISO/IEC 27090:2026, Tables 1 and 2. Author’s own illustration.

In my view, the most important statement for the board and executive management is tucked away in an unremarkable place. In the section on the poisoning of training data, the standard states that detecting poisoned data and models is still an open area of research. Today’s automated methods generally cannot reliably distinguish maliciously inserted data from harmless outliers. Anyone running an AI system therefore cannot rely on noticing a poisoning attack in time. This raises a question every board should ask: if we notice too late, which trusted state could we return to?

Why this concerns the board

The standard brings to light residual risks that today’s technology cannot reliably control. Whether a company uses a bought-in model whose training data it does not know, or lets an AI agent act on its own, therefore determines the risk it is prepared to carry. That decision forms part of the overall direction of the company, which the board cannot delegate (Art. 716a OR).

This is clearest when a model is bought in. Many AI systems are built on foundation models that were trained on large public data sets. These data sets can be poisoned without an attacker ever accessing the company’s own data. Whoever buys a model therefore also inherits the provenance of its training data. At the same time, many of the mitigations in the standard are aimed at the developer of a model, for example training with deliberately manipulated examples, or methods that make it harder to draw inferences about individual training records. Anyone using a language model as a cloud service cannot implement many of them. For the supply chain, the standard offers only brief pointers: contracts with the suppliers of data and models, the exchange of specifications, and the organisation’s own attack testing of delivered models. It leaves open what a buyer should ask for in concrete terms. FINMA already names dependency on model providers as a risk in its own right. The decision to buy a model rather than build it is therefore also a decision about dependency. That dependency is managed mainly through contracts, evidence and audit rights. Which of these the company insists on is a matter for the board.

The board may delegate implementation to executive management. It is not liable for damage caused by executive management if it can show that it selected, instructed and supervised them with the care required in the circumstances (Art. 754 OR). Only those who know what to ask can supervise. ISO/IEC 27090 provides an internationally agreed benchmark for this.

A certificate offers the board only limited support here. In June, in the article ‘In the AI Era, Certified Security Alone Is No Longer Enough’, I wrote that a certificate demonstrates conformity but says little about effectiveness against an adaptive attacker. With AI, there is an additional point: organisations cannot be certified against 27090. A certificate under ISO/IEC 27001 or 42001 attests to a management system; it does not state whether a particular model has been tested against these attacks.

I also expect the standard of care to align over time with standards such as this one. Now that these types of attack are described internationally, anyone who has to explain after an incident why they were not considered is likely to face a harder time.

Where the standard applies

Particularly relevant for boards are attacks that look like normal operation. A model can be rebuilt through ordinary queries, even when conventional security controls are working. The attacker does not break in; the attacker uses the system. Prompt injection works in a similar way, through documents or web pages that an AI system draws on as a source. The attacker’s instruction arrives with the content that the system itself retrieves.

The standard explicitly builds on ISO/IEC 27001 and 27002. AI-specific threats come in addition to the classic ones; the standard makes clear that classic security remains necessary but is not sufficient on its own. For governance, it refers to ISO/IEC 42001 and to ISO/IEC 38507 on the governance of AI use. It does not create a presumption of conformity with the EU AI Act. The harmonised standard intended for that purpose is still in draft.

The bridge to the NIST Cybersecurity Framework

Anyone managing their information security with the NIST Cybersecurity Framework 2.0 (CSF) faces a practical question: how does the new standard fit into the existing programme? To answer it, I mapped 27090 clause by clause to the six CSF functions: Govern, Identify, Protect, Detect, Respond and Recover. This is my own assessment, not a new set of rules. NIST is developing its own application of the CSF to AI in the Cyber AI Profile; a preliminary draft was published in December 2025.

The result shows a clear pattern. For Identify, Protect and Detect, 27090 offers detailed guidance. It extends the inventory with assets that are typical of AI: models, their parameters, training data and the tools used to prepare data. On detection, it is open about the limits, for example with manipulated inputs that humans can barely notice.

Respond and Recover, by contrast, have no dedicated clause. The relevant guidance is spread across the sections on individual types of attack. The standard provides for a remediation plan if training data or models have been tampered with. It recommends sanitising the affected data sets, retraining the model and checking the effectiveness of the protective measures before the model is used again. The surrounding process, with responsibilities, root cause analysis and communication, comes from the CSF.

Coverage of the six NIST CSF 2.0 functions by ISO/IEC 27090: high for Identify and Protect, high with open limits for Detect, medium for Govern, low and scattered for Respond and Recover.
Figure 2: How ISO/IEC 27090 covers the functions of the NIST CSF 2.0. My own assessment, not an official mapping.

The question of the trusted state

This is where the two frameworks meet. In the Recover function, the CSF requires the integrity of backups and other restoration assets to be verified before they are used. With classic systems, this is familiar ground. With AI systems it becomes harder, because a poisoned model can continue to function without attracting attention. Anyone who wants to replace it must either retrain with sanitised data or roll back to an earlier version. Both require data and models whose integrity has been established.

ISO/IEC 27090 provides the building block for this. It recommends establishing provenance for all critical components of an AI system, from the training data through the software dependencies to the configuration. This evidence should be cryptographically protected and supplemented by immutable logs of versions and deployments. Without this evidence, it is hard to show that an earlier state is intact.

A board can ask this question without technical expertise. If we found out tomorrow that our model had been tampered with for months, which data and models could we rebuild from, and how would we know they are intact?

Where the ISO standard goes beyond the CSF

Conversely, 27090 covers topics for which I found no direct counterpart in the CSF. The first is human oversight. The standard describes the out-of-the-loop phenomenon: people who are no longer actively involved in a task lose the ability to judge whether the results are correct and what effects they have. This is especially true when the only options are regularly ‘confirm’ and ‘override’, and confirming becomes a habit. The standard also names the well-known tendency to place too much trust in automated systems.

This matches a distinction I have drawn here several times. A person in the process is not in itself a control. Oversight only becomes effective when that person can judge the result on its merits and has the authority to change it.

The second is the permissions of AI agents. Under the standard, an agent should work under its own identity rather than inherit the user’s permissions. Its permissions should be tied to the task and expire once the task is complete. The standard gives the example of an expenses assistant that may read receipts and prepare drafts, while the employee confirms the submission.

The first edition addresses agentic systems with tool access in only a few clauses. The recommended logging covers input, output, user and model version, but not which tools an agent called. Whoever needs to reconstruct after an incident what an agent set in motion must close that gap themselves. Operators of such systems will find a starting point in the standard, but not yet a complete programme.

What remains with the board

The board does not need to know 27090 in detail. It should know whether executive management is familiar with it, and how it is integrated into the existing security programme.

Then there is the time factor. ISO/IEC 27090 states that models and protective measures lose effectiveness over time, and that measures based on training can interfere with one another. A check on a given date therefore answers the question of effectiveness only for that day.

Two questions for executive management follow from this. Which of our AI systems are inventoried with their model, training data and supplier, and for which of them can we establish provenance? And would we notice tampering, and if we did not notice it in time, which trusted state could we return to?

For a board, the value of 27090 lies in its open account of where detection reaches its limits. Where detection remains uncertain, a verifiably intact state becomes the most important fallback.

Technology can be delegated. Responsibility cannot.

Transparency note

Generative AI was used in a supporting role for research and editorial preparation of this article. The conceptual design, the selection and weighting of the content, the professional assessment, the final version of the text as well as the responsibility for all statements and conclusions lie with me.

Sources