Lesson 2 of 10 · 12 min read
Why AI systems need their own security guidance
Last updated:
AI systems need dedicated security guidance because their behaviour is learned from data rather than written in code, their inputs are open-ended, and they introduce new assets: training data, model parameters, prompts and outputs. ISO/IEC 27090 applies confidentiality, integrity and availability to each of these assets across the AI life cycle.
In this lesson you will learn to
- 01
Explain how an AI system differs from a conventional IT system from a security point of view
- 02
Name the assets that ISO/IEC 27090 protects
- 03
Apply confidentiality, integrity and availability to each AI asset
- 04
Describe what clause 5 of the standard expects
What changes when a system learns
A conventional application behaves as its code says. Security teams review that code, validate inputs against fixed rules, reproduce failures and fix them. An AI system behaves as its training data taught it. The behaviour is statistical, the inputs are open-ended text, images or documents, and a failure may not reproduce the second time the same input is sent.
That shift moves the attack surface. An attacker no longer needs to break into a server to change what a system does. Influencing the data the model learns from, crafting the input it answers, or reading what it reveals in its output can each achieve the same effect without touching the infrastructure at all.
| Property | Conventional IT system | AI system |
|---|---|---|
| Where behaviour comes from | Code that can be reviewed | Data the model learned from, which an attacker can influence |
| Inputs | Validated against fixed rules | Open-ended: text, images, documents, retrieved web content |
| Failures | Reproducible and testable | Statistical and hard to reproduce |
| Assets | Code, databases, infrastructure | Plus training data, model parameters, prompts, outputs |
Infrastructure controls remain necessary. They are no longer sufficient, because the data, the model and the outputs are now targets in their own right.
The assets ISO/IEC 27090 protects
The standard organises its thinking around the asset an attack hits first. Five assets recur throughout the document: training and test data, the model itself, the inputs and prompts the system receives, the outputs it produces, and the service or pipeline that runs it. Each asset can be attacked on each of the three classic security objectives.
| Asset | Confidentiality | Integrity | Availability |
|---|---|---|---|
| Training and test data | Personal or proprietary records in the sets exposed | Poisoned or altered records | Data sets lost or unusable |
| Model | Parameters stolen or copied | Backdoored or tampered weights | Model unavailable or degraded |
| Inputs and prompts | User inputs exposed | Injected instructions | Input channel flooded |
| Outputs | Sensitive content revealed | Wrong or manipulated results | Outputs blocked or delayed |
| Service and pipeline | Configuration and keys leaked | Pipeline code altered | Denial of service on inference |
Clause 5: applying information security to AI
Clause 5 of the standard is titled, in substance, the application of information security to AI systems. It takes the familiar objectives of confidentiality, integrity and availability and shows how each applies to the AI assets above, at every stage of the life cycle. It points the reader to ISO/IEC 27002 for the baseline controls and to ISO/IEC 42001 for the management system that governs AI.
The practical expectation is simple to state and demanding to meet: apply the ISO/IEC 27002 controls to every one of these assets, and consider the AI-specific attacks at every stage from inception to retirement. An organization that has classified its databases but never classified its training sets, or that logs access to servers but not queries to a model, has a gap that clause 5 makes visible.
Where the exposure really sits
Teams instinctively look for risk inside the model. In production the model is rarely the weakest point. The exposure sits in what the system can read and what it is permitted to do. A retrieval system that indexes documents without carrying their access permissions will answer questions with material the person asking should never see. An agent granted broad credentials will eventually take an action nobody intended, because the instruction it followed arrived inside content it retrieved.
ISO/IEC 27090 reflects this in two ways. It treats retrieval data in production as needing the same protection as training data, and it treats the authority given to an AI system, especially an agent that calls tools, as something to be scoped, logged and gated by human approval for consequential actions.
Predictive and generative AI
The standard distinguishes predictive AI, which classifies, scores or forecasts, from generative AI, which produces text, images or actions. The distinction matters because the threats differ. Evasion attacks, which craft inputs that cause a wrong classification, are the signature attack on predictive systems. Prompt injection, sensitive output and output containing injection attacks exist mainly in generative systems.
Most organizations run both. A recruitment screening model is predictive; a staff knowledge assistant is generative. The threat catalogue tags every threat with the type of AI it concerns, so an assessment can skip what does not apply.
Key terms
- Confidentiality
- The property that information is not made available to unauthorised individuals, entities or processes.
- Integrity
- The property of accuracy and completeness; for an AI system, that data, model and outputs have not been tampered with.
- Availability
- The property of being accessible and usable on demand by an authorised entity.
- Predictive AI
- AI that classifies, scores or forecasts from input data, such as a fraud model or a screening model.
- Generative AI
- AI that produces new content, such as text, images or code, in response to prompts.
In one paragraph
AI systems learn their behaviour from data and answer open-ended inputs, so attackers can target the data, the model and the outputs without breaching the infrastructure. ISO/IEC 27090 identifies five assets, training and test data, the model, inputs and prompts, outputs, and the service, and applies confidentiality, integrity and availability to each. Clause 5 expects ISO/IEC 27002 controls on every asset and AI-specific threats considered at every life-cycle stage.
Lesson 2 quiz
Five questions. Score 4 or more to mark the lesson complete. Each answer shows an explanation, so a wrong answer teaches as much as a right one.
Questions people ask
- Does ISO/IEC 27090 replace existing security controls?
- No. It assumes the ISO/IEC 27002 controls are in place and adds the AI-specific threats and mitigations on top. Access control, logging, supplier management and incident response still apply; the standard extends them to new assets.
- Which assets does ISO/IEC 27090 protect?
- Training and test data, the model, inputs and prompts, outputs, and the service or pipeline that runs the system. Each can be attacked on confidentiality, integrity or availability.
- Why does the standard treat retrieval data like training data?
- Because a generative assistant will restate whatever it is given at run time. Documents fed to a model through retrieval can leak through its answers just as memorised training data can, so they need the same access control and classification.
Shahzad Asghar
Senior IT Strategy and Portfolio Officer at UNRWA, with more than twenty years building and securing data and AI systems across UN agencies. He holds the CISM and CISSP security certifications and writes on AI governance, AI security and assurance, and digital transformation. Connect on LinkedIn.
This course is an independent educational resource by Shahzad Asghar. It is not affiliated with, endorsed by or published by ISO or IEC. ISO/IEC 27090:2026 is copyrighted and is sold through the ISO Store and national standards bodies; this course summarises it and does not reproduce its text. Last reviewed: .