Lesson 3 of 10 · 11 min read
The AI life cycle and who is responsible
Last updated:
ISO/IEC 27090 maps security threats to the AI life cycle defined in ISO/IEC 22989: inception, design and development, verification and validation, deployment, operation and monitoring, re-evaluation, and retirement. Threats enter at every stage, most of them during operation, and retraining reopens the window for data poisoning. The organization that puts an AI system in front of users owns the residual risk.
In this lesson you will learn to
- 01
Name the seven life-cycle stages the standard uses
- 02
Identify which threats enter at which stage
- 03
Explain why retraining and vendor updates are security events
- 04
Describe the responsibilities of providers, deployers and platform providers
Seven stages, from inception to retirement
ISO/IEC 27090 does not invent its own life cycle. It uses the stages defined in ISO/IEC 22989, one of its two normative references, so that the security view lines up with the AI management view in ISO/IEC 42001. The stages run from inception, through design and development, verification and validation, deployment, operation and monitoring, and re-evaluation, to retirement.
The point for a security team is that threats enter at every stage, not only once a system is live. Data poisoning happens during development and again during retraining. Model theft can happen from a build artefact before anything is deployed. Retirement is a stage too: a decommissioned model and its training data still need secure disposal.
| Stage | Security work | Threats that enter here |
|---|---|---|
| 1. Inception | Threat modelling begins; decide risk tier and owners | Decisions that create exposure later, such as choosing an untrusted model source |
| 2. Design and development | Data provenance, secure pipeline, supplier assurance | Data poisoning, backdoored supplied models, insecure development environment |
| 3. Verification and validation | Adversarial testing, red teaming, combined control evaluation | Evasion weaknesses found late or not at all |
| 4. Deployment | Artefact signing, configuration and key protection, access control | Model theft from artefacts, exposed configuration and keys |
| 5. Operation and monitoring | Logging, anomaly detection, rate limiting, output controls | Evasion, inference attacks, prompt injection, exfiltration, sensitive output |
| 6. Re-evaluation | Revalidate before redeploying | Retraining reopens poisoning; vendor updates change behaviour |
| 7. Retirement | Secure disposal of models, data and logs | Leakage from forgotten artefacts and backups |
Retraining and updates are security events
A conventional system that passed its security test stays tested until its code changes. An AI system changes when its data changes, when the vendor ships a new model version, or when it is fine-tuned. Each of those events can reintroduce a threat that was previously controlled: new training data can carry poisoned records, and a new vendor version can behave differently against the same controls.
The standard therefore treats re-evaluation as a stage with its own security work: revalidate controls before a changed system returns to service. In practice this means change management must recognise retraining, fine-tuning, new data sources, new tools connected to an agent, and vendor version changes as triggers for a fresh assessment.
Annex A of the standard maps each attack to the life-cycle stage and the asset it hits. Stage 5, operation and monitoring, carries the largest share of attacks; stages 2 and 6 carry the poisoning risk.
Provider, deployer and platform
The standard applies to organizations that develop AI systems and organizations that use them. In practice three parties share responsibility for any deployed system: the provider or developer of the model, the deployer or integrator that puts it to use, and the cloud or platform provider underneath both.
| Party | Typical responsibilities |
|---|---|
| Provider or developer | Model robustness and attack resistance; training data integrity and provenance; secure development environment; documentation of limits and known weaknesses |
| Deployer or integrator | Integration environment and API exposure; access control, data flows and use cases; monitoring, logging and incident response; validation and acceptance before go-live |
| Cloud or platform provider | Infrastructure and platform security; tenant isolation; platform logging; a shared responsibility matrix. Does not cover the deployer’s prompts, data or integrations |
Who owns the residual risk
Provider certifications and platform attestations stop at the platform layer. A cloud provider’s ISO/IEC 27001 certificate says nothing about the prompts, documents and tool permissions an organization configures on top of it. The deployer still owns integration security, data, access, monitoring and the acceptance decision.
The rule of thumb that follows from the standard: whoever puts the AI system in front of users or business processes owns the residual risk. That party must be able to show what threats were considered, which controls were applied, and who decided that the remaining risk was acceptable.
Key terms
- AI life cycle
- The stages an AI system passes through from inception to retirement, as defined in ISO/IEC 22989.
- Re-evaluation
- The stage in which a deployed system is reassessed after change, such as retraining or a vendor update, before it returns to service.
- Deployer
- The organization that integrates an AI system into its own processes and puts it in front of users.
- Shared responsibility
- The division of security duties between a platform provider, a model provider and a deployer; each covers its own layer.
- Residual risk
- The risk that remains after controls are applied; someone must accept it explicitly.
In one paragraph
ISO/IEC 27090 uses the seven life-cycle stages of ISO/IEC 22989 and maps threats to each. Poisoning enters during development and again at retraining; most other attacks concentrate in operation; retirement needs secure disposal. Providers, deployers and platforms each own a layer, but the deployer that puts the system in front of users owns the residual risk and must revalidate controls after every change.
Lesson 3 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
- Which life cycle does ISO/IEC 27090 use?
- The AI system life cycle from ISO/IEC 22989: inception, design and development, verification and validation, deployment, operation and monitoring, re-evaluation, and retirement.
- Why is retraining a security event?
- Retraining introduces new data, which can carry poisoned records, and changes model behaviour, which can defeat controls tuned to the previous version. The standard expects revalidation before a changed system returns to service.
- Does a cloud provider’s certification cover my AI application?
- No. Platform certifications cover the infrastructure and platform layer. The prompts, documents, integrations, access rules and monitoring that the deployer configures remain the deployer’s responsibility.
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: .