ISO/IEC 42001:2023 — scope and certification

ISO 42001 is a management-system standard. Auditors test how you govern AI over time, not whether a single document exists on audit day. This page covers the two artefacts that anchor every certification audit — the AIMS scope statement under Clause 4.3 and the Statement of Applicability — and walks through the Stage 1 / Stage 2 / surveillance / recertification cycle.

Quick decision

• You need to write the AIMS scope statement → Clause 4.3. Anchor it in your role under 4.1 and the interested parties under 4.2. Cover organisational functions, AI systems, and lifecycle stages.
• You need to decide which Annex A controls apply → build the Statement of Applicability from the AI risk and impact assessments (6.1.2 / 6.1.4). Annex A is informative; the SoA documents the selection.
• You are preparing for Stage 1 → focus on documentation completeness: scope, AI policy, risk and impact records, SoA, internal-audit programme, management-review minutes.
• You are preparing for Stage 2 → focus on operational evidence: control execution records, decisions, supplier evidence, corrective actions, surveillance signals.
• You already operate ISO 27001 → the Annex SL clauses (4–10) are shared; the AIMS-specific additions (5.2 AI policy, 6.1.2/3/4 risk + impact, Annex A AI lifecycle controls) sit on top of the existing ISMS.

TL;DR

• Scope (Clause 4.3) names organisational functions, AI systems and lifecycle stages — anchored in the organisation's role (Clause 4.1) and interested parties (4.2).
• Statement of Applicability records which Annex A reference controls the organisation has selected, the justification, the implementation status. ISO 42001 Annex A is informative — selection is risk-driven.
• Stage 1 = documentation review by an accredited certification body. Stage 2 = operational evidence audit. Surveillance annually for two years. Recertification at month 36.
• AI impact assessment (Clause 6.1.4) is the AIMS analogue to the EU AI Act Article 27 FRIA — distinct from the AI risk assessment (6.1.2) which looks at organisational risks.
• The constraint on time-to-certification is the evidence window — the AIMS has to run long enough for auditors to see real records of internal audit, management review and continual improvement.

Primary source

ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, Clauses 4.1, 4.2, 4.3, 6.1.2, 6.1.3, 6.1.4, 9.2, 9.3. Available via the ISO Online Browsing Platform. © ISO.

Scope you can defend (Clause 4.3)

In ISO work, scoping is not a formality — it is the contract with the auditor. The Stage 2 sampling plan flows from the scope statement.

A defensible AIMS scope statement is:

• Specific — names what is included and explicitly what is excluded. "All AI systems developed or operated by Division X" is verifiable; "AI systems in the organisation" is not.
• Role-anchored — references the organisation's role under Clause 4.1. The scope of a provider-role AIMS differs from a deployer-role AIMS; both can be in scope simultaneously when relevant.
• Operational — names accountable functions and which processes apply.
• Reviewable — describes how scope changes are approved and recorded (typically through the management review under Clause 9.3).

Practical questions to anchor the scope:

• Which AI systems (and which lifecycle stages) are inside the AIMS?
• Which organisational functions are in scope — product, platform, vendor management, risk, legal?
• Which third parties materially affect the AI systems — model providers, data providers, hosting and compute providers, downstream integrators?
• Which markets and stakeholders drive the obligations and risk tolerance the AIMS responds to?

Most teams structure the scope into an organisation-level AIMS layer (policy, roles, internal audit, shared controls) plus per-AI-system execution (controls, evidence, monitoring per system). That structure maps cleanly onto Modulos's OFF + MFF project pair (see Operationalizing in Modulos).

Statement of Applicability — the Annex A selection record

ISO 42001 Annex A is informative, not normative. The organisation selects which Annex A control objectives apply based on the AI risk and impact assessments under Clauses 6.1.2 / 6.1.3 / 6.1.4 and documents the selection in a Statement of Applicability.

A workable SoA captures, per control objective:

• inclusion / exclusion decision — applied, partially applied, or excluded;
• justification — the risk or impact that drove inclusion, or the explicit reason for exclusion;
• implementation status — implemented, in progress, planned;
• responsible function — who owns operation of the control;
• evidence reference — where the operational evidence is recorded.

Unlike ISO/IEC 27001 (where Annex A is normative and the SoA is mandatory under Clause 6.1.3 d), ISO 42001 frames Annex A as a reference set. In practice every accredited certification audit expects an SoA-equivalent record — the standard is risk-driven, and the SoA is how the organisation demonstrates that the risk assessment actually drove control selection.

Go deeper: Annex A and informative annexes.

The certification audit cycle

1

Stage 1 — documentation review

Auditor reads scope, AI policy, risk + impact records, SoA, internal audit, management review. Stage 1 findings closed before Stage 2.

2

Stage 2 — operational audit

On-site (or remote) audit of operational effectiveness. Auditor samples control execution, decisions, supplier evidence, corrective actions.

3

Certification decision

Certification body issues the ISO 42001 certificate based on the Stage 2 recommendation

4

Year 1 surveillance

Around month 12: sample of clauses + always: nonconformities, internal audit, management review, significant changes

5

Year 2 surveillance

Around month 24: same depth as year 1

6

Recertification

Around month 36: full audit at Stage 2 depth; new three-year certificate

The most important pattern: auditors sample operational reality (records, decisions, evidence) — not just the existence of policy documents. The AIMS has to operate, not just be written.

What auditors typically test

• AI governance scope, AI policy and AI objectives are defined and current (Clauses 4.3, 5.2, 6.2).
• Responsibilities and oversight are assigned and operating, not just defined (Clause 5.3, Annex A.3).
• AI risks are assessed, treated and re-assessed as systems change (Clauses 6.1.2 / 6.1.3, 8.2 / 8.3).
• AI impact assessments exist for in-scope systems and influence decisions (Clause 6.1.4, Annex A.5).
• Annex A controls in the SoA are actually executed — evidence exists, not just policy.
• Findings from internal audit (9.2) feed corrective actions (10.2) and continual improvement (10.1).
• Management review (9.3) inputs and outputs are recorded, including resourcing decisions.

The questions auditors ask themselves: Is this AIMS conformant with the standard? and Is it effective in achieving its objectives? Both have to be answered with operational evidence.

Governance loop

Four stations, one operating model.

Audit readiness loop

Certification readiness is an operating cadence.

Build

Implement controls and collect evidence

Test

Internal audit and monitoring signals

Review

Management review and decisions

Improve

Corrective actions and updates

The dashed arc marks restart — every cycle re-enters Build with what changed since the last pass.

How to operationalise scope + SoA in Modulos

Modulos models the AIMS scope + SoA against the OFF-10 / MFF-10 framework templates (clause-aligned ISO 42001) or OFF-7 / MFF-7 (legacy). The scope statement, Statement of Applicability and audit artefacts live as evidence on the relevant ORF / MRF requirements:

Requirement (OFF-10 / MFF-10)	Description	ISO 42001 clause
ORF-164	Determining the scope of the AI management system	4.3
ORF-165	AI management system	4.4
ORF-167	AI Policy	5.2
ORF-170	AI risk assessment	6.1.2
ORF-171	AI risk treatment	6.1.3
ORF-172	AI system impact assessment	6.1.4
ORF-184 / ORF-185	Internal audit + audit programme	9.2.1 / 9.2.2
ORF-186 / ORF-187 / ORF-188	Management review (process, inputs, outputs)	9.3.1 / 9.3.2 / 9.3.3
ORF-189 / ORF-190	Continual improvement + nonconformity and corrective action	10.1 / 10.2

The Statement of Applicability is recorded as control-level evidence on the Annex A requirements (ORF-191…ORF-194 for areas A.2–A.5 on OFF-10; corresponding ORF / MRF for the lifecycle and data controls). Modulos does not provide a dedicated SoA workflow surface — the SoA artefact is owner-authored and stored as evidence with versioning.

Audit pack

How four export types collapse into one shippable bundle.

Inputs

Project PDF export

Top controls (PDF exports)

Evidence files (attachments)

Key assets (Markdown exports)

Audit pack

Single shippable bundle

All four input types, versioned together, ready for the auditor.

Snapshot

Exports are snapshots. Keep scope stable before exporting — the bundle freezes whatever was in place at export time.

Freeze scope before generating audit packs

Exports are point-in-time snapshots. Freeze scope (and any framework-template version changes) before generating audit packs, so findings stay comparable across the surveillance cycle.

Cross-framework mapping (preview)

ISO 42001 element	Adjacent framework
Clause 4.3 AIMS scope	ISO 27001 Clause 4.3 ISMS scope; EU AI Act Article 16 + Article 26 role-tagged obligations
Statement of Applicability (Annex A informative)	ISO 27001 Statement of Applicability (Annex A normative); EU AI Act Annex IV technical documentation
Clause 6.1.4 AI impact assessment	EU AI Act Article 27 FRIA; algorithmic-impact-assessment frameworks
Stage 1 / Stage 2 / surveillance cycle	ISO 27001 certification cycle (identical); ISO 9001 certification cycle
Internal audit (Clause 9.2)	ISO 27001 Clause 9.2; ISO 9001 Clause 9.2
Management review (Clause 9.3)	ISO 27001 Clause 9.3; shared management-system process

Related pages

ISO 42001 overview

Hub: AIMS structure, Annex SL backbone, certification path overview

Clauses 4–10 (implementation guide)

Practical reading of the Annex SL management-system clauses

Annex A and informative annexes

How to use the Annex A reference controls and the B / C / D informative annexes

Operationalizing in Modulos

OFF-7 / MFF-7 (legacy) and OFF-10 / MFF-10 (clause-aligned) rollout

Source attribution

ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, Clauses 4.1, 4.2, 4.3, 5.2, 5.3, 6.1.2, 6.1.3, 6.1.4, 9.2, 9.3, 10.1, 10.2 + Annex A.2–A.10. © ISO/IEC. Available via the ISO Online Browsing Platform.

Disclaimer

This page is for general informational purposes and does not constitute legal or certification advice.