ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
EU AI Act Article 15 is the article that makes security a legal requirement for high-risk AI systems. It asks for an appropriate level of accuracy, robustness and cybersecurity throughout the system’s life, and it names specific AI attacks the system has to withstand: data poisoning, model poisoning, adversarial examples and confidentiality attacks. Meeting it means having a documented control, test and response for each.
This guide walks through what Article 15 requires, paragraph by paragraph, how its attack classes map to the controls in ISO/IEC 27090, the new route through the Cyber Resilience Act added in 2026, and the dates that now apply.
Free gap assessment
Which AI Act obligations do you actually owe?
Score what is already in force separately from the high-risk duties that now land in 2027, free.
Run the free EU AI Act gap assessment → or View premium report sample
Article 15 of Regulation (EU) 2024/1689 has five paragraphs. In our words:
| Paragraph | What it requires | Who it falls on |
|---|---|---|
| 15(1) | High-risk AI systems are designed and developed to reach an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently on all three throughout their life cycle | Provider |
| 15(2) | The Commission encourages benchmarks and measurement methods for accuracy and robustness | Commission |
| 15(3) | Accuracy levels and metrics are declared in the instructions for use | Provider |
| 15(4) | Resilience to errors, faults and inconsistencies, through technical and organisational measures, possibly redundancy and fail-safe plans; systems that keep learning after release must limit biased feedback loops | Provider |
| 15(5) | Resilience against unauthorised third parties trying to alter use, outputs or performance by exploiting vulnerabilities, with measures proportionate to the risk, and specifically against AI attacks | Provider |
Paragraph 5 is where cybersecurity becomes specific. It requires the technical solutions to include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks on the training data, on pre-trained components, through inputs designed to cause mistakes, and against confidentiality, as well as model flaws.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 54 AI risk scenarios, including the attacks on AI described in ISO 27090, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
The EU AI Act does not name a standard for this, and ISO/IEC 27090 does not mention the Act. But the attack classes in Article 15(5) line up closely with ISO 27090’s compromise types, which makes the standard a natural source of controls.
| Article 15(5) attack class | ISO 27090 compromise types | Example controls |
|---|---|---|
| Manipulating the training data set (data poisoning) | Data poisoning (6.2) | Dataset provenance and hashing, tamper-aware data quality checks, controlled training order |
| Manipulating pre-trained components (model poisoning) | Direct model poisoning (6.7); supply chain (5.5); backdoors (Annex B) | Supplier intake, signed models, safe model file formats, pre-deployment integrity gate |
| Inputs designed to cause mistakes (adversarial examples, model evasion) | Evasion (6.3); prompt injection (6.9) | Robustness testing, input validation and out-of-distribution detection, injection test libraries |
| Confidentiality attacks | Membership inference (6.4), model exfiltration (6.5), model inversion (6.6), sensitive output (6.8), model theft and data leaks (Annex B) | Output minimisation, throttling, data minimisation, encryption, access control on weights |
| Model flaws | Continuous validation (6.11.3.5); mitigation interactions (clause 7) | Protected test sets, validation schedules, portfolio testing after every change |
Article 15(5)’s five verbs, prevent, detect, respond, resolve and control, are worth taking literally. A provider that can show prevention controls but no detection or incident response for these attacks has only part of an answer. ISO 27090’s per-threat structure of detection and mitigation, plus logging and monitoring guidance, covers the full cycle.
Article 15(4) can look like a pure reliability requirement, but it overlaps with security. A system that keeps learning from its own operation is open to biased feedback loops, and it is also open to poisoning through operational input, which ISO 27090 calls out explicitly. Continuous validation against a protected test set serves both: it catches drift and it catches lasting attack effects. Unwanted-bias test runs do double duty in the same way, since a sudden shift towards unfair output can be the visible sign of poisoning.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, left the text of Article 15 unchanged but added a new paragraph to Article 42. Under Article 42(3), a high-risk AI system that falls within the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847) and meets the conditions of that Act’s Article 12(1) is deemed to comply with the cybersecurity requirements of Article 15.
For manufacturers of products with digital elements that embed high-risk AI, this means the CRA conformity work can carry the Article 15 cybersecurity requirement, within the limits of what the CRA declaration covers. It does not remove the accuracy and robustness parts of Article 15, and it does not help systems outside the CRA’s scope.
Article 42(3) sits beside an older route in Article 42(2): a high-risk AI system certified, or covered by a statement of conformity, under a cybersecurity scheme adopted under the Cybersecurity Act (Regulation (EU) 2019/881) is presumed to comply with Article 15’s cybersecurity requirements, to the extent the certificate covers them.
Article 15 sits in the section of the Act on requirements for high-risk AI systems. After the Digital Omnibus, those requirements apply:
Both dates were later than originally enacted. Check the current position before relying on them, because the timetable has already moved once.
No. Under the AI Act, presumption of conformity comes from harmonised standards (Article 40), common specifications adopted by the Commission (Article 41), and, for Article 15’s cybersecurity requirements specifically, the Cybersecurity Act and Cyber Resilience Act routes in Article 42(2) and 42(3). ISO/IEC 27090 is an international guidance standard, not a harmonised European standard, so following it does not by itself presume compliance with Article 15. What it gives you is a structured, recognised body of controls for exactly the attacks Article 15 names, and evidence that your choices were informed by it.
Article 15(5) explicitly reaches pre-trained components used in training, which pulls suppliers into scope. A provider building on a third-party model or dataset cannot evidence resilience against model poisoning without information from that supplier. Questions worth putting to them, and writing into the contract:
Answers that are missing or vague are themselves a risk factor for EU AI Act Article 15, because they leave a gap in the provider’s own evidence. ISO 27090’s supply chain guidance recommends contractual security terms, attention to exchanged specifications such as model cards, and red teaming of supplied models for this reason. See AI supply chain security.
A provider preparing for EU AI Act Article 15 should be able to show:
Article 15 is a design requirement on the high-risk system, so the obligation sits mainly with the provider. Deployers have their own duties elsewhere in the Act, including using the system in line with its instructions.
Article 15 covers high-risk AI systems. General-purpose AI models have their own obligations in the Act, including cybersecurity duties for models with systemic risk.
Article 15(5) does not use the term, but inputs designed to make the model make a mistake, and attempts to alter its use or outputs by exploiting vulnerabilities, describe prompt injection well. See our guide to prompt injection prevention.
ISO 42001 helps with the management system around a high-risk AI system; Article 15’s attack-specific security is closer to ISO 27090. Our ISO 42001 vs the EU AI Act comparison covers the governance side.
The attack list in Article 15(5) is short, and every item on it has an ISO 27090 subclause behind it. Start with the data poisoning attack and membership inference attack guides for two of the four classes, and the ISO 27090 overview for the rest.
Our ISO 27090 Toolkit includes a framework crosswalk mapping every ISO 27090 recommendation to EU AI Act Article 15, alongside ISO/IEC 27002, ISO/IEC 42001, NIST AI 100-2 and OWASP, plus the per-threat standards, test records and incident playbook an Article 15 evidence pack draws on. For the Act’s other high-risk obligations, see the EU AI Act Toolkit.
October 29, 2026
October 28, 2026
October 28, 2026
October 27, 2026
October 27, 2026