Knowledge base
ISO/IEC 42001:2023: documentation and compliance requirements
Everything ISO/IEC 42001:2023 requires you to document, clause by clause, with what an auditor asks to see for each. Written as requirements rather than as a checkli
Prem Kumar Dvivedi · 12 September 2026
This is what ISO/IEC 42001:2023 requires you to have, clause by clause, and what an auditor will ask to see for each of it. It covers 88 requirements across 14 areas.
It is deliberately not a checklist. A checklist asks whether you have something; this says what is required and what counts as evidence, which is the question that matters when you are building a system rather than testing one. If you would rather find out where you stand first, the same ground is covered by our free ISO/IEC 42001:2023 readiness assessment, which scores you out of 100.
4 Your organisation and the AI you use
Clauses 4.1, 4.2, 4.3, 4.4.
You must have written down the outside things that affect your use of AI — laws, customer expectations, technology, public attitudes.
Evidence: A short list of these issues, with a note of when you last looked at it.
You must have written down the inside things — skills, data, computing power, budget, how you are organised.
Evidence: The same list, covering internal issues.
For each AI system, you must have written down what role you play — you must build it, sell it, deploy it, or just use it.
Evidence: A written role determination per system. Your duties differ a lot depending on which. Settle this before answering the rest.
You must have listed everyone with an interest — customers, users, people affected by AI decisions, regulators, staff, model and data suppliers.
Evidence: A list of these groups and what each needs. Include people affected by a decision who are not your customers.
You must know which laws apply — AI rules, data protection, sector rules, product safety — in every country you operate in.
Evidence: A register by country, and a way of keeping up with a fast-moving area.
You must have written down what the AI management system covers — which AI systems, uses, business units and places.
Evidence: A scope statement with an inventory of AI systems.
The inventory must include AI built into software you bought, and AI tools your staff use day to day.
Evidence: The inventory checked against actual usage. Most organisations have more AI in use than their inventory shows.
You must know what your main processes are and how they fit together.
Evidence: A process map or a list with owners.
5 Leadership
Clauses 5.1, 5.2, 5.3.
Senior management must be able to point to AI decisions they made in the last year.
Evidence: Management review notes. Money and people provided. Ask them directly.
The organisation ever said no to an AI use, or paused one, on responsibility grounds must have been done.
Evidence: A real example. This is the strongest evidence that the policy means something.
You must have a written AI policy.
Evidence: The policy, signed and dated, promising to meet requirements and keep improving, and consistent with your other policies and your stated values.
It must be shared with your people.
Evidence: Where it is published. Ask staff.
It must be clear who is responsible for what, including a named owner for each AI system.
Evidence: Organisation chart. An owner named against each system in the inventory.
It must be clear who can approve a system going live, who must review its output, and who can switch it off.
Evidence: Defined authority to deploy, to require human review, and to suspend or withdraw a system.
6 Planning — risk and impact
Clauses 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.2, 6.3.
You must have worked out what could go wrong and what opportunities there are.
Evidence: A risk and opportunity list.
You must have a written way of assessing AI risk, with the rules set before you start.
Evidence: The method. When a risk is acceptable. Scales for likelihood and impact with what each level means.
The method must cover AI-specific things — data quality, model behaviour, bias, transparency, robustness, security, over-reliance.
Evidence: Those risk sources named in the method.
You must have actually assessed the risks for the systems in scope, with an owner for each.
Evidence: A risk register with owners, likelihood, impact and level.
For each risk you are treating, you must have chosen what to do and which controls to use.
Evidence: A risk treatment plan naming the option, the controls from Annex A, the owner and the timescale.
You must be able to answer: Have the risk owners approved the plan and accepted the residual risk, in writing?
Evidence: Documented approval by each risk owner.
You must have a Statement of Applicability covering the Annex A controls.
Evidence: The Statement listing each control, whether it is in or out, why, and whether it is implemented.
You must have assessed what your AI could do TO PEOPLE — individuals, groups and society — as a separate exercise from business risk.
Evidence: AI system impact assessments covering fairness, discrimination, safety, health, privacy, dignity, autonomy, access to services, employment and environmental effects. Groups affected who are not your customers. This is the requirement unique to this standard and the one most often missing.
You must redo the impact assessment when the system, its data or how it is used changes.
Evidence: Review triggers and dated reassessments.
You must have set AI objectives, and they must be able to be measured.
Evidence: Objectives with targets and numbers, consistent with the policy.
For each objective, it must be clear what will be done, by whom, by when, with what, and how you will judge it.
Evidence: An action plan covering all five points.
It must be defined when you add a use case, retrain a model, change data source or provider, or enter a new country, you must plan the change first.
Evidence: Change records with the effects assessed beforehand.
7 Support
Clauses 7.1, 7.2, 7.3, 7.4, 7.5.
You must provide the people, data, tools, computing power and money the system needs.
Evidence: Resource provision records.
You must know what competence AI-related roles need, and you must be able to show your people have it.
Evidence: Competence criteria covering data science, engineering, domain knowledge, risk, legal and oversight roles. Training records.
The people who do impact assessments and human oversight must be specifically competent for that.
Evidence: Their training and experience.
You must be able to answer: Does everyone who uses or is affected by an AI system know the policy, their part in it and what happens if they do not follow it?
Evidence: Awareness records covering all staff, not just the technical team. Ask people.
You must have decided what to communicate about AI, to whom, when and how — including to users and affected people.
Evidence: A communication plan covering internal and external audiences.
You must have the documents and records the standard asks for.
Evidence: A list including the impact assessments, the risk assessment and treatment, the Statement of Applicability and the objectives.
When a document is created or changed, it must be checked and approved before use.
Evidence: Approval on the document.
You must keep model, data and decision records long enough to investigate a challenge to an AI decision.
Evidence: A retention schedule. The period may be set by law rather than by you.
8 Running the system
Clauses 8.1, 8.2, 8.3, 8.4.
You must have planned and put in place the processes needed to meet the requirements.
Evidence: Documented processes and evidence they are performed.
You must control the models, data, APIs and AI services you get from outside.
Evidence: Contracts with requirements. Monitoring of provider performance. Assessment of provider changes to a model or service.
You must reassess AI risk at set intervals and whenever something significant changes.
Evidence: A schedule and dated assessments, with the trigger recorded.
You must be carrying out the risk treatment plan, and recording the results.
Evidence: Treatment plan status with implementation evidence.
You must carry out the AI system impact assessment in practice, and keep the results.
Evidence: Completed assessments retained, with evidence the outcome changed a design, a control or a decision rather than being filed.
9 Checking how you are doing
Clauses 9.1, 9.2, 9.3.
You must have decided what you will measure, how, when and who evaluates it.
Evidence: A monitoring plan covering both system-level measures (accuracy, drift, fairness, error and override rates, incidents) and management system measures.
You must analyse the results rather than just collecting them.
Evidence: Analysis and evaluation records with actions arising.
You must audit the system and the applicable Annex A controls, over a cycle.
Evidence: An audit programme. Audit reports and findings.
The auditors must be independent of the work they audit, and competent in AI.
Evidence: Auditor training and independence records.
Senior management must review the system at planned intervals.
Evidence: Review dates and attendance.
The review must cover everything the standard asks for, including risk and impact assessment results.
Evidence: An agenda covering: previous actions, changes, performance, incidents and complaints, monitoring and audit results, risk and impact assessment outcomes, regulatory developments, resources, improvement.
The review must produce decisions and actions, not just minutes.
Evidence: Decisions and an action list with owners and dates.
10 Putting things right and getting better
Clauses 10.2, 10.1.
When something goes wrong, you must deal with it and work out why.
Evidence: Nonconformity and corrective action records covering AI-specific failures — harmful output, biased results, made-up content acted on, model degradation, misuse.
You must check whether the same weakness exists on another system or use case.
Evidence: Evidence you looked wider.
You must check later that the fix worked, and revisit the risk and impact assessments.
Evidence: A follow-up record. Revised assessments.
You must be able to show the system is better than last year.
Evidence: Trends in incidents, complaints, model performance and audit findings.
Annex A.2 – A.3 Policies and how you are organised
Clauses A.2.2, A.2.3, A.2.4, A.3.2, A.3.3.
You must have a written AI policy, approved and reviewed.
Evidence: The policy with approval and review dates.
Your other must policies — security, privacy, quality, ethics — line up with the AI policy.
Evidence: Evidence the policies are consistent with each other.
You must review the AI policy at set intervals or when something changes.
Evidence: Review records.
It must be clear who is responsible for what across the life of an AI system.
Evidence: A responsibility allocation covering design, build, deployment, operation and retirement.
Staff must be able to raise a concern about an AI system without being punished for it.
Evidence: A reporting route and records of use. Ask people.
Annex A.4 Resources for AI systems
Clauses A.4.2, A.4.3, A.4.4, A.4.5, A.4.6.
You must have written down what resources each AI system depends on.
Evidence: An inventory of the resources per system.
You must know what data resources each system depends on, and where they came from.
Evidence: Data resources documented with source and provenance.
You must know what tools each system depends on.
Evidence: Tooling recorded, including third-party libraries and frameworks.
You must know what computing and system resources each depends on.
Evidence: Compute and infrastructure recorded, including third-party hosting.
You must know what human resources and skills each depends on.
Evidence: People and skills recorded per system.
Annex A.5 Assessing what AI does to people
Clauses A.5.2, A.5.3, A.5.4, A.5.5.
You must have a process for assessing the impact of an AI system on people.
Evidence: The documented process with when it must be used.
That assessment must be recorded and kept.
Evidence: Completed assessments retained.
The assessment must cover the effect on individuals and groups of individuals.
Evidence: Effects on people named, not generic categories.
It must cover the effect on wider society, including environmental cost.
Evidence: Societal effects considered, including the energy used to train and run the model.
Annex A.6 The life of an AI system
Clauses A.6.2.2, A.6.2.3, A.6.2.4, A.6.2.5, A.6.2.6, A.6.2.7, A.6.2.8.
The objectives for each AI system must be written down before it is built.
Evidence: Documented objectives including performance and fairness criteria.
The design decisions and the reasons for them must be recorded.
Evidence: Design records including why that model or approach was chosen.
Each must be system verified and validated against the criteria you set.
Evidence: Test records against the stated criteria, including known failure modes.
Deployment must be controlled, with acceptance criteria met before go-live.
Evidence: Deployment approval against criteria agreed beforehand.
The must be system monitored once it is live — for drift, degradation and errors.
Evidence: Monitoring records showing performance over time.
You must keep enough records to explain how a particular output was produced.
Evidence: Event logging sufficient to investigate an outcome.
You must keep technical documentation for each system, and it must be current.
Evidence: Technical documentation per system with revision history.
Annex A.7 The data behind the AI
Clauses A.7.2, A.7.3, A.7.4, A.7.5, A.7.6.
You must have a process for managing the data used by AI systems.
Evidence: A data management process.
You must know where each dataset came from, and that you are allowed to use it that way.
Evidence: Provenance records with source, licence and permitted use.
You must have quality criteria for the data, and you must check against them.
Evidence: Quality criteria and the assessment results.
Data preparation must be recorded — cleaning, labelling, augmenting, splitting.
Evidence: Preparation records, including how labelling was done and checked.
You must have checked whether the data actually represents the people the system will affect.
Evidence: A representativeness and bias assessment.
Annex A.8 Telling people what they need to know
Clauses A.8.2, A.8.3, A.8.4, A.8.5, A.8.6.
You must document what each system does, its limits and where it stops working well.
Evidence: System documentation covering purpose, capabilities, limitations and assumptions.
You must tell users that AI is being used, where they would not otherwise know.
Evidence: Disclosure in the product or service.
People must be able to report a concern, ask for a review, or challenge an AI outcome.
Evidence: A documented channel with records of use and response.
You must tell affected people what they need to know about AI-assisted decisions.
Evidence: Information provided to people affected, in language they can understand.
You must have arrangements for telling people outside when an AI incident happens.
Evidence: External communication arrangements for AI incidents.
Annex A.9 – A.10 Using AI responsibly, and who else is involved
Clauses A.9.2, A.9.3, A.9.4, A.9.5, A.10.2, A.10.3, A.10.4.
You must have rules about what AI may and may not be used for.
Evidence: A responsible use policy with permitted and prohibited uses.
Human oversight must be defined for each system — who reviews what, when, and they must be able to overrule it.
Evidence: Oversight arrangements per system. Evidence they are real: override rates, review times, cases where the human decided differently.
You must monitor how systems are actually used, against how they were meant to be used.
Evidence: Usage monitoring records.
You must control staff use of general AI tools that are not on your inventory.
Evidence: Rules on tools such as public chatbots. Monitoring or blocking. This is where uncontrolled AI usually enters an organisation.
It must be clear which responsibilities are yours and which belong to your suppliers and partners.
Evidence: A written allocation of responsibilities across the AI lifecycle.
You must check your AI suppliers — their governance, model provenance, data practices and incident reporting.
Evidence: Supplier due diligence records and contract terms.
Where you supply AI to customers, you must tell them what they must do for it to be used safely.
Evidence: Customer-facing obligations documented and communicated.
Using this document
Nothing above asks for a manual, a template pack, or a filing system. It asks for decisions that have been taken deliberately and can be shown to have been taken — which is a far smaller job than most organisations expect, and a different one.
Length is not compliance. A procedure nobody follows is worse than no procedure, because an auditor finds the gap between the two. The test we apply is whether the person who has to do the job recognises their own work in what is written down.
What this covers
See how this looks as a working system
Reading about a requirement and seeing the documentation that satisfies it are different things. In a short demo we open the actual manual, procedures and records set for ISO/IEC 42001, show you how each clause is answered and where your existing way of working already fits. You will know what implementation involves before you commit to it.
More reading
- EU AI Act enforcement begins, and what ISO 42001 does about it
Commission enforcement of general-purpose AI obligations began in August 2026. ISO 42001 maps to seven articles of the Act — and substitutes for none of them.
12 September 2026
- AI governance before the AI strategy
Most organisations deploying AI cannot list the systems they already use. ISO 42001 starts there, which is why it is more useful than it sounds.
12 September 2026
- How Can ISO Consulting Help the Information Technology Sector?
ISO consulting services help IT companies improve data security and meet compliance needs to strengthen processes and build customer trust.
29 November 2024
