ISO 42001 Operationalization Checklist: From Document Compliance to Operational Conformance

COMPEL Body of Knowledge — Regulatory Bridge Series Cluster A — ISO 42001 Operationalization

Why operationalization, not documentation {#why}

ISO/IEC 42001:2023 is the first certifiable management system standard for AI. It is structured like its siblings — ISO 27001, ISO 9001 — with seven clauses (4–10) that describe the operating model and an Annex A catalogue of thirty-eight controls. The temptation, for any organization that has run an ISO program before, is to treat 42001 as a document-production exercise: write the policies, fill in the Statement of Applicability, assemble a binder, hand it to an auditor.

That approach fails. Accredited certification bodies (BSI, DNV, TÜV, Schellman) sample running evidence: the last three AIIAs, the last two management reviews, the last internal audit cycle, the twelve-month incident register, the last quarter’s training records. Absent, stale, or contradictory evidence produces a major nonconformity and the certificate does not issue.

Document compliance says “we have a policy that says we do X.” Operational conformance says “we did X, here is the dated artifact, the person who ran it, the corrective action we raised, the closure record.” One produces a binder. The other produces a management system.

This article is a clause-by-clause operational checklist. For each requirement it names the recurring activity, the evidence artifact, and the cadence. It is written for the governance professional building the AIMS, not for the compliance officer auditing one.

Clause-by-clause operational checklist {#checklist}

Clause 4 — Context of the organization

Clause 4 asks whether your management system has a defensible scope. Running it as an operation means re-examining the context whenever the AI portfolio changes.

4.1 Understanding the organization and its context

• Maintain a context register that lists internal factors (AI strategy, risk appetite, culture) and external factors (regulatory pressure, supplier ecosystem, market dynamics) material to the AIMS.
• Review the register at least annually, at the management review, and on any material change — acquisitions, new jurisdictions, new high-risk AI deployments.
• Link each context factor to the downstream clause it influences. A new regulatory regime influences 6.1.1 (risks) and 6.2 (objectives); a new supplier influences Annex A.10.
• Retain dated register snapshots as evidence that the context was re-examined, not just static.

4.2 Understanding the needs and expectations of interested parties

• Keep a stakeholder register covering regulators, customers, data subjects, affected communities, workers, suppliers, investors, and internal functions.
• For each stakeholder, record the expectation (what they require of the AI system) and how the AIMS addresses it.
• Review with the AI Governance Committee quarterly; update when stakeholder expectations materially change (new regulation, litigation, public incident).
• Tie the register to the impact-assessment process so affected-party analysis is systematic, not ad hoc.

4.3 Determining the scope of the AI management system

• Produce a scope statement listing the AI systems, business units, geographies, and lifecycle phases within the AIMS boundary.
• Justify exclusions explicitly — which AI systems are out of scope and why.
• Publish the scope internally so system owners know whether their AI falls under the AIMS.
• Re-issue the scope on every AI inventory refresh (quarterly minimum).

4.4 AI management system

• Document the PDCA (plan-do-check-act) cycle as the operating model.
• Name the process owner for each clause and Annex A control.
• Maintain a process map showing how clauses interact — Clause 6 planning feeds Clause 8 operation, which feeds Clause 9 monitoring, which feeds Clause 10 improvement, which loops back into Clause 6.

Clause 5 — Leadership

Auditors do not accept a signed policy as evidence of leadership commitment — they interview executives and expect specifics.

5.1 Leadership and commitment

• Establish a board-level AI governance committee (or designate the sub-committee of an existing risk/audit committee) with published terms of reference.
• Minute executive decisions on AI risk appetite, policy approvals, major incidents, and budget allocations.
• Ensure the CEO or designated executive owner signs the AI policy and reviews management review outputs personally.
• Document how AI governance is integrated into existing business processes (procurement, product development, vendor onboarding).

5.2 AI policy

• Publish an AI policy that states commitment to applicable requirements, objectives, continual improvement, and responsible-AI principles.
• Cross-reference the policy to clause 6.2 objectives so the commitments are measurable, not aspirational.
• Review annually and on material change; version-control every revision with approval signatures.
• Communicate the policy internally (intranet, onboarding) and externally where appropriate (website, supplier agreements).

5.3 Roles, responsibilities, and authorities

• Maintain a RACI matrix for every clause and Annex A control, naming role (not individual) as accountable owner.
• Assign a top-management-designated role (e.g., Chief AI Officer, AI Governance Lead) with overall AIMS authority.
• Define segregation of duties — model developer cannot approve their own model deployment; risk owner cannot close their own risk.
• Publish the RACI to all system owners; include it in onboarding for new hires in AI-adjacent roles.

Clause 6 — Planning

Clause 6 is the risk-based backbone of the AIMS. The risk register must be a living document — entries opened, assessed, treated, and closed every month.

6.1 Actions to address risks and opportunities

• Maintain an AI risk register with entries tagged by AI system, risk category (fairness, robustness, privacy, security, transparency, accountability), likelihood, impact, and treatment.
• Run AI System Impact Assessments (AIIA) (clause 6.1.4) for every new AI system, every material change, and on a defined cadence (annual minimum for high-impact systems).
• Define risk criteria (6.1.2) upfront — what counts as acceptable, tolerable, intolerable — and anchor them to the risk appetite statement.
• Produce risk treatment plans (6.1.3) with named owners, deadlines, and evidence of completion.
• Record residual risk acceptance with executive sign-off for anything above threshold.
• Feed AIIA outputs into both the risk register and the Annex A control applicability decisions.

6.2 AI objectives and planning to achieve them

• Define measurable AI objectives aligned to the policy — for example, “100% of AI systems have current AIIA within 12 months,” “mean time to close nonconformity under 30 days,” “zero Sev-1 fairness incidents in production.”
• Assign each objective to a role, with quarterly progress reports to the AI Governance Committee.
• Cascade objectives into team-level KPIs and, where relevant, personal objectives for AI leaders.
• Review against actuals at the management review (clause 9.3).

6.3 Planning of changes

• Maintain a change-management procedure covering AI policy changes, scope changes, significant system changes, and material data changes.
• Require a change impact assessment before any material change to a high-risk AI system.
• Integrate with the existing change-advisory board (CAB) if one exists; if not, stand one up for AI.
• Retain dated change records as evidence.

Clause 7 — Support

Clause 7 tests whether the AIMS has the resources, skills, awareness, communications, and information discipline to function.

7.1 Resources

• Produce an annual AIMS resource plan covering people (headcount, roles), tooling (MLOps, model monitoring, policy platforms), and budget.
• Link the plan to the objectives (6.2) so resourcing follows commitments.
• Review and approve at the management review; track actual versus planned quarterly.

7.2 Competence

• Maintain a competency register per AI-adjacent role with the required competencies, the evidence of attainment (certifications, training completions, demonstrated experience), and the renewal date.
• Map roles to certifications where relevant (for example, COMPEL AITF/AITP/AITGP/AITL, ISO 42001 Lead Auditor, cloud-platform credentials).
• Re-assess on role change, on finding of competence gap in an incident, and at least annually.
• Retain training-completion records per individual.

7.3 Awareness

• Run an AI literacy program reaching all employees (EU AI Act Article 4 increasingly requires this for EU operations).
• Tier awareness content: foundational for all staff, role-specific for AI developers/users, executive for board and leadership.
• Track completion, retention (knowledge checks), and annual refreshes.
• Retain records with individual traceability.

7.4 Communication

• Maintain an AI communication plan covering internal (policy rollouts, training, incident notifications) and external (regulator inquiries, data-subject rights, customer notifications, public statements).
• Define who can communicate externally about AI on behalf of the organization.
• Retain communications logs — especially regulator correspondence and incident notifications.

7.5 Documented information

• Use a document-management system (SharePoint, Confluence, dedicated GRC) with version control, access control, and retention.
• Classify AI documentation (policies, procedures, evaluation reports, incident records) by sensitivity and retention class.
• Retain records per policy — typically life of AI system plus 3–10 years depending on jurisdiction; EU AI Act mandates 10 years after last placement for high-risk systems.
• Run periodic controls to verify document currency — no procedure older than its review cycle.

Clause 8 — Operation

Clause 8 is where the AIMS meets the AI systems — the clause with the highest density of Annex A controls and where operational-versus-document compliance matters most.

8.1 Operational planning and control

• Maintain operating procedures per AI system covering data ingestion, training, evaluation, deployment, monitoring, and retirement.
• Require gate reviews at each lifecycle phase with documented approvers and rejection criteria.
• Integrate with MLOps tooling — pipeline runs, evaluation results, deployment approvals all captured automatically.
• Retain operational evidence — pipeline logs, evaluation reports, deployment tickets — per retention policy.

8.2 AI risk assessment

• Run AI risk assessments per system, per material change, per the 6.1 procedure.
• Use a consistent risk taxonomy across the organization — same fairness categories, same robustness categories, same privacy categories.
• Feed outputs into the AI risk register and the treatment plan.
• Require risk owner sign-off on each assessment.

8.3 AI risk treatment

• Implement treatments per the treatment plan — controls, monitoring, contractual safeguards, retirement, or risk acceptance.
• Verify implementation before closure — a treatment is not complete because the ticket is resolved; it is complete because evidence shows the control is operating.
• Re-test treatments periodically (quarterly for Tier 1 risks, annually for Tier 2/3).
• Document why any risk was accepted rather than treated, with executive sign-off.

8.4 AI system impact assessment

• Run an AIIA covering intended use, affected individuals and groups, potential harms, mitigations, and residual impact.
• Use a standard AIIA template across the organization so impact assessments are comparable.
• Require AIIA approval by the AI Governance Committee (or delegated authority) before deployment of high-impact systems.
• Re-run on material change, on re-training with materially different data, on scope expansion, and on a defined cadence.
• Satisfies NIST AI RMF MAP 1.5 concurrently — see the crosswalk article.

Clause 9 — Performance evaluation

Clause 9 is the checkpoint clause. It tests whether the AIMS is actually working, not just running.

9.1 Monitoring, measurement, analysis, and evaluation

• Define what to monitor per AI system — performance, fairness metrics, robustness indicators, data drift, model drift, security events, user feedback.
• Define how to monitor — dashboards, alerts, thresholds, escalation paths.
• Define cadence — continuous for production systems, per-cycle for retraining, per-release for new deployments.
• Feed monitoring outputs into the risk register, the incident register, and the management review.
• Retain monitoring evidence per retention policy.

9.2 Internal audit

• Maintain an internal audit program covering all clauses and in-scope Annex A controls over a defined cycle (typically three years).
• Use auditors independent of the audited activity — a model developer cannot audit their own model.
• Produce dated audit reports with findings categorized (major NC, minor NC, observation, opportunity for improvement).
• Track findings through closure in an audit-findings register with root cause, corrective action, effectiveness check, and closure evidence.
• Report summary findings to the management review.

9.3 Management review

• Run the management review at least annually — quarterly is good practice for new AIMS implementations.
• Cover the full required input set: audit results, performance measurement, stakeholder feedback, status of corrective actions, changes in external and internal issues, resource adequacy, opportunities for improvement.
• Produce dated minutes with decisions and actions — the minutes are audited, not the meeting.
• Assign decisions and track them to closure.

Clause 10 — Improvement

Clause 10 closes the PDCA loop. Auditors look for evidence of learning — the AIMS must demonstrably improve over time.

10.1 Nonconformity and corrective action

• Maintain a nonconformity register covering audit findings, incidents, customer complaints, regulator queries, and operational issues.
• For each nonconformity: record the issue, contain it, identify root cause (5-whys, fishbone, or equivalent), define corrective action, verify effectiveness, close with evidence.
• Track time-to-close as a management KPI — stale NCs are a red flag.
• Require executive sign-off on major nonconformities.

10.2 Continual improvement

• Maintain a continual-improvement register capturing opportunities for improvement (OFIs) from audits, reviews, and staff suggestions.
• Prioritize OFIs against the objectives (6.2) and resource plan (7.1).
• Report progress at the management review.
• Demonstrate improvement trends — quarterly metrics moving in the right direction across audit cycles.

Annex A control implementation table {#annex-a}

Annex A of ISO/IEC 42001:2023 lists thirty-eight controls grouped into ten domains. The table below translates each domain into a running implementation activity. Every control must appear in the Statement of Applicability with an inclusion/exclusion decision.

The Statement of Applicability must cite in-scope controls, justify exclusions, and reference the procedure implementing each included control. Auditors sample Annex A controls during Stage 2.

Evidence artifact per clause {#evidence}

Each clause produces a canonical artifact, retained in a document-management system with versioning and access control.

Recurring-control cadence table {#cadence}

The cadence table is the operational heartbeat of the AIMS. Every control has a cadence — nothing runs “when we get to it.”

COMPEL stage mapping {#compel-mapping}

ISO 42001 clauses map onto the COMPEL six-stage lifecycle. Running COMPEL positions an organization for ISO 42001 certification with minimal additional work.

COMPEL stage artifacts — AIIAs, risk registers, evaluation plans, monitoring dashboards, retrospectives — double as ISO 42001 evidence.

Metrics {#metrics}

An operational AIMS produces the following metrics monthly and reviews them at the management review:

• AIIA coverage: percentage of in-scope AI systems with current (not stale) AIIA.
• Risk treatment throughput: number of risks opened, closed, and aged by tier.
• Nonconformity time-to-close: mean and 90th percentile, split by major/minor.
• Audit finding closure rate: percentage of findings closed within target (typically 90 days for major, 180 for minor).
• Training completion: percentage of in-scope staff with current AI literacy and role-specific training.
• Supplier coverage: percentage of AI suppliers with current risk assessment and contractual AI clauses.
• Monitoring alerting: number of production alerts raised, triaged, and escalated, by system and severity.
• Management review actions: number open, closed, overdue.
• Objective attainment: percentage of 6.2 objectives on track.
• AI incident rate: incidents per system per quarter, split by severity.

Trend lines matter more than absolute values — auditors look for improvement quarter over quarter.

Risks if skipped {#risks}

Treating ISO 42001 as a documentation exercise rather than an operational program exposes the organization to:

• Major nonconformity at Stage 2 — the audit fails and certification is delayed six to twelve months while evidence gaps are filled.
• Stale AIIAs — the management system loses its risk-based backbone and regulators challenge the defensibility of deployed systems.
• Supplier-risk gap — AI introduced through procurement never enters the AIMS; when an incident occurs at the supplier, there is no contractual hook or prior assessment.
• Incident mishandling — without a running nonconformity process, incidents are closed operationally but no corrective action reaches the policy or the risk register, so the same incident repeats.
• Regulatory exposure — EU AI Act Article 17 presumes conformance via ISO 42001; a shelved AIMS cannot be presented as evidence of quality-management-system compliance.
• Cost creep — without a running AIMS, every audit, regulator query, or customer due-diligence request triggers a one-off document-production scramble at 3–5× the steady-state cost.
• Loss of customer trust — enterprise customers increasingly require ISO 42001 certification in procurement; a lapsed or failed certification shows up in due-diligence reports.

Related standards and references {#references}

• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system — iso.org/standard/81230.html. Clauses 4–10 and Annex A controls A.2–A.10.
• ISO/IEC 23894:2023 — AI risk management guidance — iso.org/standard/77304.html. Risk-management reference called out by ISO 42001 clause 6.
• ISO/IEC 42005:2025 — AI system impact assessment — iso.org/standard/44545.html. Companion standard to 42001 clause 6.1.4 and 8.4.
• NIST AI Risk Management Framework 1.0 — nist.gov/itl/ai-risk-management-framework. Companion voluntary framework for the US market.
• EU AI Act (Regulation 2024/1689) — eur-lex.europa.eu. Article 17 (quality management system) and Article 11 (technical documentation) where ISO 42001 conformance supports presumed compliance.
• IAF MD 5 — Duration of QMS and EMS audits — iaf.nu. Informs Stage 1/Stage 2 audit durations for accredited ISO 42001 bodies.
• ISO/IEC 27001:2022 — Information security management systems — iso.org/standard/27001. Management-system sibling; share the Annex L structure and much of the documentation discipline.

Related COMPEL articles

• ISO 42001 Implementation Using COMPEL
• ISO 42001 Alignment and AI Management System Certification
• Building EU AI Act Evidence Portfolios
• NIST AI RMF to ISO 42001 Crosswalk: A Dual-Compliance Operating Map

How to cite

COMPEL FlowRidge Team. (2026). “ISO 42001 Operationalization Checklist: From Document Compliance to Operational Conformance.” COMPEL Framework by FlowRidge. https://www.compelframework.org/articles/seo-a4-iso-42001-operationalization-checklist/