ISO 27001 and ISO 27090 implemented together — AI security in one ISMS

ISO/IEC 27001 is a requirements standard: it specifies what an information security management system must achieve, which is why it can be certified. ISO/IEC 27090 is a guidance standard: it describes which threats specifically affect AI systems, how to recognise them and how to defend against them. It does not call for a management system of its own; instead, it builds on the established practice of ISO/IEC 27001 and 27002 — two sentences in its principles section, worded as requirements, call for information security controls to be implemented on a risk basis and for AI-specific compromises to be considered across the entire life cycle.

Two anchor points carry the entire model

First, the risk assessment: the nine compromise types are assessed for every AI system in scope — in the same register and with the same methodology as all other information security risks. Second, the Statement of Applicability: ISO/IEC 27001 accepts controls from any source and requires a comparison with Annex A. The mitigation guidance of ISO/IEC 27090 thus becomes ISMS controls that are implemented, monitored, audited and examined as part of the certification audit.

• No second management system, no second risk methodology, no second document control
• Every measure exactly once, mapped multiple times — to Annex A, ISO/IEC 27090 and, where needed, ISO/IEC 42001 or the EU AI Act
• Internal audit, management review and certification audit also cover the AI measures
• Organisations without an ISMS build it and the AI profile in one project

Separate analyses lead to duplicate interviews and contradictory results. That is why we examine every requirement in clauses 4 to 10 and every relevant Annex A control just once — assessing at the same time whether its AI-specific extension is covered. In addition, we look at the AI-specific content of ISO/IEC 27090 that has no direct counterpart in ISO/IEC 27001: the nine compromise types, zero trust for models and agents, red teaming, interactions between measures and the decline in their effectiveness over time.

1. 1
   Scoping and context

   Kick-off with management and the ISMS team: goals of the initiative such as a certificate, customer requirements or the EU AI Act, provisional scope, interested parties with AI-related requirements.

2. 2
   AI inventory

   Record all AI systems — developed in-house, operated in your own tenant, used as an API or SaaS, or embedded in standard software; cross-checking against procurement, licence records, code repositories and network data uncovers shadow AI.

3. 3
   Document review

   Policy, risk methodology, risk register, Statement of Applicability, process descriptions, supplier assessments and existing AI policies.

4. 4
   Interviews and sampling

   CISO and ISMS team, IT operations, ML engineering and data science, software development, procurement, data protection and business units; technical sampling of access rights to models and data, logging, and input and output filters.

5. 5
   Rating by maturity level

   Each requirement is rated on four levels from “Not in place” to “Effective & verified” — twice: for the ISMS requirement and for its AI-specific extension.

6. 6
   Gap register and management summary

   Gaps with risk, effort, owners and priority; heat map by clause and by AI system; the ten most important gaps for management.

What the gap analysis delivers

• First version of the AI inventory with owners and criticality
• Gap register ISO/IEC 27001 × ISO/IEC 27090 with maturity levels
• Relevance rating of the nine compromise types per AI system
• Heat map and management summary with priorities and a rough effort estimate
• Recommendation on scope and certification path

The basis is the risk assessment: for each AI system in scope, the relevant compromise types are rated according to likelihood and consequences. Risk treatment then selects measures — from Annex A, from ISO/IEC 27090 or derived in-house — and compares them against Annex A so that no necessary control is overlooked. The result is an extended Statement of Applicability that states the source, justification and implementation status of every measure.

Two routes into the Statement of Applicability

Prioritise instead of doing it all at once

• No-regret measures first: AI inventory, owners, access protection, logging, usage rules for generative AI
• Then by risk: the most critical AI systems and the compromise types rated high
• Take deadlines into account: customer audits, the next surveillance audit, high-risk obligations under the EU AI Act from December 2027
• Have residual risks formally accepted by the risk owners — not by the project team

ISO/IEC 27001 requires changes to the ISMS to be carried out in a planned manner — and the AI extension is such a change; good practice is to define the purpose, potential consequences, resources and responsibilities in advance. This protects an existing certificate, because the ISMS remains functional throughout the restructuring, and gives a build from scratch a clear structure. The concept covers project organisation, work packages, dependencies, budget, communication and metrics.

Roadmap in waves

1. 1
   Wave 0 · Weeks 1–4Mandate and immediate actions

   Confirm the scope, complete the AI inventory, appoint owners, publish usage rules for generative AI, clean up access to models and data, switch on logging for the most critical systems.

2. 2
   Wave 1 · Months 2–4Governance and methodology

   Adopt the information security policy and the AI security policy, launch the risk treatment plan from phase 2, define supplier requirements.

3. 3
   Wave 2 · Months 3–8Technical measures

   Zero trust for data, models and agents, input and output controls, protection of the development environment, monitoring and throttling, red teaming of the most critical systems.

4. 4
   Wave 3 · Months 6–10Migration and training

   Migrate processes and data, deliver target-group-specific training, track metrics, collect evidence.

5. 5
   Wave 4 · Months 9–12Verify and decide

   Internal audit, corrective actions, management review and the decision on the certification audit.

The timings are orientation values from projects for a combined build from scratch with a manageable number of AI systems. With an existing, certified ISMS, much of waves 1 and 4 is not needed — the AI extension can then often be incorporated by the next surveillance audit.

Metrics for steering

• Share of AI systems with an owner, a risk assessment and an entry in the Statement of Applicability
• Share of critical AI systems with inference logging and monitoring
• Open findings from red teaming and audits by age and severity
• Training coverage per target group
• Schedule adherence of work packages against the roadmap

On the organisational side, implementation starts with rules that affect everyone: the policy extended to cover AI, usage rules for generative AI, the classification of training, prompt and output data, and a change procedure that treats model changes, retraining and changes to system prompts or retrieval sources like software changes. On the technical side, implementation follows the compromise types that were rated high in the risk assessment.

Zero trust as the common thread

ISO/IEC 27090 carries over to AI the zero trust principles that ISO/IEC 27002 describes for secure system architectures: access to training data, models and retrieval sources is individually authenticated and authorised, AI applications are given clear boundaries, actions by AI agents are checked individually, permissions are granted only for the task at hand and for a limited time, and system behaviour is continuously monitored. These principles run through all of the standard’s mitigation guidance.

Evidence to start collecting now

• Approved, versioned policies and usage rules
• Configurations and permission concepts for models, data and agents
• Logging and monitoring evidence with sample analyses
• Red teaming and acceptance test reports with remediation of findings
• Change tickets for model changes and retraining, including revalidation

Migration takes place on two levels. At the process level, the existing ISMS processes take on the AI cases, rather than a separate AI process universe emerging alongside the ISMS. At the data level, registers, measures and evidence are transferred from spreadsheets, wikis and legacy tools into a consolidated data model in which every measure exists exactly once and points to several frameworks.

Data migration in five steps

1. 1
   Stocktake

   Which registers, lists of measures, evidence and audit findings exist where — and in what quality?

2. 2
   Target data model

   One model for assets, risks, controls, evidence and suppliers, with multiple mappings to ISO/IEC 27001, ISO/IEC 27090 and, where needed, ISO/IEC 42001, the EU AI Act, NIS2 or DORA.

3. 3
   Clean-up

   Merge duplicates, add owners and validity periods, resolve orphaned measures — not every legacy item deserves to be migrated.

4. 4
   Trial run and sign-off

   Test migration with spot checks, sign-off by the business owners, reconciliation of record counts.

5. 5
   Cutover and archive

   Cutover date, brief parallel operation, archiving of legacy data in line with retention obligations — the evidence history must be preserved for the next audit.

The content is derived from the compromise types and the measures defined in phase 2 — which is why it differs markedly from role to role. A one-size-fits-all course misses the mark both for executive management, which has to evaluate risks and approve resources, and for ML engineering, which is expected to prevent specific attacks on data and models.

Proving effectiveness

• Competence profile per role: target vs. actual
• Attendance records and short knowledge checks
• Practical evidence such as passed exercise scenarios
• Metrics in the management review: training coverage per target group, reported anomalies

ISO/IEC 27001 requires internal audits at planned intervals, an audit programme covering frequency, methods, responsibilities and reporting lines, and auditors who are objective and impartial. Guidance on this is provided by ISO 19011 for auditing management systems and ISO/IEC 27007 for ISMS audits. The audit criteria are ISO/IEC 27001 and the organisation’s own requirements — for the AI measures, that means the Statement of Applicability. ISO/IEC 27090 is not used as audit criteria; it takes effect through the measures you have adopted from it.

Typical AI-related audit questions

• Are all AI systems in production listed in the inventory — and does the inventory match procurement and network data?
• Is there a current risk assessment covering the relevant compromise types for every AI system in scope?
• Do access rights to models, training data and retrieval sources match the permission concept? Sample check of the permissions.
• Are inputs and outputs, model version and tool calls logged and analysed? Sample check of the logs.
• Was the last model change preceded by testing and revalidation? Sample check of the change tickets.
• Have red teaming findings been addressed and tracked?
• Have model providers been assessed and contractually bound?

ISO/IEC 27001 specifies what top management must review at planned intervals: the status of actions from previous management reviews; changes in internal and external issues and in the needs of interested parties; feedback on information security performance, including nonconformities, measurement and audit results and the achievement of objectives; feedback from interested parties; the results of the risk assessment and the status of risk treatment; and opportunities for improvement. The outcome is a set of documented decisions.

Decisions that should be in the minutes

• Risk appetite for AI and acceptance of residual risks for the most critical systems
• Resources for the next waves of the roadmap
• Scope adjustments for new AI systems
• Go or no-go for the certification audit
• Objectives and metrics for the next cycle

1. 1
   Selecting the certification body

   Choose an accredited body — in Germany, one accredited by DAkkS, the national accreditation body — and agree on scope, sites and audit duration. The requirements for certification bodies are set out in ISO/IEC 17021-1 and ISO/IEC 27006-1.

2. 2
   Stage 1 audit

   Review of the documentation and of certification readiness: scope including AI systems, risk assessment, Statement of Applicability, planning and performance of the internal audit and management review.

3. 3
   Stage 2 audit

   On-site assessment of effectiveness: interviews, walkthroughs and sampling — for AI systems, for example, authorisation concepts, logs, test reports and change records.

4. 4
   Corrective actions and decision

   Nonconformities are resolved within the deadlines set by the certification body; the body then decides on certification.

5. 5
   Certificate and cycle

   The certificate is valid for three years; surveillance audits take place in the following years, then recertification. New AI systems are added via the scope and the Statement of Applicability.

What the certificate says — and what it does not

The certificate attests to an ISMS in accordance with ISO/IEC 27001 for a defined scope. If that scope includes the AI systems, their security is part of the certified management system. The certificate does not support the statement “certified to ISO/IEC 27090”, and that statement must not be implied in communications either. The accurate wording is: “ISMS certified to ISO/IEC 27001; the measures for our AI systems are guided by ISO/IEC 27090.”

Optional: combined audit with ISO/IEC 42001

Organisations that also want to demonstrate how they manage AI as a whole — impact assessment, responsibilities, life cycle, data quality — can integrate an AI management system in line with ISO/IEC 42001. Both standards follow the same harmonised structure, and combined audits are possible. Please note: on 22 October 2026, no DAkkS-accredited certification body for ISO/IEC 42001 was listed in Germany; offers based on accreditation by other accreditation bodies should be checked individually.

Seven mistakes we often see

• A second register or a separate AI management system alongside the ISMS — duplicate maintenance, contradictory assessments
• ISO/IEC 27090 ticked off as a checklist instead of prioritised through the risk assessment
• Shadow AI in standard software and SaaS overlooked
• Protection only via prompt rules instead of permissions, approvals and isolation
• No logging of inference — incidents go unnoticed, audits lack evidence
• Migration shortly before the audit, so the evidence history is lost
• Advertising “ISO 27090 certified” — misleading and actionable under unfair competition law

Success factors

• Visible top-management mandate with a risk appetite for AI
• An owner for each AI system in the business unit, not just in IT
• One data model, multiple mappings
• Early no-regret measures for quick impact
• Red teaming as evidence of effectiveness
• Training by target group, not one-size-fits-all