ISO/IEC 42001 clauses 4 to 10 are the auditable requirements of the AI management system standard, written in the harmonized structure that ISO management system standards share. Clause 4 covers context, 5 leadership, 6 planning, 7 support, 8 operation, 9 performance evaluation and 10 improvement. Clauses 1 to 3 set scope, references and vocabulary. A certification audit tests clauses 4 to 10 together with the Annex A controls the organization selects.
Each subclause is read from the implementer’s chair. You get the decision or record it produces, a suggested owner, what an auditor checks, and a common mistake. Requirements are paraphrased and never quoted at length. Check exact wording against your licensed copy of ISO/IEC 42001:2023.
How the ten clauses are organized
ISO/IEC 42001 is built from ten numbered clauses and then Annexes A to D. The first three clauses set the frame. Clauses 4 to 10 contain the “shall” statements an auditor tests. At the lowest level of numbering, clauses 4 to 10 break into 32 subclauses, from 4.1 to 10.2.
Four annexes sit behind the clauses. Annex A lists reference control objectives and controls, and Annex B gives implementation guidance for them; both are normative. Annexes C and D are informative. Per Annex A of ISO/IEC 42001:2023, there are 38 controls in nine areas (A.2 to A.10) under ten control objectives. Check each control’s wording in your licensed copy.
The clause text has not moved since publication. As of 30 September 2026, ISO’s catalogue entry for ISO/IEC 42001:2023 shows it as the current edition, with no amendment or revision in progress. CEN adopted the standard without modification as EN ISO/IEC 42001:2026 on 13 March 2026, so European copies carry a different label over the same clauses.
Clauses 1 to 3: scope, one reference and the vocabulary
Clauses 1 to 3 of ISO/IEC 42001 define who the standard is for, which other document it depends on, and what its words mean. An auditor spends little time here, yet each one shapes how the later clauses read. One note does carry “shall” wording: Note 2 to 3.26 requires every identified risk and its controls to be reflected in the SoA.
- Clause 1 (scope) applies the standard to any organization that provides or uses products or services built on AI systems, whatever its size, type or nature. It sets requirements and guidance for an AIMS.
- Clause 2 names one normative reference, ISO/IEC 22989:2022, the AI concepts and terminology standard. The reference is dated, so the 2022 edition is the one that applies.
- Clause 3 imports the terms of ISO/IEC 22989 and adds 26 entries numbered 3.1 to 3.26. Three of them feed directly into later work: AI system impact assessment (3.24), data quality (3.25) and statement of applicability (3.26).
Two definitions change how you scope the work. Under 3.1, “organization” means only the part of a larger entity that sits inside the AIMS scope. Under 3.3, top management can be those who direct that unit. A business unit can therefore run its own AIMS with its own leadership sign-off.
The harmonized structure behind clauses 4 to 10
The harmonized structure is the common clause skeleton that ISO management system standards use, also known by its older name, Annex SL. ISO/IEC 42001 states that it applies that structure, with identical clause numbers, clause titles, core text and common definitions. Its Annex D adds that ISO/IEC 27001 uses the same high-level structure, which makes running the two together easier.
For an implementer, the shared skeleton has two consequences. Management system machinery like document control, audit programs and review meetings can be shared with an existing ISMS or QMS. The AI-specific text, though, sits inside the shared clauses, mostly in 4.1, 6.1 and 8.2 to 8.4.
PDCA as a reading aid
The PDCA cycle (Plan, Do, Check, Act) is the improvement loop ISO uses to describe ISO/IEC 42001. ISO’s AI management systems page says the standard “is built around a ‘Plan-Do-Check-Act’ process”. The mapping below is GAICC’s reading; the standard prints no such table.
| PDCA phase | Clauses | What the phase delivers |
| Plan | 4, 5, 6 | Scope, roles, policy, risk criteria, assessments, the SoA and objectives |
| Do | 7, 8 | Resources, competent people, controlled documents and assessments run in operation |
| Check | 9 | Metrics, internal audits and management review decisions |
| Act | 10 | Corrective actions and improvements fed back into planning |
Some guides put clause 7 under Plan. Either view works. Audit findings cite clause numbers.
Clause order and build order
ISO/IEC 42001 states that the order of its requirements does not show their importance or the order in which to implement them. In practice, scope and the list of AI systems in use come early, because 4.1 roles drive which controls apply. The impact assessment method usually exists before the Statement of Applicability is final, since its results feed the risk assessment.
With the frame set, the next question is what each subclause asks of you.
Every subclause from 4.1 to 10.2 in one table
The master table lists all 32 subclauses of ISO/IEC 42001 clauses 4 to 10 with the implementer output for each. Owner suggestions are GAICC editorial: the standard names top management and “designated management” in a few places and leaves every other assignment to you.
| Subclause | What it asks for, in brief | What the implementer produces | Suggested owner | What the auditor checks |
| 4.1 Context | Relevant issues, a climate change decision, the purpose of each AI system and the organization’s role toward it | Context register with issues, climate decision and an AI role per system | AIMS lead with AI system owners | Roles match how each system is built, sold or used |
| 4.2 Interested parties | Relevant parties, their requirements, and which ones the AIMS addresses | Interested party register with a decision column | AIMS lead with legal | Legal and contract duties appear with an owner |
| 4.3 Scope | Boundaries and applicability, informed by 4.1 and 4.2, kept as documented information | Approved scope statement naming units, AI systems and roles | Top management approves | Stage 1 reads it; Stage 2 tests it against live systems |
| 4.4 AIMS | Set up, run, maintain, improve and document the system and its processes | Process map showing how AIMS processes connect | AIMS lead | Processes run in practice as drawn |
| 5.1 Leadership | Visible commitment: policy fit with strategy, resources, integration, direction | Minutes, budget decisions and messages from leadership | Top management | Interviews with top management |
| 5.2 AI policy | A policy fit for purpose, a frame for objectives, commitments to requirements and improvement | Approved AI policy with version and date | Top management | Approval evidence; staff can find it |
| 5.3 Roles | Assigned, communicated duties, including AIMS conformity and performance reporting | Role descriptions or a RACI, plus appointment records | Top management | Named holders for the two duties the clause lists |
| 6.1.1 General | Risks and opportunities, and AI risk criteria that separate acceptable from unacceptable risk | AI risk criteria and an action plan | Risk lead; criteria approved by management | Criteria cover harm to people as well as to the business |
| 6.1.2 AI risk assessment | A repeatable way to identify, analyze and evaluate AI risks | Risk method and risk register | Risk lead with system owners | Scores stay consistent across systems |
| 6.1.3 AI risk treatment | Treatment options, necessary controls checked against Annex A, an SoA with reasons, a plan, sign-off | Statement of Applicability, treatment plan, residual risk acceptance | Risk lead prepares; designated management approves | A reason for each exclusion; signed acceptance |
| 6.1.4 AI system impact assessment | A process to assess consequences for individuals, groups and societies, with results fed into 6.1.2 | Impact assessment procedure and template | AI system owner with an impact assessor | Results visibly changed a risk entry |
| 6.2 AI objectives | Measurable objectives tied to the policy, monitored and documented, with a plan to reach them | Objectives register with measure, owner and date | Top management sets; owners deliver | Progress data per objective |
| 6.3 Planning of changes | Changes to the AIMS made in a planned way | AIMS change log | AIMS lead | One recent change and its plan |
| 7.1 Resources | Resources for the AIMS determined and provided | Resource plan or budget line | Top management | Named roles have time and tools |
| 7.2 Competence | Required competence defined and met, gaps closed, evidence kept | Competence matrix and evidence files | Learning lead with AIMS lead | Evidence for people in sampled roles |
| 7.3 Awareness | People know the AI policy, their part and the cost of not conforming | Awareness material and completion records | AIMS lead | Short staff interviews |
| 7.4 Communication | What, when, with whom and how the AIMS communicates | Communication plan | AIMS lead | One planned message and proof it went out |
| 7.5.1 General | Documents the standard requires plus those you decide you need | Register of documents and records | Document controller | Listed items exist |
| 7.5.2 Creating and updating | Identification, format, review and approval | Template with owner, version and approval fields | Document controller | Approval fields on sampled documents |
| 7.5.3 Control | Availability, protection, distribution, retention and version control | Document control procedure | Document controller | Version history and access rules |
| 8.1 Operational planning and control | Controlled processes that carry out the clause 6 actions, including outsourced ones | Operating procedures, criteria and supplier controls | Process owners | One AI system traced through its controls |
| 8.2 AI risk assessment | Risk assessments run on a planned cycle and after significant change; results kept | Dated assessment records | Risk lead | Dates against the plan and the change log |
| 8.3 AI risk treatment | The treatment plan carried out and checked; results kept | Treatment status records | Control owners | Proof a treatment happened and worked |
| 8.4 AI system impact assessment | Impact assessments run on a planned cycle and when significant changes are proposed; results kept | Completed impact assessment records | AI system owner | A changed system with a fresh assessment |
| 9.1 Monitoring and measurement | What to measure, how, when to measure and when to analyze; results evidenced | Metric set and results | AIMS lead with owners | Trend data and who reviewed it |
| 9.2.1 Internal audit, general | Audits at planned intervals on conformity and effective implementation | Audit reports | Internal audit lead | Audits scheduled and carried out |
| 9.2.2 Internal audit program | Frequency, methods, duties, planning and reporting; objective auditors | Audit program and audit plans | Internal audit lead | Auditors did not audit their own work |
| 9.3.1 Management review, general | Top management reviews the AIMS at planned intervals | Review calendar | Top management | Reviews took place |
| 9.3.2 Review inputs | Past actions, changes in issues and needs, performance trends, improvement options | Review pack | AIMS lead | Every input is present |
| 9.3.3 Review results | Decisions on improvement and needed changes, evidenced | Minutes with decisions and actions | Top management | Decisions traced into actions |
| 10.1 Continual improvement | Ongoing improvement of suitability, adequacy and effectiveness | Improvement log | AIMS lead | Improvements beyond fixes |
| 10.2 Nonconformity and corrective action | React, find causes, look for similar cases, act, check effectiveness, update the AIMS | Corrective action records | Process owner; AIMS lead tracks | Root cause and an effectiveness check |
Several subclauses name no documented information at all, among them 4.1, 5.3 and 7.3. Auditors still ask for evidence there, so plan a record even where the text does not demand one. Working through these 32 rows with an instructor is the core of GAICC’s Lead Implementer course that works through clauses 4 to 10. Every clause in that range gets at least one module, and the course ends with certification preparation.
Clause 4: context of the organization
Clause 4 of ISO/IEC 42001 decides what the AIMS covers and from whose point of view, and its four subclauses produce the context register, the interested party register, the scope statement and the process map.
The AI-specific demand sits in 4.1. The organization considers the intended purpose of each AI system it develops, provides or uses, and determines its role toward each one. A note lists six role families taken from ISO/IEC 22989: AI providers, AI producers, AI customers, AI partners, AI subjects and relevant authorities. The standard adds that roles can decide whether, and how far, its requirements and controls apply. A wrong role in clause 4 therefore becomes a wrong exclusion in the SoA.
Watch one naming trap, because in 42001 “AI deployer” sits inside the AI producer family, while the legal term “deployer” in the EU AI Act and in Colorado law means something else. Keep legal labels out of the role column.
Clause 4.1 also asks whether climate change is a relevant issue, and the decision should be recorded either way, with a reason. For AI, compute and energy use are the usual starting point.
At Stage 1 the auditor reads the scope statement and compares it with what the organization sells and uses. At Stage 2 the auditor picks an AI system and asks for its role and issue entries. Teams often write scope as a list of departments and never name the AI systems inside it. The text of ISO/IEC 42001 does not contain the term “inventory”, yet a list of AI systems is the practical input to 4.1 and 4.3. The guide to getting the scope right covers role choice and scope wording in depth.
Clause 5: leadership
Top management carries three duties under clause 5 of ISO/IEC 42001: show commitment (5.1), set the AI policy (5.2) and assign roles (5.3). The Lead Implementer prepares the material, but the signatures belong to leadership.
Under 5.2, top management sets a policy that suits the organization’s purpose, frames the AI objectives and commits to meeting requirements and to continual improvement. The policy must be documented, linked to other policies, communicated inside the organization and available to interested parties where appropriate. Writing it well is covered in the AI policy guide.
Clause 5.3 asks top management to assign and communicate responsibilities and authorities. Two duties must have a named owner: keeping the AIMS in conformity with the standard, and reporting AIMS performance to top management. Everything else is your design, which is why a RACI helps. See the roles clause 5 expects for a worked RACI.
Expect interviews with leadership, approval records for the policy and named people for the two duties in 5.3. Two errors recur. In the first, a committee or a security lead approves the AI policy and no one at top management level signs. In the second, a RACI lists every activity but leaves performance reporting unassigned.
Clause 6: planning
Clause 6 of ISO/IEC 42001 is where the AIMS decides what could go wrong, what it will do about it and what it is aiming for. Six subclauses produce the risk criteria, the risk method, the Statement of Applicability, the treatment plan, the impact assessment process, the objectives and the change plan. The full treatment of what clause 6 asks for sits on GAICC’s risk page.
6.1.1 and 6.1.2: risk criteria and risk assessment
AI risk criteria in 6.1.1 separate acceptable from unacceptable risk and support risk assessment, treatment and the assessment of AI risk impacts. Risks are determined in light of each system’s domain, application context and intended use. Clause 6.1.2 then asks for an assessment process that gives consistent, comparable results. Its analysis step looks at consequences for the organization, for individuals and for societies.
The output is a written method plus a risk register, and a frequent error is to reuse an information security matrix scored only on confidentiality, integrity and availability. A matrix like that has no place to record harm to a person who is denied a loan.
6.1.3: risk treatment, the SoA and sign-off
Clause 6.1.3 turns assessed risks into chosen controls, so the organization picks treatment options and determines the controls each one needs. It checks them against Annex A so no needed control is overlooked, adds its own controls where Annex A falls short and considers the Annex B guidance. It then produces a Statement of Applicability and an AI risk treatment plan.
Two approvals sit here. Designated management approves the treatment plan and accepts the residual AI risks. In most organizations that approver sits above the Lead Implementer, who prepares the pack.
A Statement of Applicability lists the necessary controls and justifies each inclusion and exclusion. Two grounds justify an exclusion: the risk assessment found the control unnecessary, or external requirements do not call for it. Annex A is neither mandatory nor exhaustive, as a note to the 3.26 definition says. Read justifying each control you include or exclude before you draft the SoA, and browse the Annex A control set for the controls themselves.
6.1.4: the AI system impact assessment
Clause 6.1.4 asks for a defined process that assesses the consequences an AI system can have for individuals, groups and societies. It covers deployment, intended use and foreseeable misuse, and it takes account of the technical and social setting and the jurisdictions involved. Results are documented and must be considered in the 6.1.2 risk assessment.
The popular line “risk looks inward, impact looks outward” does not fit 42001, because 6.1.2 already weighs harm to individuals and societies. The impact assessment stands as its own documented process, and its findings flow into the risk assessment. Method, triggers and evidence are covered in the AI system impact assessment guide.
[TRAINER INSIGHT NEEDED: In GAICC Lead Implementer course exercises, which clause 6 output do candidates most often get wrong, and what does the corrected version look like?]
6.2 and 6.3: objectives and planned change
AI objectives under 6.2 must align with the AI policy and be measurable where practicable. They are monitored, communicated, updated and documented. For each one, the plan names what will be done, the resources, the owner, the deadline and how results will be judged. Clause 6.3 asks that changes to the AIMS itself be made in a planned way.
Stage 1 looks for the method, the SoA and the plan. Stage 2 traces one risk from register entry to control to evidence, and checks the residual risk signature.
Clause 7: support
People, knowledge and documents are what clause 7 of ISO/IEC 42001 secures for the AIMS. The outputs are a resource plan, a competence matrix, awareness records, a communication plan and a document control system.
Resources come first. Under 7.1 the organization determines and provides what the AIMS needs. Annex A expands this for AI through its area on resources for AI systems, which covers data, tooling, computing and human resources.
Competence under 7.2 starts with defining what each AI-affecting role needs. The organization then shows people meet it, closes gaps and checks the actions worked, keeping the evidence. Attendance lists alone do not prove competence, because they skip the first step. GAICC’s page on competence evidence sets out what counts.
Awareness and communication (7.3 and 7.4) are short subclauses. People doing work under the organization’s control should know the AI policy, how they contribute and what happens if they do not conform. The communication plan answers what, when, with whom and how.
Documented information under 7.5 covers documents the standard requires plus those you decide you need. Each is created with an owner and approval, then controlled for access, version and retention. GAICC’s page on clause 7.5 requirements lists each required document.
Teams often treat awareness as a training course. An auditor tests awareness by asking a developer where the AI policy lives and what it means for their work.
Clause 8: operation
Clause 8 of ISO/IEC 42001 puts into operation what clause 6 designed. Each planning step has an operating twin: 6.1.2 pairs with 8.2, 6.1.3 with 8.3 and 6.1.4 with 8.4.
Subclause 8.1 asks the organization to plan and control the processes needed to meet requirements and carry out the clause 6 actions. Process criteria are set and applied. Externally provided processes, products or services that matter to the AIMS must be controlled too. For most organizations, that phrase is where a hosted model from a supplier enters the AIMS.
Subclauses 8.2 to 8.4 set repeat cycles. Risk assessments are rerun at planned intervals and when significant changes are proposed or occur. Impact assessments are rerun at planned intervals and when significant changes are proposed. The treatment plan is carried out and its effect checked. Results of all three are retained as records.
At Stage 2, auditors take one AI system and walk it through its life: requirements, data, testing, release, monitoring, and they compare assessment dates with the change log. A typical gap is an impact assessment written once for certification and never reopened. Define “significant change” in advance, for example a new user group, a new data source or a retrained model. Without a definition, nobody knows when 8.2 or 8.4 should trigger.
Clause 9: performance evaluation
Whether the AIMS works is the question behind clause 9 of ISO/IEC 42001, performance evaluation. Its outputs are a metric set, an internal audit program with reports, and management review minutes.
9.1 Monitoring, measurement, analysis and evaluation
Under 9.1 the organization decides what to measure, how, when to measure and when to analyze the results. Results are kept as evidence, and the organization evaluates both AIMS performance and effectiveness. Objectives from 6.2 are the natural first metrics.
[TRAINER INSIGHT NEEDED: Which AIMS performance measures do GAICC instructors suggest for an organization’s first year under clause 9.1, and why those?]
9.2 Internal audit
Internal audits under 9.2 run at planned intervals and check conformity with the organization’s own AIMS rules and with the standard, and whether the AIMS is effectively implemented and maintained. The program sets frequency, methods, responsibilities and reporting, and auditors are chosen for objectivity and impartiality. Clause 3.18 allows an external party to run the audit on the organization’s behalf. Set up the internal audit program before you book a certification body.
9.3 Management review
Management review under 9.3 happens at planned intervals. Inputs include actions from earlier reviews, changes in issues and stakeholder needs, performance trends and improvement options. Outputs are decisions on improvement and on changes to the AIMS, kept as evidence.
A sentence that circulates widely says “ISO 42001 requires an annual internal audit and an annual management review.” The standard’s wording is planned intervals. The yearly rhythm comes from certification rules. ISO/IEC 17021-1 calls for surveillance audits at least once a calendar year outside recertification years, according to an accreditation body’s summary of its section 9. The same summary lists a Stage 1 objective: confirm the internal audit and management review are planned and under way. So both must exist before Stage 1, whatever cycle you choose.
Clause 10: improvement
Improvement under clause 10 of ISO/IEC 42001 closes the loop. Subclause 10.1 asks for continual improvement of the AIMS’s suitability, adequacy and effectiveness. Subclause 10.2 sets the steps for a nonconformity.
When something fails, the organization reacts and corrects it, deals with the consequences, finds the cause and checks whether similar failures exist or could occur. It then acts, reviews whether the action worked and changes the AIMS if needed. Records show what went wrong, what was done and the result.
The “similar cases” step matters more for AI than for most systems. A data labeling flaw found in one model often sits in other models trained from the same pipeline. Check the siblings before you close the record.
Auditors sample closed items and ask how you confirmed the fix worked. A finding closed with a correction alone, with no root cause or effectiveness check, leaves nothing to show them. Teams that want structured practice on that loop can take clause-by-clause implementation training, whose modules on nonconformities and corrective action lead into a mock audit.
Clauses 4 to 10 now have their outputs. The remaining questions are how they differ from ISO 27001 and where readers most often go wrong.
Where 42001 departs from ISO 27001
ISO/IEC 42001 and ISO/IEC 27001 share clause numbers and titles, so the differences sit inside the text and in the annexes. The table lists the ones that change an implementer’s workload.
| Point | ISO/IEC 27001:2022 | ISO/IEC 42001:2023 | What it means for you |
| Risk criteria (42001 6.1.1; 27001 6.1.2) | Criteria for information security risk | AI risk criteria that also support assessing AI risk impacts | New criteria for harm to people |
| Risk analysis (6.1.2) | Risks tied to loss of confidentiality, integrity and availability | Consequences for the organization, individuals and societies | Rescore inherited risks |
| Impact assessment (6.1.4, 8.4) | No equivalent | Separate documented process, rerun on schedule and on change | A new process and new records |
| SoA content (6.1.3) | Necessary controls, reasons, and whether each is implemented | Necessary controls with reasons for inclusion and exclusion | Implementation status becomes optional good practice |
| Annex guidance | Annex A normative; guidance in a separate standard, ISO/IEC 27002 | Annex A normative, and Annex B implementation guidance is also normative | Read Annex B as part of the standard |
| Organizational role (4.1) | Not addressed | Role toward each AI system determines applicability | A role column for every system |
Climate change is no longer a difference. ISO/IEC 27001 gained a climate change amendment in 2024, and 42001 included the climate question from the start. For integration steps, read the full ISO 42001 and ISO 27001 comparison.
Common misreadings of clauses 4 to 10
Several statements about ISO/IEC 42001 clauses circulate on ranking pages and in forum threads, and the standard does not support them. Each row gives the claim and what the text supports instead.
| Claim | What the standard supports |
| Internal audits and management reviews must happen every year | Planned intervals; the yearly cycle comes from certification body rules |
| Risk assessment looks inward, impact assessment looks outward | 6.1.2 already covers individuals and societies; 6.1.4 is a separate process feeding it |
| Annex B is informative | Annex B is normative; Annexes C and D are informative |
| Clause 6.1.4 covers objectives for risk treatment | 6.1.4 is the AI system impact assessment; objectives sit in 6.2 |
| You implement the clauses in order, 4 to 10 | The standard says its order is not an implementation order |
| ISO 42001 requires an “AI inventory” | The word is absent; the need is traced through 4.1, 4.3 and the Annex A resource controls |
| Every Annex A control must be implemented | Annex A is neither mandatory nor exhaustive; exclusions need reasons |
Where to begin, by starting position
Your organization’s role and the systems it already runs decide which clauses to open first.
| Starting position | Clauses to open first | Why |
| You build or sell AI systems | 4.1 roles, then 6.1.4 and 8.4 | Producer and provider roles are where the A.6 life cycle controls apply most clearly |
| You only use third-party AI | 4.1, 8.1 and the A.10 supplier controls | Your role is mostly AI customer; the impact assessment still covers how you use each system |
| You hold ISO/IEC 27001 certification | 6.1 criteria, 6.1.4, 8.4 and a new SoA | Clauses 5, 7, 9 and 10 machinery can be reused |
| You are a consultant running a gap review | All 32 rows of the master table | Mark “evidence exists” or “evidence missing” per row |
| You are preparing for the Lead Implementer exam | Clauses 4 to 10 in order, then 6.1.2 to 6.1.4 and 8 | See how the GAICC exam weights these clauses by domain |
For the standard as a whole, including certification and the wider family, start with the standard itself.
Frequently asked questions
What are the requirements of ISO 42001?
The requirements are the “shall” statements in clauses 4 to 10, which split into 32 subclauses from context in 4.1 to corrective action in 10.2. Clause 6.1.3 adds a comparison with the 38 Annex A controls, with each inclusion and exclusion recorded in a Statement of Applicability. Annex B guidance is normative too, while Annexes C and D are informative.
What is the focus of clause 9 in ISO 42001?
Clause 9 asks whether the AIMS is working. Subclause 9.1 sets what you measure and when, 9.2 runs internal audits at planned intervals, and 9.3 has top management review the system and record decisions. The evidence from all three feeds the corrective actions and improvements in clause 10.
Are all of clauses 4 to 10 required for certification?
ISO/IEC 42001 gives an exclusion route only for controls, through the justification rules in 6.1.3 and its notes. Clauses 4 to 10 have no equivalent route, so plan to evidence every subclause, including the ones that name no documented information. Whether the standard itself is mandatory for your organization is a separate question, answered in GAICC’s overview of the standard.
How detailed should a clause-by-clause gap check be?
Work at subclause level, one row for each of the 32 subclauses, because auditors sample at that depth. For each row, record the output that should exist, where the evidence sits and whether it is current. Add a row for each Annex A control you plan to include, since the Statement of Applicability is tested alongside the clauses.
Does an ISO 27001 certificate help with the ISO 42001 clauses?
It helps with the shared machinery. Annex D of ISO/IEC 42001 notes that both standards use the same high-level structure, so document control, internal audit and management review can usually be extended. The AI work is new: risk criteria in 6.1.1, an impact assessment under 6.1.4 and 8.4, and a Statement of Applicability against the 42001 annex.
What happens to clauses 9 and 10 after certification?
Clauses 9 and 10 keep running for the life of the certificate. An accreditation body’s summary of ISO/IEC 17021-1 describes a three-year cycle, with surveillance audits in years one and two and recertification in year three. Each surveillance audit reviews internal audits, management review and action on earlier nonconformities, and Stage 1 and Stage 2 certification audits covers the audit stages..
