The ISO/IEC 42001 AI management system standard lists 38 reference controls in Annex A, grouped under 9 objectives from A.2 to A.10. You choose the ones that treat your AI risks and record the decision in a Statement of Applicability. Below, each control is described in our own words, with what good looks like and the evidence an auditor usually asks for.
Assess AI risks with a defined method (clause 6.1.2).
Choose a treatment for each risk and the controls that implement it (clause 6.1.3).
Compare those controls with Annex A so nothing needed is overlooked.
Record every Annex A control as included or excluded, with the reason and its status, in the Statement of Applicability.
Annex B of the standard gives implementation guidance for each control. The gap assessment drafts a Statement of Applicability from your answers, and the checklist tracks the evidence.
A.2 Policies related to AI
Control
What good looks like
Typical evidence
A.2.2 AI policy
A documented policy guides how you develop, provide or use AI systems.
AI policy document
A.2.3 Alignment with other policies
The AI policy fits with your other policies, such as security, privacy and quality.
Policy cross-reference or mapping
A.2.4 Review of the AI policy
The AI policy is reviewed at planned intervals and when something significant changes.
Policy review record
A.3 Internal organisation
Control
What good looks like
Typical evidence
A.3.2 AI roles and responsibilities
Roles and responsibilities for AI are defined and allocated to named people.
Role descriptions; AI RACI
A.3.3 Reporting of concerns
People can raise concerns about AI systems through a defined channel, without fear of reprisal.
Concern-reporting procedure; channel details
A.4 Resources for AI systems
Control
What good looks like
Typical evidence
A.4.2 Resource documentation
The resources each AI system needs across its life cycle are identified and documented.
AI system resource inventory
A.4.3 Data resources
The data used by each AI system is documented.
Data inventory per AI system
A.4.4 Tooling resources
Tools, frameworks, libraries and models in use are documented.
Tooling and model inventory
A.4.5 System and computing resources
Computing and infrastructure resources are documented.
Infrastructure inventory
A.4.6 Human resources
The people and skills needed at each life cycle stage are documented.
Staffing and skills plan
A.5 Assessing impacts of AI systems
Control
What good looks like
Typical evidence
A.5.2 Impact assessment process
A process assesses the potential consequences of AI systems before and during use.
Impact assessment procedure
A.5.3 Documenting impact assessments
Impact assessment results are documented and kept for a defined period.
Stored impact assessment reports
A.5.4 Impact on individuals and groups
Impacts on people's rights, fairness, safety and wellbeing are assessed.
Individual and group impact analysis
A.5.5 Societal impacts
Wider effects on society (for example environment, employment, public trust) are assessed.
Societal impact analysis
A.6 AI system life cycle
Control
What good looks like
Typical evidence
A.6.1.2 Objectives for responsible development
Objectives for responsible AI development are set and built into the development process.
Responsible AI development objectives
A.6.1.3 Responsible design and development processes
Design and development follow defined processes with responsible-AI checkpoints.
Development process with review gates
A.6.2.2 Requirements and specification
Requirements for new AI systems, or significant changes, are specified and agreed.
Requirements specifications
A.6.2.3 Design and development records
Design choices and development work are documented.
Design documents; decision records
A.6.2.4 Verification and validation
AI systems are tested against defined acceptance criteria before release and after changes.
Test plans and results; acceptance criteria
A.6.2.5 Deployment
A deployment plan is followed and release requirements are met before go-live.
Deployment checklist; release approval
A.6.2.6 Operation and monitoring
AI systems in use are monitored for performance, errors, drift and misuse, with a plan to act.
Monitoring dashboards; operations runbook
A.6.2.7 Technical documentation
Technical documentation is available to those who need it (users, partners, authorities).
Technical documentation set
A.6.2.8 Event logs
AI systems record event logs at the right stages, and the logs are kept.
Logging configuration; retention settings
A.7 Data for AI systems
Control
What good looks like
Typical evidence
A.7.2 Data for development and enhancement
Data management processes cover the data used to develop and improve AI systems.
Data management procedure
A.7.3 Acquisition of data
Where data comes from, and your right to use it, are recorded.
Data source register; licences or consents
A.7.4 Data quality
Data quality requirements are defined and data is checked against them.
Data quality rules and check results
A.7.5 Data provenance
The origin and history of data can be traced through the life cycle.
Lineage records
A.7.6 Data preparation
Methods used to prepare data (cleaning, labelling, transformation) are defined and documented.
Data preparation procedures
A.8 Information for interested parties
Control
What good looks like
Typical evidence
A.8.2 Information for users
Users receive the information they need to use the AI system appropriately, including its limits.
User documentation; AI notices
A.8.3 External reporting
Interested parties can report adverse impacts of your AI systems.
External reporting channel
A.8.4 Communicating incidents
There is a plan to tell users and others about AI incidents.
Incident communication plan
A.8.5 Information for interested parties
Obligations to report information about AI systems to interested parties are identified and met.
Register of reporting obligations
A.9 Use of AI systems
Control
What good looks like
Typical evidence
A.9.2 Processes for responsible use
Processes define how AI systems are used responsibly in your organisation.
Responsible use procedure
A.9.3 Objectives for responsible use
Objectives guide the responsible use of AI systems.
Responsible use objectives
A.9.4 Intended use and human oversight
AI systems are used only as intended and documented, with human oversight where it matters.
Intended use statements; oversight records
A.10 Third-party and customer relationships
Control
What good looks like
Typical evidence
A.10.2 Allocating responsibilities
Responsibilities are split clearly between you, partners, suppliers and customers.
Responsibility matrix in contracts
A.10.3 Suppliers
Suppliers of AI models, services and data are assessed and held to your responsible-AI requirements.
Supplier assessments; contract clauses
A.10.4 Customers
Customer needs and expectations are considered in how you provide AI systems.
Customer requirements; terms of use
Controls to get right first
In the gap assessment, a missing control from this list of 12 is a high-priority gap, because most AI risk treatments depend on it:
A.2.2 AI policy
A.3.2 AI roles and responsibilities
A.5.2 Impact assessment process
A.5.4 Impact on individuals and groups
A.6.2.4 Verification and validation
A.6.2.6 Operation and monitoring
A.6.2.8 Event logs
A.7.4 Data quality
A.8.2 Information for users
A.8.4 Communicating incidents
A.9.4 Intended use and human oversight
A.10.3 Suppliers
Excluding a control
A control can be excluded when it isn't relevant to the AI systems in scope, for example the data-for-development controls when you only use AI services built by others. Record the reason in the Statement of Applicability. The clause 4 to 10 requirements can't be excluded.
Questions
How many controls are in ISO 42001 Annex A?
38 controls, grouped under 9 control objectives numbered A.2 to A.10.
Are the Annex A controls mandatory?
Not one by one. You compare your AI risk treatment with Annex A, then record each control as included or excluded, with your reasons, in the Statement of Applicability. Excluding a control needs a justification an auditor will accept. The requirements in clauses 4 to 10 apply in full.
Can we add controls that are not in Annex A?
Yes. Annex A is a reference list. If your AI risk treatment needs a control that isn't there, add it and record it in the Statement of Applicability.
Where is the official wording of the controls?
In ISO/IEC 42001 itself, sold by ISO and national standards bodies. This page describes each control in our own words; buy the standard for the authoritative text.
ISO 42001 Gap Assessment