ISO/IEC 27090 names nine ways an AI system can be attacked, from data poisoning to prompt injection, and eight mitigations. This article explains each risk in plain terms, shows where it sits in ISO/IEC 42001 and the CERT-In Guidelines, and lists what to fix first.
Traditional security controls protect the servers, networks and code around an AI system. They do not protect the model itself, its training data, or the prompts that steer it. ISO/IEC 27090:2026 fills that gap. It gives guidance on security threats that are specific to AI systems, and on how to reduce them.
ISO/IEC 27090 is guidance, so there is no certificate for it. Its value is that it names the attacks precisely. ISO/IEC 42001 then gives you the certifiable management system to show that you control them.
The nine AI security risks
| ISO/IEC 27090 clause | Risk | What it means | Example |
|---|---|---|---|
| 6.2 | Data poisoning | Training or reference data is altered so the model learns the wrong behaviour | A document slipped into a knowledge assistant’s corpus changes the answers staff receive |
| 6.3 | Evasion | Inputs are crafted so a working model gives a wrong answer | A fraud model is beaten by splitting one large payment into many small ones |
| 6.4 | Membership inference | An attacker learns whether a person’s record was in the training data | Precise confidence scores reveal who was in the training set |
| 6.5 | Model exfiltration | The model is stolen, or rebuilt from many queries | A partner reconstructs a fraud model by scoring crafted transactions |
| 6.6 | Model inversion | Sensitive training inputs are recovered from outputs | A document reader reveals details from the identity papers it was trained on |
| 6.7 | Direct model poisoning | The model file, weights or code are tampered with | An unverified vendor model update reaches production |
| 6.8 | Sensitive model output | The model reveals data it should not, including hidden instructions | A chatbot shows one customer another customer’s details |
| 6.9 | Prompt injection | Instructions hidden in the input override the system’s instructions | A refund agent obeys text planted in a record its tool returns |
| 6.10 | Output carries an attack | The model’s output attacks the next system | An extracted field is written into a database and runs as a command |
The eight mitigations
Clause 7 of ISO/IEC 27090 groups the defences into eight mitigations:
- Choose mitigations together. One control can weaken another, so record the trade off.
- Keep controls continuous. The same checks apply from development to operation, including prompt and corpus changes.
- Plan for decay. Models and defences weaken over time, so re-test on a schedule.
- Log and monitor. Record input, output, user, time and model version.
- Protect the build environment. Guard training data, code and model files where they are built.
- Detect and filter inputs. Catch inputs designed to attack the model.
- Throttle. Limit query rate and volume to stop extraction and abuse.
- Keep models small. A smaller, narrower model leaks less.
Where this fits with ISO/IEC 42001 and CERT-In
ISO/IEC 42001 already expects AI security threats to be handled. The Annex B guidance for controls A.6.2.3 and A.6.2.6 (B.6.2.3 and B.6.2.6) names data poisoning, model stealing and model inversion. Annex D points to ISO/IEC 27001 for security controls. An integrated AIMS and ISMS can carry the ISO/IEC 27090 mitigations in one Statement of Applicability.
The CERT-In AI Security Auditing Guidelines of November 2026 list the AI tests an auditor runs. They include adversarial robustness, model extraction, data poisoning detection, prompt injection, supply chain scanning and AI privacy attacks. Each one lines up with a risk in ISO/IEC 27090. The Guidelines name ISO/IEC 42001 as their primary alignment standard, so the same evidence serves both.
Our ISO/IEC 27090 map links every risk to ISO/IEC 42001, ISO/IEC 27001, the CERT-In Guidelines, the OWASP Top 10 for LLMs and MITRE ATLAS.
What to fix first
- Map your AI assets. List each AI system with where its data, model, prompts and outputs live.
- Threat model each system. Check it against the nine risks above.
- Lock the supply chain. Verify the origin and integrity of every model and dataset you buy.
- Test, do not assume. Add prompt injection, poisoning, extraction and inversion tests to your VAPT.
- Guard both ends. Filter attack inputs, and validate outputs before the next system uses them.
- Log, throttle and re-test. Keep logs, rate limit scoring endpoints, and re-test as defences decay.
- Prove it under an AIMS. Record threats and controls in your ISO/IEC 42001 Statement of Applicability.
Frequently asked questions
Can we get certified to ISO/IEC 27090?
No. It is guidance. Use it inside an ISO/IEC 42001 or ISO/IEC 27001 programme, which can be certified.
Does ISO/IEC 27090 apply if we only use AI from vendors?
Yes. Prompt injection, sensitive output and supply chain risks apply to bought AI too. Your controls then sit in supplier due diligence, configuration, input and output filtering, and monitoring.
Is the OWASP Top 10 for LLMs enough?
It is a useful testing list for language models. ISO/IEC 27090 also covers classic machine learning attacks such as evasion and membership inference, and it links them to a management system.
Want to know where you stand? Try the free ISO/IEC 42001 gap check, which covers the nine attacks above in its optional AI security step. For an auditor’s view, start with an ISO/IEC 42001 gap assessment, which includes AI security against ISO/IEC 27090, or see our ISO/IEC 42001 consulting.