ISO/IEC 42001: ISO/IEC 42001 – Tutorial (about 60 minutes)

ISO/IEC 42001 is the international standard that sets out requirements for an AI management system: the policies, roles, processes, controls and records an organisation uses to develop, provide or use artificial intelligence responsibly and to keep AI-related risks under control. It is used by software companies, banks, hospitals, public bodies, cloud providers and any other organisation that builds AI or relies on it, and it was the first international management system standard for AI – one against which an organisation can be independently certified. After this tutorial you will be able to explain what the standard requires and why, read its clause and annex structure, plan an implementation step by step, prepare for a certification audit and relate it to ISO/IEC 27001, the NIST AI Risk Management Framework and the EU AI Act.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current and only edition is ISO/IEC 42001:2023, Information technology – Artificial intelligence – Management system, edition 1, published in December 2023 by ISO and IEC through their joint technical committee for artificial intelligence (ISO/IEC JTC 1/SC 42). It is a requirements standard, so an organisation can be audited and certified against it. No amendment is listed for it and no revision had been announced as of the verification date; like every ISO standard it will be systematically reviewed at least every five years. Its companion ISO/IEC 42006:2025 (published July 2025) sets extra requirements for the certification bodies that audit it. Verified 2026-10-29 against the IEC Webstore listing (edition 1.0, 2023-12-18, 51 pages, no amendments) and the Standards Council of Canada standards database.

Who this is for: engineers, data scientists and architects who build or integrate AI; product owners who decide where AI is used; security, privacy, quality, risk and compliance professionals who are asked to "get us ready for 42001"; internal auditors; and managers who need to understand what a certificate does and does not prove.

Prerequisites: none. Some familiarity with another management system standard such as ISO 9001 or ISO/IEC 27001 helps, because ISO/IEC 42001 shares their skeleton, but every term is explained when it first appears. A rough idea of how machine learning works (a model learns patterns from data and then produces predictions, recommendations or content) is enough on the AI side.

By the end of this tutorial:

You will be able to explain why ISO/IEC 42001 exists, what it covers and what kinds of organisations use it.
You will be able to define the core vocabulary: AI management system, AI policy, AI risk, AI system impact assessment, statement of applicability, interested party, documented information and the AI roles.
You will be able to describe the structure of the standard: clauses 4 to 10 and the four annexes, and how Annex A controls connect to the risk process.
You will be able to plan an implementation, from scoping and policy through risk treatment, controls, internal audit and management review.
You will be able to explain how certification works, who may certify, what auditors look for and what a certificate means.
You will be able to apply the standard to a realistic organisation and produce the main artefacts.
You will be able to position ISO/IEC 42001 next to ISO/IEC 27001, ISO/IEC 23894, ISO/IEC 42005, the NIST AI RMF and the EU AI Act, and avoid the most common implementation mistakes.

Lesson 1 – Origins, purpose and scope

Why AI needed a management system standard

By the early 2020s, AI had moved from research labs into everyday business: credit decisions, medical triage, recruitment screening, fraud detection, customer chatbots, code assistants. With it came new kinds of trouble. Models trained on historical data can repeat old unfairness. A model that performed well in testing can quietly degrade when the world changes. Generative systems can produce confident but false content. Decisions can be hard to explain to the person they affect. And many organisations discovered that nobody could say exactly which AI systems they were running, who owned them, or who had approved them.

Principles for "trustworthy AI" already existed in abundance – fairness, transparency, accountability, safety. What was missing was a practical, auditable way to turn those principles into routine organisational behaviour. That is exactly what a management system does. A management system is the set of interrelated policies, objectives, roles and processes an organisation uses to achieve something consistently, rather than by luck or individual heroics. ISO has decades of experience with them: ISO 9001 for quality, ISO 14001 for the environment, ISO/IEC 27001 for information security. ISO/IEC 42001 applies the same proven pattern to AI.

Who wrote it

The standard was developed by ISO/IEC JTC 1/SC 42, the joint subcommittee of ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) that handles artificial intelligence. National standards bodies from many countries took part and voted on it. SC 42 also produces the surrounding family of AI standards – terminology, risk management guidance, impact assessment guidance, data quality and more – so ISO/IEC 42001 sits at the centre of a growing toolkit.

What it is for

The purpose of ISO/IEC 42001 is to help an organisation develop, provide or use AI systems responsibly while pursuing its own objectives and meeting its obligations to the people and bodies that have a stake in what it does. Three ideas in that sentence matter:

It is about the organisation, not one model. The standard does not certify that a particular chatbot is safe or that a model is accurate. It asks whether the organisation has a working system for governing all the AI within its chosen scope.
It is risk-based. The organisation decides which controls it needs by assessing its own AI risks and impacts, instead of following a fixed checklist.
It balances benefit and harm. The aim is not to stop AI but to use it with eyes open, so that opportunities are pursued and risks are treated deliberately.

Scope

The standard applies to any organisation, whatever its size, type or sector, that provides or uses products or services that make use of AI. That breadth is intentional. A five-person start-up fine-tuning a language model, a global bank buying AI-based fraud detection, a hospital using a diagnostic support tool and a city council running a chatbot can all apply it. The requirements are written generically, and each organisation sets the boundaries of its own management system – for example "the AI products of our analytics division" or "all AI used in customer-facing processes".

It is equally important to know what ISO/IEC 42001 is not. It is not a technical specification for building models, it does not set accuracy thresholds, and it is not a law. It does not replace data protection, product safety or sector regulation; instead it gives the organisation a structured way to identify those obligations and show how it meets them.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 42001 uses the vocabulary of ISO management system standards plus AI terms drawn from ISO/IEC 22989, the AI concepts and terminology standard, which it lists as a normative reference (a document you need in order to apply it). The definitions below are paraphrased.

AI system – a system built to generate outputs – for example content, predictions, recommendations or decisions – that serve objectives people have set for it. Machine learning models are the common case, but rule-based and other techniques can also count.
AI management system (AIMS) – the organisation's set of interrelated policies, objectives, processes and roles for governing AI responsibly. "AIMS" is the abbreviation you will hear constantly.
Interested party – a person or organisation that can affect, be affected by, or believe itself to be affected by a decision or activity. ISO uses this term where others say "stakeholder": customers, regulators, employees, people about whom an AI system makes decisions, suppliers.
AI policy – the top-level statement of intent and direction on AI, approved by top management, which frames the AI objectives and commits the organisation to meeting applicable requirements and to continual improvement.
AI objective – a measurable result the organisation wants to achieve with its AIMS, such as "every production model has an approved impact assessment" or "bias metrics reviewed monthly for all lending models".
Top management – the person or group who directs and controls the organisation at the highest level within the AIMS scope. Leadership responsibilities cannot be delegated away entirely.
AI risk – ISO management system standards describe risk as the effect of uncertainty, and that effect can be negative or positive. For AI, it means whatever could help or prevent the organisation in achieving its AI objectives; the standard asks for both risks and opportunities to be addressed.
AI risk assessment – the process of identifying, analysing and evaluating AI risks against criteria the organisation has set in advance.
AI risk treatment – choosing and implementing options to deal with assessed risks, including selecting controls.
Control – a measure that maintains or modifies risk, for example a data quality review, a human approval step or a monitoring alert.
AI system impact assessment – a documented process for considering the potential consequences of an AI system for individuals, groups and society, including foreseeable misuse. It looks outward, at the people affected, rather than only at risks to the organisation.
Statement of applicability (SoA) – a document listing the controls the organisation needs, with the reasons for including them and the reasons for excluding any Annex A controls. Most organisations also record whether each control is implemented, as ISO/IEC 27001 requires.
Documented information – information the organisation must control and keep, together with the medium it is held on. It covers both documents (such as a policy) and records (evidence that something happened).
Nonconformity – failure to meet a requirement, whether of the standard, the organisation's own procedures or a legal obligation. It must be corrected and its cause addressed.
Continual improvement – recurring activity to enhance the suitability, adequacy and effectiveness of the AIMS.

AI roles

Organisations relate to AI in different ways, and the standard asks each one to work out which roles it plays, because obligations and risks differ. The roles come from ISO/IEC 22989:

AI provider – makes an AI product, service or platform available to others.
AI producer – designs, develops, tests and deploys AI systems (the developer role).
AI customer – uses an AI product or service, including as an end user.
AI partner – contributes services such as data supply, system integration, evaluation or auditing.
AI subject – the person or organisation whose data is used, or who is affected by the system's outputs.
Relevant authorities – regulators and policy makers with power over AI use.

Figure 1 – The AI roles an organisation can play; one organisation often holds several of them at once.

A single organisation frequently plays several roles. A bank that builds its own credit model is a producer and a provider to its own business, and it is a customer when it buys a third-party chatbot. Applicants are AI subjects. Knowing the roles helps scope the AIMS and decide which controls matter: a pure AI customer focuses on supplier selection and responsible use, while a producer must also control development, testing and data.

Lesson 3 – Structure of the standard

The Harmonized Structure

ISO/IEC 42001 follows the ISO Harmonized Structure (formerly called Annex SL), the common skeleton that all modern ISO management system standards share. Clauses 1 to 3 are introductory (scope, normative references, terms and definitions). Clauses 4 to 10 contain the requirements – the "shall" statements an auditor checks. Because ISO 9001, ISO/IEC 27001, ISO 14001 and ISO/IEC 42001 use the same clause numbers and much of the same core wording, an organisation can run several of them as one integrated management system.

Clause 4 – Context of the organisation. Understand internal and external issues relevant to AI (including the organisation's AI roles and the intended purpose of its AI systems), identify interested parties and their requirements, define the AIMS scope and establish the AIMS.
Clause 5 – Leadership. Top management demonstrates commitment, establishes the AI policy and assigns roles, responsibilities and authorities.
Clause 6 – Planning. Address risks and opportunities through three processes – AI risk assessment (6.1.2), AI risk treatment (6.1.3) and AI system impact assessment (6.1.4) – then set AI objectives (6.2) and plan changes to the AIMS in a controlled way (6.3).
Clause 7 – Support. Provide resources, ensure competence, raise awareness, plan communication and control documented information.
Clause 8 – Operation. Plan and control the processes, and actually perform AI risk assessments (8.2), carry out risk treatment (8.3) and perform AI system impact assessments (8.4) at planned intervals and when significant changes occur.
Clause 9 – Performance evaluation. Monitor and measure, run internal audits and hold management reviews.
Clause 10 – Improvement. Improve continually, and handle nonconformities with corrective action.

Notice the pairing between clauses 6 and 8: clause 6 asks you to define the risk and impact processes, and clause 8 asks you to run them in daily operation. Auditors check both: a well-written procedure with no executed assessments is a finding, and so are assessments carried out without an agreed method.

The four annexes

Annex A (normative) – reference control objectives and controls. 38 controls grouped into nine control areas, numbered A.2 to A.10, each with one or more control objectives. The organisation compares the controls it selected during risk treatment with this list to make sure nothing necessary has been overlooked.
Annex B (normative) – implementation guidance. For each Annex A control, practical guidance on how it can be put in place.
Annex C (informative) – potential AI-related objectives and risk sources. Examples of objectives an organisation might pursue (such as fairness, privacy, robustness, safety, security, transparency and explainability, accountability, environmental impact) and sources of risk (such as level of automation, lack of transparency, machine-learning-specific issues, system lifecycle issues and technology readiness).
Annex D (informative) – use across domains and sectors. How the AIMS can be applied in different sectors and integrated with other management system standards.

The nine Annex A control areas

Paraphrasing the topic of each control area:

A.2 Policies related to AI – an AI policy, its alignment with other organisational policies and its regular review.
A.3 Internal organisation – defined AI roles and responsibilities and a way for people to report concerns about AI.
A.4 Resources for AI systems – knowing and documenting the data, tools, computing and human resources AI systems rely on.
A.5 Assessing impacts of AI systems – an impact assessment process, documentation, and consideration of impacts on individuals, groups and society.
A.6 AI system lifecycle – responsible development objectives and processes, requirements, design, verification and validation, deployment, operation and monitoring, technical documentation and event logging.
A.7 Data for AI systems – data acquisition, quality, provenance (where data came from and how it was handled) and preparation.
A.8 Information for interested parties – documentation for users, external reporting channels, communication of incidents and information obligations.
A.9 Use of AI systems – processes and objectives for responsible use, and use in line with the intended purpose.
A.10 Third-party and customer relationships – allocating responsibilities across the supply chain, managing suppliers and considering customers' needs.

Figure 2 – How the requirement clauses and the four annexes fit together around the statement of applicability.

An important design choice: the clauses are mandatory in full – an organisation cannot claim conformity while skipping, say, internal audit – but Annex A controls are a reference set. The organisation includes the controls its risk and impact assessments call for, may exclude others with a justification, and may add controls of its own that are not in Annex A at all. The statement of applicability is where these decisions become visible.

Lesson 4 – How it works in practice

The Plan-Do-Check-Act rhythm

Management systems follow the Plan-Do-Check-Act (PDCA) cycle: plan what you will do and why, do it, check whether it worked, and act on what you learned. The clauses map onto that cycle, and the cycle never stops – AI systems, data, laws and the organisation itself keep changing.

Figure 3 – The Plan-Do-Check-Act cycle and the ISO/IEC 42001 clauses that belong to each phase.

Implementation steps

No two implementations look the same, but most follow a recognisable sequence.

Secure sponsorship and build an AI inventory. Top management agrees to the programme and names an owner. The team lists every AI system in use or under development, including AI features hidden inside purchased software. Many organisations are surprised by how long this list becomes.
Understand context and interested parties. Which laws and contracts apply? What do customers, regulators, employees and affected people expect? Which AI roles does the organisation play for each system? What is each system's intended purpose?
Define the scope. Decide and document which organisational units, AI systems, locations and processes are inside the AIMS, and why. A narrow first scope (one product line) is acceptable if it is honest and the interfaces with out-of-scope parts are understood.
Write the AI policy and assign roles. Top management approves a policy that fits the organisation's purpose. Roles cover the AIMS owner, system owners, data owners, model risk reviewers, and the people who approve deployments and handle concerns.
Define the risk and impact methods. Set risk criteria (how likelihood and consequence are rated, what level of risk is acceptable), and an impact assessment method that considers individuals, groups and society, including misuse. Annex C helps generate candidate risk sources and objectives. ISO/IEC 23894 gives guidance on AI risk management and ISO/IEC 42005 on impact assessment.
Assess, treat and select controls. Run the assessments for each in-scope system, choose treatment options, select controls, compare them with Annex A and produce the statement of applicability and a risk treatment plan. Risk owners approve the plan and accept the residual risk.
Implement controls and supporting processes. Data quality checks, model validation gates, human oversight steps, logging and monitoring, user documentation, incident reporting, supplier clauses, training for staff.
Set objectives and measure. Choose AI objectives and metrics, and start collecting evidence that processes run as designed.
Audit, review and improve. Run an internal audit across the whole scope, hold a management review, fix nonconformities, then repeat on a planned cycle.

How risk, impact and controls connect

The heart of the standard is the loop between assessments and controls. The AI risk assessment asks what could prevent the organisation from meeting its AI objectives or obligations. The AI system impact assessment asks what the system could do to people and society – benefits as well as harms, intended use as well as foreseeable misuse. The results of the impact assessment are an input to the risk assessment: a serious potential harm to applicants is also a risk to the organisation's objectives and obligations. Treatment then selects controls, and the statement of applicability records the result.

Figure 4 – From inventory to impact and risk assessment, control selection, the statement of applicability and ongoing reassessment.

Artefacts you will produce

Typical documented information in an AIMS includes: the scope statement; the AI policy; role descriptions; the risk assessment and impact assessment methods; completed risk and impact assessments; the risk treatment plan; the statement of applicability; AI objectives and progress; competence records; system documentation (purpose, data sources, model details, test results, known limitations); monitoring and event logs; supplier assessments; internal audit reports; management review minutes; and records of nonconformities and corrective actions. The standard does not dictate format. A model card in a repository, a ticket in a workflow tool or a dashboard can be valid evidence if it is controlled – that is, versioned, approved where needed, protected and retrievable.

Roles in practice

Top management owns the policy, objectives and resources and chairs or attends management review. An AIMS manager coordinates the system. System owners are accountable for individual AI systems through their lifecycle. Data scientists and engineers implement lifecycle and data controls. Risk, legal, privacy and security specialists contribute to assessments. Internal auditors provide independent checking. Many organisations also form an AI governance committee to approve high-impact uses. The standard does not prescribe these titles; it requires that responsibilities be defined, assigned and communicated.

Lesson 5 – Assessment, certification and compliance

Ways to use the standard

Organisations use ISO/IEC 42001 in three ways. Some simply align with it, using it as a best-practice blueprint without any external check. Some carry out self-assessment or ask a customer or consultant to perform a second-party review. And some seek third-party certification, where an independent certification body audits the AIMS and issues a certificate. Because 42001 is a requirements standard, certification is possible – unlike guidance documents such as ISO/IEC 23894 or ISO/IEC 42005, which cannot be certified on their own.

Who certifies

Credible certificates come from certification bodies that are accredited by a national accreditation body (for example UKAS in the United Kingdom, ANAB in the United States or DAkkS in Germany). The certification body works to ISO/IEC 17021-1, the general requirements for bodies that audit and certify management systems, and to ISO/IEC 42006, which adds AI-specific requirements, such as the competence auditors need in AI and how audits of AI management systems should be planned. When you see a certificate, check who issued it, whether that body is accredited for ISO/IEC 42001, and what the stated scope covers.

The certification cycle

Figure 5 – The typical accredited certification cycle: two-stage initial audit, yearly surveillance and recertification every three years.

The initial audit has two stages. Stage 1 reviews the design of the AIMS: scope, policy, risk and impact methods, statement of applicability and readiness. Stage 2 tests whether the system actually works: auditors interview staff, sample AI systems, follow the evidence from inventory through assessment to controls and monitoring, and check internal audit and management review. Findings are graded – a major nonconformity (a requirement not met or a process that fails systemically) must be resolved before certification; minor ones need an accepted corrective action plan. Certificates are generally valid for three years, with surveillance audits in between.

What auditors look for

A scope that is clear and does not conveniently leave out the riskiest AI.
Evidence that top management is engaged, not only signing documents.
Risk and impact assessments that are specific to real systems, follow the defined method and are updated when systems change.
A statement of applicability whose inclusions and exclusions are justified by those assessments.
Controls that run in practice: validation records, monitoring alerts that were followed up, supplier reviews, incident handling.
Competence and awareness: people know the policy and their responsibilities.
A functioning check-and-improve loop: internal audits with findings, management reviews with decisions, corrective actions closed.

What a certificate means – and does not mean

A certificate says that, at the time of audit, the organisation's management system for AI within the stated scope conformed to the standard's requirements. It does not say that every AI system is accurate, unbiased or safe, and it does not by itself prove compliance with any law. In the European Union, for example, the AI Act relies on its own harmonised standards, which European standards bodies are developing separately; holding an ISO/IEC 42001 certificate can support, but does not replace, the AI Act's conformity obligations. Treat the certificate as evidence of disciplined governance, not as a product guarantee.

Lesson 6 – Worked example

The organisation

Meridian Lending is a fictional consumer-finance company with 600 employees operating in several countries. It already holds ISO/IEC 27001 certification for information security. It uses three AI systems: an in-house machine learning model that scores loan applications, a fraud-detection service bought from a vendor, and a customer-support assistant built on a third-party large language model. A major banking partner has asked Meridian to show how it governs AI, and regulators in two markets are tightening rules on automated credit decisions. The board decides to implement ISO/IEC 42001 and seek certification within 15 months.

Step 1 – Inventory and roles

The newly appointed AIMS manager, working with IT and procurement, builds an inventory. It finds the three known systems plus two surprises: a marketing team using a generative tool to draft campaign text, and an HR screening feature switched on inside the recruitment software. For each system the team records owner, intended purpose, data used and Meridian's role. For the credit model Meridian is producer and provider (to its own lending operation); for the fraud service and support assistant it is an AI customer; applicants and customers are AI subjects.

Step 2 – Context, interested parties and scope

Workshops identify interested parties: applicants, customers, the banking partner, credit regulators, data protection authorities, employees and the vendors. Their requirements include fair-lending rules, explanation rights for adverse decisions, data protection law and the partner's contractual expectations. Management sets the scope as "the design, development, procurement, deployment and operation of AI systems used in lending, fraud prevention and customer service". The HR feature is turned off until it can be assessed; marketing's generative tool is brought into scope under a usage rule.

Step 3 – Policy, roles and integration

The board approves an AI policy committing Meridian to fair, explainable and secure AI, human review of adverse credit decisions, legal compliance and continual improvement. An AI governance committee (risk, legal, data science, compliance, customer service) approves high-impact systems. Because the ISMS already has document control, internal audit, management review and corrective action processes, Meridian extends them to cover AI rather than building parallel ones.

Step 4 – Impact and risk assessment

For the credit model, the impact assessment considers applicants wrongly refused, groups that might be disadvantaged by proxies for protected characteristics in the data, the consequences of a silent model failure and foreseeable misuse such as staff relying on the score without reviewing borderline cases. It also records benefits: faster decisions and more consistent treatment. These findings feed the risk assessment, which rates "unfair outcomes for a protected group" as high likelihood-times-consequence, "model drift after an economic shock" as high, and "inability to explain refusals" as medium. For the support assistant, the main risks are incorrect answers about loan terms and leakage of personal data in prompts sent to the vendor.

Step 5 – Treatment, controls and statement of applicability

The treatment plan includes: a fairness testing step before each model release, with agreed metrics and thresholds (A.6 lifecycle and A.7 data); monthly drift monitoring with an alert and a fallback to manual underwriting (A.6 operation and monitoring); reason codes generated for every refusal and a human review of borderline cases (A.8 and A.9); restricting the assistant to approved knowledge articles, filtering personal data before prompts leave Meridian and a clear message that customers are talking to an AI (A.8, A.9 and A.10); and contract clauses with both vendors covering incident notification, data use and change notice (A.10). Comparing with Annex A, the team notices it had no channel for staff to raise concerns about AI and adds one (A.3). It excludes no Annex A controls, but marks a few as partially implemented with dates. Risk owners sign the plan and accept the residual risks.

Step 6 – Operate, measure and audit

AI objectives are set: 100 % of in-scope systems with a current impact assessment; fairness metrics within threshold for every release; drift alerts investigated within five working days. Data scientists receive training on the new release gate, and customer-service staff on escalation. After four months of operation the internal audit team, borrowing an auditor with machine learning knowledge from the partner bank, audits the AIMS. It finds that the fraud vendor's model was updated without triggering reassessment – a minor nonconformity. The corrective action adds vendor model changes to the reassessment triggers. Management review examines the metrics, audit results and a near-miss with the assistant, and approves budget for a second data scientist.

Step 7 – Certification

An accredited certification body performs Stage 1 and notes that the scope statement should explain how out-of-scope HR AI is prevented from re-entering use. In Stage 2, auditors sample the credit model end to end – from the inventory entry to the impact assessment, the release gate evidence, drift alerts and the governance committee minutes – and interview staff. Two minor findings are raised and closed with corrective action plans, and Meridian is certified. Its first surveillance audit is scheduled twelve months later, with the HR system expected to join the scope.

What the example shows

The standard did not tell Meridian which fairness metric to use or what accuracy to achieve; it made Meridian decide, document, check and improve those choices. The real value came from the inventory (which exposed unmanaged AI), from linking impacts on people to business risk, and from reusing the existing ISMS machinery.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 42001 rarely works alone. It provides the management "container"; other documents fill it with guidance, specialised methods or legal duties.

Standard or framework	Type	Focus	Relationship to ISO/IEC 42001
ISO/IEC 27001	Certifiable management system standard	Information security	Same Harmonized Structure and a similar Annex A and SoA approach; often run as one integrated system, though AI risks such as fairness go beyond security.
ISO/IEC 27701	Privacy information management standard	Personal data protection	Complements 42001 where AI systems process personal data.
ISO 9001	Certifiable management system standard	Quality	Shared skeleton; useful for AI embedded in products and services.
ISO/IEC 22989	Terminology standard	AI concepts and vocabulary	Normative reference for 42001; source of the AI roles.
ISO/IEC 23894	Guidance	AI risk management, based on ISO 31000	Explains how to perform the AI risk assessment and treatment that 42001 requires.
ISO/IEC 42005	Guidance	AI system impact assessment	Explains how to run the impact assessments that 42001 requires.
ISO/IEC 42006	Requirements for certification bodies	Auditing and certifying AIMS	Governs how 42001 certification audits are performed.
NIST AI Risk Management Framework	Voluntary framework (United States)	AI risk outcomes: Govern, Map, Measure, Manage	No certification; its practices can feed 42001 risk work, and many organisations map the two.
EU AI Act (Regulation (EU) 2024/1689)	Law	Risk-based obligations for AI in the EU	Legal duties apply regardless of certification; a 42001 AIMS can organise and evidence compliance but is not a substitute.

Integrating with an existing ISMS

Organisations already certified to ISO/IEC 27001 have a head start: document control, internal audit, management review and corrective action can be shared, and the SoA concept is familiar. The genuinely new work is AI-specific: the AI inventory and roles, impact assessment, lifecycle and data controls, fairness and transparency topics, and the competence to judge models. Many certification bodies can audit both standards together.

Using frameworks inside the AIMS

The NIST AI RMF and its profiles offer detailed risk practices; ISO/IEC 23894 and 42005 give methods; sector rules (medical devices, financial model risk management, automotive safety) add their own requirements. ISO/IEC 42001 asks you to identify the relevant ones in clause 4 and to show in your risk treatment and controls how you meet them. Used this way, one set of evidence can serve several audiences.

Common pitfalls and best practices

Pitfalls

Paper-only systems. Writing policies and templates but never running assessments on real systems. Auditors sample live evidence and will find the gap.
Scoping out the hard parts. Leaving the riskiest AI out of scope to make certification easier undermines trust in the certificate and leaves the real risk unmanaged.
Treating Annex A as a checklist. Implementing all 38 controls without linking them to assessed risks produces cost without focus and an SoA that cannot justify itself.
Forgetting purchased AI. Ignoring AI embedded in vendor software or used through cloud services, where much of the organisation's exposure sits.
One-off assessments. Assessing a system once at launch and never again, even after retraining, new data or new user groups.
Confusing the certificate with product assurance. Telling customers that certification proves a model is unbiased or legally compliant.
Building a parallel bureaucracy. Creating AI-only processes that duplicate existing security, privacy and quality machinery.

Best practices

Start with an honest inventory and keep it current through procurement and change management.
Link impacts to risks. Feed impact assessment findings into risk assessment so harms to people become managed business risks.
Define reassessment triggers such as retraining, new data sources, new uses or user groups, vendor model updates and monitoring anomalies.
Integrate with existing management systems and engineering workflows: put validation gates in the release pipeline rather than in a separate document.
Build competence in auditors and reviewers so they can question data and models, not only documents.
Make top management visible through the governance committee, objectives and management review decisions.
Measure what matters: a small set of AI objectives tied to real risk outcomes, reviewed regularly.

Summary and key takeaways

ISO/IEC 42001:2023 is the requirements standard for an AI management system, published by ISO and IEC (JTC 1/SC 42); it is current, with no amendment or announced revision as of 2026-10-29.
It governs the organisation's approach to AI within a defined scope; it does not certify individual models or set technical performance thresholds.
It uses the Harmonized Structure (clauses 4 to 10), so it integrates naturally with ISO/IEC 27001, ISO 9001 and others.
Three planning processes sit at its core: AI risk assessment, AI risk treatment and AI system impact assessment – defined in clause 6 and executed in clause 8.
Annex A offers 38 reference controls across nine control areas; the statement of applicability records which are needed, which are excluded and why.
Annexes B, C and D add implementation guidance, example objectives and risk sources, and sector and integration guidance.
Accredited certification bodies, working to ISO/IEC 17021-1 and ISO/IEC 42006, certify through a two-stage audit, yearly surveillance and three-year recertification.
A certificate shows disciplined governance; legal obligations such as the EU AI Act must still be met on their own terms.

Reflection questions

List the AI systems your organisation uses or builds, including AI inside purchased software. For each one, which AI roles does your organisation play?
If you had to set a first AIMS scope, where would you draw the boundary, and how would you defend it to an auditor who asked about the systems you left out?
Pick one AI system you know. What would its impact assessment say about affected people, foreseeable misuse and benefits, and which risks would that create for the organisation?
Which Annex A control areas would be most important for an organisation that only buys AI services, and which would matter more for one that develops models?
What evidence would you show a Stage 2 auditor to prove that your AI risk process actually runs, rather than only existing on paper?