ISO/IEC 27090: what the new standard says about attacks on AI

Since October 2026 there is an ISO standard built around a single question: how do you attack an AI system, and what helps against it? ISO/IEC 27090:2026, first edition, drafted in the same subcommittee as ISO/IEC 27001 (ISO/IEC JTC 1/SC 27). 56 pages, six of them a bibliography with 115 references.

I read it cover to cover. The standard is a catalogue. Every type of attack gets the same grid: how the attack works, what breaks afterwards, how you notice it and how you contain it. It is sober, very technical in places and surprisingly honest in many more.

For small and mid-sized companies the most important message is not in the exotic attacks. It sits right at the front: an AI system is software first. If your information security is under control, a large part of the job is already done. The rest I put into context here, together with what you can do with it on Monday.

Guidance, not a certificate

ISO/IEC 27090 sets no requirements for a management system. It gives guidance. Nobody gets certified against it. If you want a certificate, you still go through ISO/IEC 27001 for information security or ISO/IEC 42001 for the AI management system. ISO/IEC 27090 is the reference book you keep next to them.

It is not entirely without obligation, though. The binding word “shall” appears exactly twice in the actual text, both times in clause 5.1. The established controls of ISO/IEC 27002 are to be implemented as far as your risk assessment calls for them. And the AI-specific compromises in the overview table are to be taken into account across the whole life cycle. Everything else is a recommendation.

For governance, the standard points to ISO/IEC 42001: a programme that inventories every AI system in the organization, analyses its risks and manages them (5.2). Its terminology comes from ISO/IEC 22989 and ISO/IEC 23053, the only two normative references. If you already run ISO/IEC 42001, ISO/IEC 27090 adds no new bureaucracy. It adds the substance your risk assessment has so far only named in broad strokes.

It gets interesting when you put the EU AI Act next to it. Article 15(5) requires high-risk AI systems to be protected against manipulated training data, poisoned pre-trained components, inputs designed to make the model err, and attacks on confidential data. That reads like a summary of clause 6 of the new standard. For high-risk systems under Annex III it applies from 2 December 2027, under Annex I from 2 August 2028 (Article 113 as amended by Regulation (EU) 2026/1744).

ISO/IEC 27090 still does not give you a presumption of conformity. It is not a harmonised standard. What it does give you is the language and the catalogue to show that you have thought about exactly these attacks and made decisions about them.

Nine attacks in the main text, six in the annex

Clause 6 describes nine types of attack, each in the same grid. Annex B adds six cases in which a conventional attack takes on an AI-specific twist. The overview in my own words:

Two things stand out. First, not every case needs an attacker. Confidential content in the output, or a leak of training or input data, can also come from a plain operating error (6.8, B.6, B.7). Second, the standard is honest where it hurts. By its own assessment, whether training data has been poisoned still cannot be detected reliably by automated means; it calls this an open area of research (6.2.3).

If you buy models rather than build them, clause 5.5 matters more than any single attack. Pre-trained models and third-party datasets can contain backdoors that only fire on a specific trigger. AI libraries can bring malicious code with them. And a model’s origin can be disguised. The standard recommends verified provenance, signed models and datasets, trusted repositories, regular scans of dependencies and tests for unexpected behaviour (5.5.4, 5.5.5).

For procurement, Annex B.3.3 names four points that belong in every specification: security requirements for data and model suppliers go into the contract, suppliers get security training, the model description is handed over properly, and the delivered model is attacked on purpose before use, known as red teaming. It is the same logic as a supplier audit for purchased parts, just with different inspection characteristics.

Two of its examples should resonate in any manufacturing company. In predictive maintenance, poisoned training means an impending failure is not flagged (6.2.2). And in a documented experiment, three barely visible stickers on the road were enough for a driver assistance system to misread the lane and steer into oncoming traffic (6.3.2). One number from Annex B sticks: there are inputs that cost a model up to thirty times the computing time and energy of ordinary ones (B.2.1).

The remaining annexes are tools. Annex A maps each attack to the life cycle and to the assets it hits: training data, model, parameters, inputs, outputs. Annex C covers federated learning, where the data stays on the devices or with the partners and only model updates travel.

Your knowledge base now counts as training data

The sentence with the biggest impact for companies that only use AI is in clause 7.6. If you give a language model documents from your own repository, known as retrieval augmented generation, you are steering the model’s behaviour. The standard draws the consequence: that repository needs the same protection as training data.

That turns an old habit upside down. In conventional IT the sensitive data lives in production, and development works with test data. With AI it is often the other way round, as 7.6 also notes: training needs real data, so the real data sits in the development environment. If you distributed your safeguards along the old pattern, with AI you are protecting the wrong side.

For your company that means two questions. Who can write to the repository your AI reads from? And can the AI show a user a document that this user could never open themselves? Clause 5.3 gives, as an example, an authorization check for every retrieved document, regardless of whether the application as a whole is approved.

In my own company an AI reads incoming purchase order PDFs from customers. On one large order with three price lines per item, it got 40 of 66 unit prices wrong. That was no attack, just a hard-to-read document. Since September the system takes not a single price from the PDF. The price always comes from our own database, and an item without a stored price is flagged in red.

What comes out of a document is a suggestion. What is in your database is what counts.

That rule protects against both: the reading error and the file in which someone has hidden an instruction in white text. This is exactly the line the standard draws. It advises first establishing whether unwanted behaviour is an attack at all (6.11.3.1), and it treats text from the model as untrusted as soon as the data behind it is untrusted (6.10.4). By the way, the standard also advises being sparing with technical details about your own AI systems in publications (6.11.2.5). That is why I write no more than these two paragraphs about our order system.

AI agents: permissions per task, with an expiry date

The standard is at its most concrete on agents, meaning AI systems that act on their own: sending emails, querying databases, running code. Clause 6.11.3.3 describes what matters. Permissions are granted for a task. They expire when the task is done. The agent has its own identity and does not simply inherit the rights of the person who starts it.

Applied to a quotation assistant in mechanical engineering: it may read the enquiry, read the price list and create a draft. It may not send anything. It has no access to payroll or to other customers’ files, even if the sales manager using it has those rights. The quote only goes out once a human has approved it.

Besides attacks and poor data, the standard names two causes of unwanted behaviour that have little to do with technology: users trust the output too much, and engineers give the system too much authority (6.11.3.1). No firewall helps against the second. Only a permission list short enough to fit on a sticky note does.

The standard is also honest about human oversight (6.11.3.2). Someone who clicks “Confirm” twenty times a day stops checking at some point. It describes this effect explicitly and advises keeping people actively involved in the process. An approval that is always granted is not oversight. It is a clicking sound.

What to do with it on Monday

The good news is in clause 5.1. Securing the software stack is often more effective than building expensive special defences against query-based attacks. If you worry about your model, secure the server holding the model files first. Lock the door first. Then think about the third-floor window.

• Create a list of all AI systems, with purpose, data sources and the person responsible (5.2).
• Log every use of AI: input, date, time, user, output and model version (7.5). Without the version you cannot reconstruct an incident later.
• Throttle queries per user. The point is to slow down the systematic probing someone uses to rebuild or trick a model; server load is a side issue here (7.8).
• Obtain models only from verified sources, check checksums and signatures, and load model files in a format that does not execute code, such as safetensors (5.5.5, B.4.3).
• Treat outputs like external inputs: validate, encode, never push them unfiltered into a web page or a downstream system (6.10).
• Protect the AI’s knowledge base with the same permissions as the original documents (5.3, 7.6).
• Test behaviour regularly against a fixed test set so that poisoning shows up before it has worked for weeks (6.11.3.5).

Two warnings from clause 7 belong on every project list. Safeguards can interfere with each other: a model trained against one type of attack can become more vulnerable to another (7.2). And safeguards wear out, just like the model itself (7.4). An AI is therefore never secured once and for all. It stays secure only as long as someone keeps measuring.

As an auditor, after reading this, the first thing I ask for is the log. If it records the model version, every incident can be traced. In ISO/IEC 42001 this attaches to controls A.6.2.6 and A.6.2.8, in ISO/IEC 27001 to A.8.15 and A.8.16. ISO/IEC 27090 now supplies the reason why none of this is optional for AI.

The new standard does not turn AI security into rocket science. It shows that most of it is craft you already know from information security. What is new is where the workpieces lie: in the training data, in the knowledge base, in the agent’s permissions. Clean up there, and you are more secure not because of a certificate, but because you know what your AI is allowed to do.