Lesson 10 of 10 · 15 min read
Implementing ISO/IEC 27090 in your organization
Last updated:
Implementing ISO/IEC 27090 starts with an inventory of every AI system and AI feature, including those inside vendor software. The existing ISO/IEC 27001 risk assessment is then extended with AI assets and the twelve threats, gaps are mapped to ISO/IEC 27002 controls, and priority controls are applied: prompt injection defences, data provenance, logging and endpoint protection. A six-month roadmap with named owners and a quarterly review cycle completes the adoption.
In this lesson you will learn to
- 01
Describe the inventory-first approach and the risk tier rule
- 02
Extend an ISO/IEC 27001 risk assessment with AI assets and threats
- 03
Map ISO/IEC 27090 themes to ISO/IEC 27002:2022 controls
- 04
Use the four templates and the six-month roadmap, and state the limits of the standard
Start with the inventory
Nothing in the standard can be applied to a system the organization has not listed. The first step is a register of every model, assistant, vendor AI feature and data pipeline, with its purpose, AI type, source, data used and classification, exposure, owners and risk tier. The register must include AI features inside purchased software, because most AI in an organization arrives that way, and shadow AI found through expense records and network data.
A simple risk tier rule keeps the register useful. High: personal or confidential data, external exposure, or decisions about people or money. Medium: internal use with confidential data. Low: public data and no decisions. The tier decides which controls apply and which systems are assessed first.
Extend the existing risk assessment
The standard and its reviewers agree on the method: extend the ISO/IEC 27001 risk assessment rather than build a parallel AI process. Add training data, models, pipelines, prompts and retrieval stores as assets. Add the twelve threats as threat sources. Score likelihood and impact per system, record existing controls and gaps, and decide treatments with owners and dates.
A workable scoring rule: likelihood times impact on one-to-five scales; fifteen or more is treated before go-live, eight to fourteen within the quarter, below eight is accepted with a recorded decision. Reassess on retraining, vendor version change, new data source, new tool connected, incident, or at least annually.
Mapping to ISO/IEC 27002:2022
Most of the work is extending the scope of controls that already exist. The table shows where each ISO/IEC 27090 theme lands in ISO/IEC 27002:2022 and what is genuinely new.
| ISO/IEC 27090 theme | ISO/IEC 27002:2022 control | What is new for AI |
|---|---|---|
| AI asset inventory | 5.9 Inventory of information and other associated assets | Models, data sets, prompts and pipelines as asset types |
| Threat identification | 5.7 Threat intelligence; ISO/IEC 27001 clause 6 risk assessment | Twelve AI threats; asset and objective tagging |
| Supplied models and data | 5.19 to 5.21 Supplier relationships and ICT supply chain | AI bill of materials; backdoors survive fine-tuning |
| Logging and monitoring | 8.15 Logging; 8.16 Monitoring activities | Prompts, outputs, model and template versions, tool calls |
| Secure development | 8.25 Secure development life cycle; 8.31 Separation of environments; 8.4 Access to source code | Notebooks, checkpoints and retrieval stores as protected assets |
| Architecture and access | 8.27 Secure system architecture; 8.5 Secure authentication; 8.20 Networks security | Rate limiting, output limiting, per-client baselines on inference endpoints |
| Testing | 8.29 Security testing in development and acceptance; 8.8 Technical vulnerabilities | Adversarial testing, red teaming, combined control evaluation, revalidation after retraining |
| Incident management | 5.24 to 5.28 Incident management | Playbooks for poisoning, leakage and injection-driven actions |
Four templates
Four documents carry the implementation. An AI system inventory register, one row per system, with the fields above. A threat and risk assessment, one per system, with one row per catalogue threat scored for that system. A control mapping and gap analysis that records each theme, the ISO/IEC 27002 control, status, evidence, action and owner, and doubles as the audit evidence package. And an AI security policy with a responsibility matrix: the CIO accountable for the inventory and life cycle, the security lead for assessment, controls, monitoring and incident response, product owners for individual systems, data owners for provenance, and legal and privacy consulted throughout.
A six-month roadmap
Four phases, then a quarterly cycle. The priority controls in phase three, prompt injection defences, data provenance, logging with versions, and rate and output limits, give the most risk reduction for the effort.
| Phase | Focus | Outputs |
|---|---|---|
| Days 0 to 30 | Inventory and owners | Register complete; owner per system; policy outline approved; systems tiered |
| Days 30 to 60 | Assess and find gaps | Risk assessment for high-tier systems; control mapping; supplier questionnaires sent; residual risk reported |
| Days 60 to 120 | Priority controls | Prompt injection defences; data provenance checks; logging with versions; rate and output limits |
| Days 120 to 180 | Test, monitor, evidence | Red team of high-tier systems; drift and anomaly monitoring live; incident playbooks and tabletop exercise; evidence package |
| Quarterly | Sustain | Reassess on change; review the inventory; report AI risk to the risk committee |
What the CIO and the security lead each own
The CIO owns the inventory as the starting point, an owner for every life-cycle stage, the treatment of models, data sets and MLOps tools as supply chain, the budget for monitoring and revalidation as an operating cost, and the link to governance through ISO/IEC 42001 and ISO/IEC 38507 and the risk committee.
The security lead owns the extension of the existing risk assessment, the ISO/IEC 27002 baseline with zero trust, logging and monitoring emphasised, the use of the catalogue in threat modelling and red teaming, the detection capability, the rule that model output and external content are untrusted in every integration, and incident response playbooks for AI-specific incidents, including the decision in advance on when a model is pulled from service.
Limits to keep in mind
The standard focuses on deliberate attacks; supplement it with ISO/IEC 23894 and the organization’s incident history for accidental failures and insider misuse. It is not certifiable and gives no legal presumption; map to the EU AI Act or ETSI where a certifiable route is needed. It took four years to write and agents, tool use and new injection techniques will outrun it; pair it with living sources such as the OWASP Top 10 for LLM applications, MITRE ATLAS and vendor advisories. Reviewers also note loose use of terms such as threat, failure and compromise. None of this reduces its value as the reference; it shows where to supplement.
Buy the standard. This course summarises it; the implementation team needs the text to verify clause wording, Annex A and Annex B before the templates are finalised.
Key terms
- AI system inventory
- A register of every AI system and AI feature an organization builds or uses, with owner, data, exposure and risk tier.
- Gap analysis
- A comparison of the controls a standard expects with the controls in place, recording status, evidence and actions.
- Responsibility matrix
- A table assigning who is responsible, accountable, consulted and informed for each activity.
- Evidence package
- The documented controls, test results and decisions that let an auditor or regulator verify a claim.
- Zero trust
- An architecture that verifies every access and grants least privilege, applied here to data provenance and agent permissions.
In one paragraph
Implementation begins with an inventory and a risk tier rule, extends the existing ISO/IEC 27001 risk assessment with AI assets and the twelve threats, and maps gaps to ISO/IEC 27002:2022 controls, most of which already exist and only need wider scope. Four templates, an inventory register, a per-system risk assessment, a control gap analysis and a policy with responsibility matrix, carry the work through a six-month roadmap. The CIO owns inventory, life cycle and budget; the security lead owns assessment, controls, detection and incident response. The standard’s limits show where to supplement it.
Lesson 10 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
- Where should an organization start with ISO/IEC 27090?
- With an inventory of every AI system and AI feature, including those inside vendor software, each with an owner and a risk tier. Everything else in the standard is applied per system from that register.
- Do we need a separate AI risk process?
- No. The recommended approach is to extend the existing ISO/IEC 27001 risk assessment with AI assets and the twelve threats, so AI risk is managed through the same governance as everything else.
- Which controls give the most risk reduction first?
- Prompt injection defences, data provenance checks, logging with model and template versions, and rate and output limits on inference endpoints. They address the most likely attacks for the least effort.
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: .