Navigating CMMC and FedRAMP Together: From Assessment-Ready to Authorized | July 22nd

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Governance
AI Governance
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

ISO 42001: The Importance of Knowing Your Role Before Building Your AI System

Artificial Intelligence | ISO 42001

Published: Jun 17, 2026

ISO/IEC 42001:2023 is the first international standard for an Artificial Intelligence Management System (AIMS). Structured similarly to other ISO management system standards, like ISO 27001, with mandatory clauses 4 through 10 and an Annex A control set, it shares the same Plan-Do-Check-Act logic familiar to any management system practitioner.

But among other AI specific considerations, it contains a requirement that sets it apart from other ISO frameworks: as part of scoping your AIMS, you must formally determine your role with respect to the AI systems within the scope of the AIMS. In this article, we’ll outline the importance of role awareness in ISO 42001 certification, including a breakdown of Annex A and the 38 controls across 9 domains, key compliance requirements, and considerations around what auditors really look for.

What Are the Roles in ISO 42001?

ISO 42001 is a standard built around role awareness. Guidance and terminology noted in ISO/IEC 22989 provides the normative reference to the AI roles with which you can declare when implementing an AIMS. The ISO 22989 standard recognizes three certifiable roles, AI producer, AI provider, and AI customer, each described below:

  • AI Producer: designs and trains AI Models
  • AI Provider: offers AI systems as products or services to others
  • AI User: acquires and operates AI tools built by someone else

What Are the Role Responsibilities in ISO 42001?

Organizations can occupy more than one role simultaneously, and a firm that builds its own Machine Learning (ML) models and also licenses third-party AI tools is considered both a Provider and a User. In those cases, your organizations’ AIMS must account for and address both sets of obligations. Clause 4.3 requires the scope to reflect every role the organization holds. Other responsibilities by roles are outlined below.

ISO 42001 Role Responsibilities for Provider vs. User

At first glance, the clause requirements look identical for both the provider and user roles and structurally, they are. Both must produce an AI Policy (Clause 5.2), conduct risk assessments (Clause 6.1), and maintain performance monitoring (Clause 9.1). The divergence lies in what those activities address.

ISO 42001 Role Responsibilities for Providers and Developers

For providers and developers, the focus is on the AI system itself. Risk assessment centers on algorithmic bias, training data provenance, model drift, adversarial inputs, and explainability gaps. The AI System Impact Assessment (Clause 6.1.4) must evaluate potential harm to interested parties and dependencies (determined in clause 4.1 and 4.2) before deployment. AI Lifecycle controls govern design, data collection, training, validation, monitoring, retraining, and decommissioning. Transparency obligations require providers to disclose model capabilities, limitations, and override mechanisms to downstream users.

ISO 42001 Role Responsibilities for Users and Customers

For users and customers, the focus shifts to the use case. Risk assessment targets three key concerns: over-reliance on AI outputs, discriminatory outcomes in specific business contexts such as lending, hiring, or triage, and supplier opacity. The Impact Assessment is scoped to the organization's specific application, primarily considering how deploying this AI tool affects the individuals it touches.

Human oversight (Annex A.8.4) becomes the primary operational control: documented procedures for reviewing AI-generated decisions, escalation paths, and override records are the evidence an auditor will request first. Supplier management (A.9) is equally critical, requiring contracts with AI providers to include audit rights, incident notification obligations, and exit provisions.

ISO 42001 Annex A: 38 Controls Across 9 Domains

Annex A is the operational backbone of ISO 42001. Its 38 reference controls are organized into nine domains, each targeting a distinct dimension of AI governance. Unlike ISO 27001's Annex A, ISO 42001's Annex A is a reference set, in which you select applicable controls and justify any exclusions in a Statement of Applicability (SoA). In practice, the majority of controls apply to most organizations, and auditors treat the SoA as the primary lens for assessing your control landscape.

The Nine Domains

  1. A.2 covers AI Policy across three controls addressing policy establishment, alignment with broader organizational policies, and scheduled review.
  2. A.3 addresses Internal Organization through two controls defining roles, responsibilities, and AI governance reporting structures.
  3. A.4 covers Resources in two controls requiring documentation of data, tooling, computer infrastructure, and human expertise.
  4. A.5 is the largest domain with eight controls governing the full AI system lifecycle from design through decommissioning. This is the primary domain for Providers.
  5. A.6 addresses Data Governance in two controls covering training data quality, provenance, acquisition, and bias analysis.
  6. A.7 covers Transparency in two controls requiring disclosure of AI capabilities and limitations to users and affected individuals.
  7. A.8 addresses Use of AI Systems across five controls including acceptable use policies, intended use verification, human oversight, and decision record keeping. This domain is most operationally significant for Users.
  8. A.9 covers Third-Party Relationships in two controls governing supplier due diligence and contractual obligations.
  9. A.10 contains one control addressing downstream use of AI by the organization’s own customers.

Annex B provides implementation guidance for each control. Annexes C and D are non-normative but valuable: C maps common AI risk sources to the control framework, while D guides integration with ISO 27001, ISO 9001, ISO 22301, and sector-specific standards.

ISO 42001 Requirements: What You Must Have in Writing

ISO 42001 requires intensive documentation. Every clause from 4 through 10 generates mandatory documented information, and every Annex A control, whether included or excluded, must appear in the Statement of Applicability with a justification regarding applicability to your organization. It’s largely believed that the SoA is the single most important document for certification and is the auditor's primary starting point.

The core mandatory documents span the full management system lifecycle. The foundation of documents (noted within the standard) includes the AIMS Scope Document, the AI Policy signed by top management, and a Roles and Responsibilities assignment. Planning documentation requires an AI Risk Assessment and Treatment Plan, an AI System Impact Assessment, and documented AI Objectives with measurement plans.

Support and operational documentation centers on the Statement of Applicability, evidence of staff competence and training, and operational planning and lifecycle records. Evaluation and improvement documentation includes performance monitoring results, internal audit reports, management review records, and corrective action records. Annex A additionally requires operational evidence for all applicable controls, particularly lifecycle records, data governance documentation, transparency disclosures, human oversight logs, and supplier agreements.

Building on What You Already Have: How Other ISO Certifications Can Serve as Foundation for ISO 42001

For organizations already certified to ISO 27001 or ISO 22301, ISO 42001 does not need to be built from scratch. The much overlooked Annex D explicitly supports integrated implementation, and the harmonized structure set shared across standards means the management system required documentation (i.e. risk assessment methodology, documented information controls, internal audit programmed, and management review) are able to be utilized in an integrated manner.

For instance, the ISO 27001 risk register can be extended with AI-specific threat categories such as bias, model drift, adversarial inputs, and data provenance failures. The existing incident response structure accommodates AI incident response with targeted additions for model failure scenarios. The two Statements of Applicability can cross-reference shared controls to avoid duplication.

For ISO 22301, AI systems that are operationally critical should be included in the Business Impact Analysis with defined recovery objectives, and BCM exercises should be extended to include AI failure scenarios. For other audit accreditations like DORA, ISO 42001's lifecycle and incident response controls map directly onto DORA's ICT risk management obligations. Those pursuing CSA STAR can leverage ISO 42001's data governance, transparency, and supplier controls as evidence against overlapping cloud and AI governance requirements.

Where Auditors Look More In-depth, Beyond the Clause Documentation

Human oversight (A.8.4) is perhaps the most operationally visible control: a policy alone is not sufficient — auditors want logs, escalation records, and evidence that staff have been trained to review and override AI-generated decisions. Data governance (A.6) is a persistent gap for Providers, who often cannot produce documented bias analysis or a data lineage trail for training datasets. Supplier agreements (A.9) for Users are frequently missing the three provisions auditors look for: audit rights, incident notification timelines, and exit or data return clauses.

The practical message is straightforward: document early, keep records operationally, and treat the AIMS as a living system rather than a certification project. Please remember in accordance with the ISO 42001 standard that once a certificate is awarded or upon initial certification, the organization is expected to improve and review annually. Determine your role, scope accordingly, and build evidence that your AI systems are governed, not just documented. A solid foundation will lead to not only a successful audit, but a thriving AIMS environment.

Moving Forward with Building a Governed AI System

Beyond certification, ISO 42001 is a framework for demonstrating that your organization takes AI governance seriously. Whether you're a Provider navigating lifecycle controls and bias analysis, or a User focused on human oversight and supplier accountability, the path to certification starts with understanding your role and responsibilities.

Knowing your role shapes your scope, drives your documentation, and tells you exactly where auditors will look. Organizations that treat their AIMS as a living system are the ones that not only achieve certification but sustain it.

If you're ready to determine your role and build an AIMS that's governed from the ground up, we'd love to help. Contact us to learn more about how we support organizations through AI governance road mapping and ISO 42001 certification.

In the meantime, discover other ISO 42001 insights in these helpful resources:

About Matthew Gierl

Matthew Gierl is a Senior Associate with Schellman. Prior to joining the firm in February of 2018, Matthew worked as a IT Risk Consultant specializing in SOC 1 and SOC 2 testing. As a Senior Associate with Schellman, Matt is now focused primarily on helping organizations across various industries achieve different ISO certifications.