ISO 42001 for Project Managers

PM Takeaways

• ISO 42001 is a management system standard — same pattern as ISO 9001 or ISO 27001. Ten clauses, “shall” language, an Annex A controls catalogue you select from based on your risk profile, and third-party certification available. The AI-specific substance lives in Clauses 6 and 8 and the two annexes.
• ISO 42001 distinguishes providers (who develop and place AI systems on the market) from deployers (who put AI systems into use). Most PMs on internal AI projects are on the deployer side — and deployer obligations differ meaningfully from provider obligations. The standard also recognizes “affected persons” whose interests must be accounted for even though they aren’t AI actors.
• The two most significant PM deliverables in ISO 42001 are the AI risk assessment (Clause 6.1.2) and the AI impact assessment (Clause 6.1.4). They are not the same document — risk asks what could go wrong with the system, impact asks who could be harmed by it. Both feed the Annex A controls selection, and neither closes at deployment.
• An ISO 42001-certified management system provides documented evidence for many of the EU AI Act’s Article 17 quality management requirements. For organizations pursuing high-risk AI conformity, certification is a practical complement to the regulatory pathway — not a substitute for it.

If you’ve worked with ISO standards before — ISO 9001 for quality management, ISO 27001 for information security — you know what to expect from the structure. A defined high-level format across ten clauses. Requirements written in “shall” language. A controls catalogue you select from based on your context and risk profile. Third-party certification available. Continual improvement built in by design.

ISO/IEC 42001:2023 applies that same pattern to AI. Published in December 2023, it is the first international standard for AI management systems. It defines requirements for an Artificial Intelligence Management System (AIMS): the documented policies, processes, roles, and controls through which an organization governs the responsible development, provision, and use of AI.

For PMs, the question is not whether to pursue organizational certification — that is a leadership decision. The question is what the standard requires at the project level, and how to ensure your project generates the evidence and documentation an AIMS-based organization needs.

Structure: HLS and AI-Specific Clauses

ISO 42001 follows ISO’s High-Level Structure (HLS) — the same ten-clause template used by ISO 9001, ISO 27001, and other management system standards. Clauses 1–3 cover scope, references, and terms. Clauses 4–10 contain the requirements. This shared structure allows organizations with existing ISO management systems to integrate an AIMS without duplicating governance infrastructure. The ten clauses map to the Plan-Do-Check-Act cycle.

The AI-specific substance — what makes 42001 different from a generic management system standard — is concentrated in Clauses 6 and 8, and in the two annexes. Those are the sections that generate project-level deliverables unique to AI.

Clause 6: Planning — Where Project Deliverables Are Generated

Clause 6 is where ISO 42001 becomes distinctly AI-specific. It contains four AI-related requirements that translate directly into project artifacts.

6.1.2 — AI Risk Assessment

The AI risk assessment identifies what could go wrong with the AI system and evaluates likelihood and consequence. The standard requires the assessment to be documented, repeatable, and reviewed when conditions change. It feeds the selection of controls from Annex A.

AI risk assessment differs from conventional project risk management in several important ways. The risk register is not closed at project go-live — it extends through the operational life of the system. Risks include technical failure modes specific to AI (model drift, distributional shift, adversarial attack), operational risks (misuse, over-reliance, shadow deployment), and accountability risks (unclear ownership when something goes wrong).

PM implication: The AI risk assessment is a formal project deliverable — not the project manager’s risk register, but a document that will be reviewed in an AIMS audit. It needs an owner, a review trigger, and a documented linkage to the controls selected. Building both documents and clarifying their relationship is a scoping and governance task for project initiation.

6.1.4 — AI Impact Assessment

The AI impact assessment evaluates the system’s effects on individuals, communities, and society. It is distinct from the risk assessment: risk asks what could go wrong for the organization; impact asks who might be harmed and how, including people who are not the direct users or customers of the system.

The standard specifies five impact domains: sustainability (effects on the environment and natural resources), economics (employment, access to financial services, economic inclusion), governance (effects on legislative processes, democratic institutions, national security), health and safety (access to healthcare, physical and psychological harm), and norms and values (misinformation, bias, effects on cultures and communities).

PM implication: The impact assessment requires engaging with stakeholders who may not appear on a conventional stakeholder register — people affected by the system’s outputs but who are not customers, users, or sponsors. The assessment also needs a review trigger: if the system’s use cases, data, or deployment context change, the impact assessment must be revisited.

6.2 — AI Objectives

The standard requires the organization to establish measurable AI objectives consistent with the AI policy and to plan how to achieve them. Objectives must be documented, communicated, monitored, and updated.

PM implication: AI objectives belong in the project business case and success criteria. They are not the same as project success metrics — they include governance outcomes such as bias within defined thresholds, explainability requirements met for defined user groups, and monitoring alerts responded to within defined timelines. Define these at initiation. They become the baselines for Clause 9 performance monitoring.

Clause 8: Operations — Lifecycle Controls and Supply Chain

8.3 — AI System Lifecycle Controls

Clause 8.3 requires controls throughout the AI system lifecycle: from problem definition and data acquisition through design, development, testing, deployment, monitoring, and decommissioning. The standard does not prescribe a specific development methodology but requires documented evidence that controls are applied at each lifecycle phase.

PM implication: Your project plan must include lifecycle control activities as deliverables, not just system development activities. For each phase there should be an identifiable control — or documented rationale for exclusion — traceable to the risk and impact assessment. This is the audit trail an AIMS certification audit will look for.

8.4 — Supply Chain and Third-Party AI

ISO 42001 explicitly addresses AI supply chain governance. When an organization uses externally developed AI components — pre-trained models, third-party APIs, AI platforms — it remains responsible for ensuring those components meet the AIMS requirements to the extent they affect the organization’s AI systems.

This is not a simple pass-through. An organization cannot discharge its AIMS obligations by pointing to a vendor’s terms of service or model card. The deployer must understand what controls the provider has applied, what information the provider has documented, and what residual obligations the deployer carries for the deployed system.

PM implication: Third-party AI vendor selection should include a governance due diligence step aligned to ISO 42001 Clause 8.4 requirements. Procurement criteria should include questions about the vendor’s governance documentation (model cards, data datasheets, system cards, risk documentation), the controls applied, and what information they will make available to support your AIMS requirements. Vendor governance artifacts are project deliverables, not just commercial terms.

8.5 — Data Governance

Clause 8.5 establishes data governance requirements for AI systems: data quality, data provenance, data security, and data bias controls. Data used for training, validation, and testing must be documented and managed in ways that support the risk and impact assessment findings.

PM implication: Data governance is not a separate workstream that runs in parallel to the AI project. It is a project delivery requirement with documented artifacts. The data specification feeds the risk assessment, the impact assessment, and the system card. Build data governance activities into the project schedule with explicit owners and review points.

Annex A: The Controls Catalogue

Annex A contains 38 controls organized across eight control domains. These controls are not all mandatory — the organization selects applicable controls based on the risk and impact assessment outputs and documents the selection rationale in a Statement of Applicability (SoA). Any control can be excluded if the organization documents why it does not apply.

The Statement of Applicability is an organizational artifact, not a project artifact. But each project should be able to identify which Annex A controls are triggered by its risk and impact assessments, and which project deliverables provide the evidence for those controls. Building a project-level control mapping at initiation helps ensure the project generates the right evidence and avoids surprises in AIMS audits.

Provider vs. Deployer: Which Obligations Apply?

ISO 42001 recognizes that organizations operate in different roles in the AI value chain. The obligations under the standard differ based on role, and many organizations operate in multiple roles simultaneously.

Many organizations are both providers and deployers. A financial services firm that develops a credit scoring model for internal use is both. The applicable obligations depend on the role for each specific AI system, not on the organization’s general profile.

ISO 42001 and the EU AI Act

ISO 42001 has a direct and practical relationship with EU AI Act compliance. The EU AI Act’s Article 17 requires providers of high-risk AI systems to establish a quality management system covering documented policies and processes across the full lifecycle. Annex VII of the EU AI Act explicitly references quality management system assessment.

An ISO 42001-certified management system is not a substitute for EU AI Act conformity assessment — the two have different scope and different requirements. But certification provides documented evidence of many of the quality management requirements Article 17 imposes, and reduces the evidence-gathering burden in a conformity assessment. For organizations pursuing high-risk AI system deployment under the EU AI Act, ISO 42001 certification is a practical complement to the regulatory pathway rather than an alternative to it.

NIST has published a crosswalk between ISO 42001 and the NIST AI RMF confirming substantial structural overlap between the two frameworks. Organizations that have implemented the AI RMF have typically satisfied many ISO 42001 requirements in substance. The difference is that ISO 42001 provides a certifiable structure that an AI RMF implementation does not.

ISO 42001 vs. NIST AI RMF: A PM Comparison

Both frameworks address AI governance, but they serve different purposes and generate different obligations. Understanding the distinction helps PMs navigate situations where both apply.

The two frameworks are complementary. Many organizations use the NIST AI RMF for practical day-to-day risk management and ISO 42001 for the management system structure that supports certification. Building your project governance against both simultaneously is practical rather than redundant — most project-level deliverables satisfy requirements in both.

The ISO 42001 Family

ISO 42001 is part of a broader family of AI-related ISO/IEC standards. Several companion standards provide additional guidance the core standard does not fully specify:

ISO/IEC 23894:2023 — AI risk management guidance. Provides detailed guidance on the risk management processes that ISO 42001 requires. Practically useful for developing the AI risk assessment methodology required by Clause 6.1.2.

ISO/IEC 24028:2020 — AI trustworthiness. Addresses the trustworthiness properties of AI systems including accuracy, robustness, reliability, security, privacy, fairness, and explainability. Provides the technical vocabulary for specifying trustworthiness requirements in risk and impact assessments.

ISO/IEC 42005 (in development) — AI system impact assessment. Expected to provide detailed guidance on the AI impact assessment process required by ISO 42001 Clause 6.1.4 and Annex A.5.

Right-Sizing for Your Situation

Full ISO 42001 certification requires organizational commitment beyond any single project. But the standard’s requirements apply at the project level regardless of whether your organization is pursuing certification — because they define what responsible AI governance looks like in practice.

Greenfield — Starting Out

Focus on the two core Clause 6 deliverables: the AI risk assessment and the AI impact assessment. Even without an AIMS, producing these two documents at project initiation and updating them before go-live gives you the most defensible foundation. Use the Annex A control domains as a checklist to identify which areas need documentation — you don’t need all 38 controls, but you need to be able to explain which ones apply and how you’ve addressed them. Start with A.6 (lifecycle) and A.7 (data) as the most universally relevant.

Emerging — Building Repeatability

The Statement of Applicability pattern is worth borrowing even without formal certification. For each project, document which Annex A controls apply and which project artifacts provide the evidence — a one-page mapping that connects your deliverables to the standard’s requirements. This creates the reusable template that future projects can inherit rather than rebuild. It also positions the organization well if certification becomes a goal — the evidence trail is already there.

Established — Mature Programs

At this level the work is integration, not creation. Your project artifacts should map explicitly to AIMS documentation requirements — the risk register references the Clause 6.1.2 risk assessment, the monitoring plan references the Clause 9 performance evaluation requirements, and vendor governance artifacts reference Clause 8.4. NIST has published a crosswalk between ISO 42001 and the AI RMF: use it to confirm that your existing AI RMF implementation is generating the evidence ISO 42001 requires, and identify where genuine gaps remain.

The AI Governance Advisor at app.aipmo.co can help you work through how ISO 42001’s clauses apply to your specific project context, identify which controls are relevant for your system type, and structure the risk and impact assessment deliverables your project needs.

Framework References

ISO/IEC 42001:2023 — Clauses 4–10, Annex A (controls catalogue), Annex B (AI concepts guidance). AI management system requirements, AI risk and impact assessment, lifecycle controls, supply chain governance, and performance evaluation. Primary source for all clause and control references in this article.

ISO/IEC 23894:2023 — Full standard. AI risk management guidance; provides detailed methodology for the Clause 6.1.2 risk assessment process.

ISO/IEC 24028:2020 — Full standard. AI trustworthiness properties; technical vocabulary for specifying requirements in risk and impact assessments.

NIST AI Risk Management Framework 1.0 (NIST AI 100-1, 2023) — GOVERN, MAP, MEASURE, MANAGE functions; NIST–ISO 42001 crosswalk. Complementary risk management framework with substantial structural overlap with ISO 42001 requirements.

EU AI Act (Regulation (EU) 2024/1689) — Article 17, Annexes VI and VII. Quality management system requirements for high-risk AI providers; ISO 42001 certification supports Article 17 compliance evidence.

Download this articleA formatted copy for your files — available free to members.Download PDFDownload this articleJoin free to download a formatted copy for your files.Join free →

This article is part of AIPMO’s Frameworks series. See also: AI Impact Assessments  |  The PM’s Guide to NIST AI RMF  |  OECD AI Principles  |  AI Risk Classification

Embedded JavaScript