ISO/IEC 42001 Annex A is the normative annex that sets out reference control objectives and controls, which an organization checks its AI risk treatment against. Per Annex A of ISO/IEC 42001:2023, there are 38 controls, grouped under ten control objectives across nine areas numbered A.2 to A.10. No control is automatically mandatory. Under clause 6.1.3 you compare the controls your risk treatment needs with Annex A. You then record each inclusion and each exclusion, with a reason, in the Statement of Applicability.
The Annex A in ISO/IEC 42001 should not be confused with the one in ISO/IEC 27001. The 27001 annex holds 93 information security controls. The 42001 annex governs AI work: impact assessment, data provenance, intended use and supplier responsibilities. Annex A also differs from Annex B. Annex B gives implementation guidance for the same controls and numbers its sections B.2 to B.10 to match. The register on this page lists all 38 controls, each with its plain-English intent, the usual evidence and the usual owner.
GAICC paraphrases the standard here and reproduces only control numbers and short titles. Before building a register from it, confirm each control’s wording in your licensed copy of ISO/IEC 42001:2023.
Annex A status and counts at a glance
ISO/IEC 42001 labels Annex A normative in its published table of contents, and it labels Annex B normative as well. C and D carry the informative label. A normative annex is part of the requirements text, so an auditor may test whether you know it and how you applied it.
| Annex | Published label | Title (short) | What it gives an implementer |
| A | Normative | Reference control objectives and controls | The 38 controls you compare your risk treatment against |
| B | Normative | Implementation guidance for AI controls | One guidance section for each Annex A control |
| C | Informative | Potential AI-related organizational objectives and risk sources | Candidate AI objectives and risk sources for clauses 6.1 and 6.2 |
| D | Informative | Use of the AI management system across domains or sectors | Sector notes and integration with other management systems |
Page numbers in the published table of contents show where the weight sits. Annex A starts on page 17 and takes about four pages, while Annex B starts on page 21 and runs until Annex C begins on page 46. Most of what you need to know about a control sits in its Annex B section, since the Annex A entry is a single sentence.
Per-area counts
ISO/IEC 42001 Annex A opens with A.1, a general clause, and places its controls in nine areas from A.2 to A.10. Each area starts with an objective, and A.6 carries two of them: one for management guidance on AI system development (A.6.1) and one for the life cycle itself (A.6.2). That gives ten objectives in all.
| Area | Area title | Objectives | Controls |
| A.2 | Policies related to AI | 1 | 3 |
| A.3 | Internal organization | 1 | 2 |
| A.4 | Resources for AI systems | 1 | 5 |
| A.5 | Assessing impacts of AI systems | 1 | 4 |
| A.6 | AI system life cycle | 2 | 9 |
| A.7 | Data for AI systems | 1 | 5 |
| A.8 | Information for interested parties of AI systems | 1 | 4 |
| A.9 | Use of AI systems | 1 | 3 |
| A.10 | Third-party and customer relationships | 1 | 3 |
| Total | 10 | 38 |
The counts are per Annex A of ISO/IEC 42001:2023. Confirm each control’s wording in a licensed copy.
What ranking pages and AI answers get wrong
Several pages that rank for Annex A searches carry structural errors. GAICC checked them against the published table of contents and found six patterns, listed here without naming the publishers.
| What the page or answer says | What the published text shows |
| A guide on page one of Google calls A.5 “AI System Lifecycle” and A.6 “Data”, and lists eight areas | Nine areas; A.5 holds the four impact assessment controls the guide drops |
| Annex B is informative (at least two ranking pages) | ISO’s published contents list marks Annex B normative |
| Annex A is informative (a documentation site AI answers cite on the SoA) | Annex A is normative |
| Annex A has nine control objectives | Nine areas and ten objectives, because A.6 has two |
| A widely cited vendor guide summarizes A.2 as two controls, A.5 as three and A.6 as eleven | Its own detailed headings list three, four and nine |
| A Google AI answer lists A.2.3 as a review control and A.2.4 as an availability control | A.2.3 is alignment with other policies and A.2.4 is review of the AI policy |
Normative status still leaves room for selection. A note in the standard’s own definition of the Statement of Applicability says an organization might need fewer controls than Annex A lists, or more. What the normative label adds is that the selection itself can be audited.
All 38 Annex A controls in one register
The register lists every ISO/IEC 42001 Annex A control by ID and short title, as publicly enumerated. The “What it asks” column is GAICC’s plain-English paraphrase of each control’s intent. The evidence and owner columns are GAICC editorial guidance, because the standard names no job titles. Treat each title and paraphrase as provisional until you have matched it to a licensed copy.
| ID | Short title | What it asks (GAICC paraphrase) | Typical evidence | Typical owner role |
| A.2.2 | AI policy | Set a written policy for how the organization builds or uses AI | Approved policy with version and sign-off | Top management, drafted by the AIMS lead |
| A.2.3 | Alignment with other organizational policies | Find where existing policies touch AI work and align them | Cross-reference log for privacy, security, procurement and HR policies | AIMS lead with policy owners |
| A.2.4 | Review of the AI policy | Review the AI policy on a planned cycle and when things change | Review minutes and change history | AIMS lead; top management approves |
| A.3.2 | AI roles and responsibilities | Define who is responsible for which AI work, then assign it | Role descriptions, RACI, appointment records | Top management |
| A.3.3 | Reporting of concerns | Give people a protected way to raise concerns about AI systems | Reporting procedure and case log | Ethics or compliance lead |
| A.4.2 | Resource documentation | Identify and record what each AI system needs across its life cycle | AI system register with resource fields | AI system owner |
| A.4.3 | Data resources | Record facts about the data each AI system uses | Dataset records: source, purpose, category, retention | Data owner |
| A.4.4 | Tooling resources | Record the tools used to build and run AI systems | Tool list with versions and platforms | ML engineering lead |
| A.4.5 | System and computing resources | Record the computing and infrastructure each system depends on | Infrastructure records and cloud account map | Platform or IT lead |
| A.4.6 | Human resources | Record the people and skills each system relies on | Skills matrix linked to each system | AI system owner with HR |
| A.5.2 | AI system impact assessment process | Run a defined process for judging consequences for people and society | Approved procedure with triggers and thresholds | AIMS lead or risk lead |
| A.5.3 | Documentation of AI system impact assessments | Record the results and keep them for a set period | Completed assessments and a retention rule | Impact assessor |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Assess and record likely effects on people and groups | Affected-group sections with sign-off | Impact assessor with legal or privacy |
| A.5.5 | Assessing societal impacts of AI systems | Assess and record wider effects on society | Societal impact section with sign-off | Impact assessor |
| A.6.1.2 | Objectives for responsible development of AI system | Set objectives that steer responsible development and build them into the life cycle | Development objectives inside engineering standards | Head of AI or engineering |
| A.6.1.3 | Processes for responsible AI system design and development | Define and record the design and development process | Documented AI development life cycle with stage gates | Engineering lead |
| A.6.2.2 | AI system requirements and specification | Specify requirements for new systems and major changes | Requirements specification with acceptance criteria | Product owner |
| A.6.2.3 | Documentation of AI system design and development | Record design and build decisions against the requirements | Design records, model cards, architecture decisions | ML engineering lead |
| A.6.2.4 | AI system verification and validation | Define how each system is tested and what counts as a pass | Test plans, evaluation results, release sign-offs | Evaluation or QA lead |
| A.6.2.5 | AI system deployment | Plan each release and confirm requirements are met first | Release plan and go-live approval | Release manager |
| A.6.2.6 | AI system operation and monitoring | Define what running the system involves: monitoring, fixes, updates and support | Monitoring dashboards, runbooks, change tickets | Operations or MLOps lead |
| A.6.2.7 | AI system technical documentation | Decide what technical documentation each audience needs and supply it | Documentation set per audience | Product owner |
| A.6.2.8 | AI system recording of event logs | Decide when event logs are kept, at least while the system is in use | Logging settings, retention rules, sample logs | Platform lead |
| A.7.2 | Data for development and enhancement of AI system | Define and run data management for building and improving systems | Data management procedure | Data owner |
| A.7.3 | Acquisition of data | Record how data is obtained and selected | Acquisition records, licenses, legal basis | Data owner with legal |
| A.7.4 | Quality of data for AI systems | Set data quality requirements and check data meets them | Quality criteria and validation reports | Data steward |
| A.7.5 | Data provenance | Keep a record of where data came from and how it changed | Lineage records | Data engineering lead |
| A.7.6 | Data preparation | Set criteria for preparing data and record the methods used | Preparation specifications for labeling, cleaning and splitting | Lead data scientist |
| A.8.2 | System documentation and information for users | Work out what users need to know and give it to them | User guides, notices, stated limitations | Product owner |
| A.8.3 | External reporting | Let interested parties report adverse impacts of a system | Public reporting route and intake log | Customer support or compliance |
| A.8.4 | Communication of incidents | Plan how AI incidents are communicated to users | Incident communication plan and notices sent | Incident manager |
| A.8.5 | Information for interested parties | Decide and record what must be reported, and to whom | Reporting obligations register | Legal or compliance |
| A.9.2 | Processes for responsible use of AI systems | Define how AI systems are used responsibly | Acceptable use procedure and approvals | Business system owner |
| A.9.3 | Objectives for responsible use of AI system | Set objectives that steer responsible use | Use objectives with measures | Business system owner |
| A.9.4 | Intended use of the AI system | Make sure systems are used as intended and as documented | Intended use statements, usage monitoring, exception records | Business system owner |
| A.10.2 | Allocating responsibilities | Split life cycle duties between you, partners, suppliers and customers | Responsibility matrix in contracts | Procurement with legal |
| A.10.3 | Suppliers | Make sure supplied products and services fit your responsible AI approach | Supplier assessments and contract clauses | Vendor risk or procurement |
| A.10.4 | Customers | Take customer expectations and needs into account | Customer requirements, contract terms, feedback records | Product or account lead |
Two owner terms recur. The AIMS lead runs the management system day to day. The AI system owner is the business person accountable for one AI system. For a full assignment model, see who does what in an AIMS.
How Annex A controls are selected
ISO/IEC 42001 Annex A controls are selected through AI risk treatment under clause 6.1.3, which starts from your risks and turns to the annex afterward. The sequence below follows the standard’s clause logic as public reproductions of clauses 6.1.2 to 6.1.4 describe it.
- Run the AI system impact assessment under clause 6.1.4.
- Feed its results into the AI risk assessment under clause 6.1.2.
- Pick how to treat each risk and work out the controls each treatment needs.
- Check those controls against Annex A to catch anything necessary you left out, and consider the Annex B guidance.
- Add any controls the risks need that Annex A does not contain.
- Record every control, included or excluded, with a justification in the Statement of Applicability.
- Get the treatment plan and the residual AI risks approved by designated management.
Step 4 is where gaps appear. Teams often open Annex A first and write the risk assessment around it. Auditors then find controls with no risk behind them, and risks with no control in front of them.
Exclusions and their grounds
An Annex A exclusion needs a reason an auditor can trace. Secondary reproductions of clause 6.1.3 name two grounds. The risk assessment found the control unnecessary, or no applicable external requirement calls for it. “Not relevant to us” with no link to an assessment result is the weak form, and auditors push back on it.
Your organizational role drives many exclusions. Clause 4.1 requires you to determine your roles with respect to your AI systems. A note to that clause adds that roles can determine which requirements and controls apply, and how far. ISO/IEC 42001 takes its role set from ISO/IEC 22989: AI provider, AI producer, AI customer, AI partner, AI subject and relevant authorities. One trap catches US readers. The “AI deployer” in 22989 is a kind of AI producer. A legal “deployer” under the EU AI Act or Colorado law is a different category.
Illustrative example: an AI customer that builds nothing
The example below is illustrative and built from the standard’s structure. It describes no real organization. Picture a regional bank that licenses a third-party AI writing assistant for its staff and trains no models.
| Control group | Typical stance for this bank | What the bank records |
| A.6.1.2, A.6.1.3, A.6.2.2 to A.6.2.4 | Often excluded | No development in scope; the supplier carries design and testing under A.10 |
| A.6.2.5, A.6.2.6, A.6.2.8 | Usually included | The bank still rolls out, runs, monitors and logs the assistant |
| A.7.2 and A.7.6 | Often excluded | No training or data preparation by the bank |
| A.7.3 to A.7.5 | Reopened if staff feed in documents | A connected document store or prompt library is data going into the system |
| A.5.2 to A.5.5 | Included | Impact assessment applies whatever the role |
| A.9.2 to A.9.4 and A.10.2 to A.10.4 | Included, and central | Use rules and supplier terms carry most of the risk treatment |
The same bank would face a different register if it later fine-tuned a model on customer letters. Role changes reopen the register.
Controls you add yourself
Clause 6.1.3 expects you to add controls that your risks need and Annex A lacks. Agentic AI is the clearest case today. Take an agent that can send email or move money. It may need tool permission limits, human approval for named actions, and a tested way to halt it. None of those has its own Annex A line. Give each one an organization-defined ID, such as ORG.1, and treat it like any other control in the register.
Recording all of this is the job of the Statement of Applicability, which covers columns, versioning and approval in depth.
A.2 Policies related to AI
Policy work under A.2 has three parts: writing the AI policy, aligning it with other policies and reviewing it. A.2.2 echoes clause 5.2. One policy document usually satisfies both. The common finding is a policy that reads like a values statement and commits to nothing an auditor can test. Write each commitment so it points to a process, an owner or a record.
Alignment under A.2.3 is mostly cross-referencing. Privacy, information security, procurement and acceptable use policies all touch AI work, so a short alignment log should show where each one applies and who changed what. Review under A.2.4 runs on a planned cycle and on triggers such as a new regulation or a new class of AI system. The detail of contents, approval and objectives sits in AI policy requirements.
A.3 Internal organization
Accountability is the subject of A.3: who is responsible for AI work and how people raise concerns about it. Clause 5.3 names two assignments top management must make, conformity of the AIMS and reporting on its performance. A.3.2 extends that to every role the AI work needs, from impact assessor to data owner.
A.3.3 asks for a channel to report concerns about AI systems. Annex B points to ISO 37002, the whistleblowing management system standard, for how such a channel can work. Many organizations reuse an existing ethics hotline. That works if the intake form names AI systems and the case log can show AI concerns as a separate category. Keep A.3.3 distinct from A.8.3. Annex B aims A.3.3 at employed and contracted persons, while A.8.3 gives interested parties outside the organization a route to report adverse impacts.
A.4 Resources for AI systems
Resource documentation is the work of A.4, which asks you to record what each AI system depends on: data, tools, computing and people. The word “inventory” does not appear in ISO/IEC 42001. The expectation to know what AI you run is pieced together from clauses 4.1 and 4.3 and the five A.4 controls. In practice A.4 is where the AI system register gets built.
A workable register has one row per AI system, including third-party SaaS tools with AI features. Its columns cover purpose, owner, data sources, tools, hosting and the people who run it. NIST’s AI RMF names the same practice “inventory” in GOVERN 1.6. A.4.6 links to clause 7.2, because the skills you record become the competence you have to evidence. The register also gives auditors their sampling frame, so a missing system weakens every control that depends on it.
A.5 Assessing impacts of AI systems
Four controls in A.5 turn the impact assessment of clause 6.1.4 into a process, documentation, effects on individuals and groups, and effects on society. Under A.5.3 the results are kept for a defined period, so set the retention rule before the first assessment.
The popular split that “risk assessment looks inward, impact assessment looks outward” is wrong under ISO/IEC 42001. Clause 6.1.2 already asks about effects on individuals and on societies. Clause 6.1.4 is a separate documented assessment whose results feed the risk assessment. Clause 8.4 repeats it at planned intervals or when significant changes are proposed. ISO/IEC 42005:2025 gives detailed guidance on running these assessments, though ISO/IEC 42001 predates it and does not cite it. Triggers, thresholds and sign-off are covered under the AI impact assessment.
A.6 AI system life cycle
Nine controls under two objectives make A.6 the largest area. A.6.1 sets the objectives and processes for responsible development. A.6.2 then walks the life cycle: requirements, design records, verification and validation, deployment, operation and monitoring, technical documentation and event logs.
Evidence for A.6 lives in engineering tools. Tickets, pull requests, evaluation reports, release approvals and monitoring alerts become the records an auditor reads. Auditors often trace one system end to end, from a requirement to its test result to a live monitoring alert. If those records sit in three tools with no shared ID, the trace breaks.
Builders and buyers differ here, because a team that only buys AI usually keeps deployment, operation and logging and justifies the build controls. For A.6.2.8, decide which life cycle phases keep event logs, with at least the period of use covered. ISO/IEC 24970 on AI system logging was still at the final draft ballot stage, unpublished, when GAICC checked iso.org on 6 October 2026.
A.7 Data for AI systems
Data used to build and run AI systems falls under A.7, which covers management, acquisition, quality, provenance and preparation. ISO/IEC 42001 defines data quality as data meeting the organization’s own requirements for a specific context. The A.7.4 requirement therefore starts with written quality criteria, and tooling comes after them.
Retrieval sources count. A document store behind a chatbot, or a library of example prompts, is data going into the system. One practitioner on a public AI governance forum placed such a library in both A.7 and A.6, since it is also a built component. Provenance under A.7.5 is where most teams lack records, especially for older datasets bought or scraped before anyone asked where they came from. Field-level guidance, including the ISO/IEC 5259 data quality series, sits in data controls under A.7.
A.8 Information for interested parties
Disclosure is the theme of A.8: what you tell users and other interested parties about your AI systems. Its four controls cover user information, a route for outside reports of adverse impacts, and incident communication. The fourth covers reporting duties to others, such as regulators or customers.
A.8.4 reaches beyond the security incident plan. A model that starts producing biased loan letters is an AI incident even when no data has leaked. The communication plan should name who decides to notify users, what triggers it and which template applies. A.8.5 works best as a register of obligations by audience, maintained with legal, because customer contracts often add reporting duties that no regulation imposes on its own.
A.9 Use of AI systems
Responsible use by the organization itself is the subject of A.9: use processes, use objectives and intended use. Almost every organization in scope needs these controls, including one that builds nothing. For buyers, A.9 and A.10 usually carry most of the risk treatment.
A.9.4 catches shadow AI. Staff who paste client files into a public chatbot are using an AI system outside its intended use. Evidence for A.9 therefore mixes rules with signals: an acceptable use procedure, usage monitoring, and records of exceptions granted or refused. Use objectives under A.9.3 connect to the AI objectives that clause 6.2 asks you to plan and measure.
A.10 Third-party and customer relationships
A.10 covers responsibilities shared with partners, suppliers and customers. A.10.2 splits life cycle duties, A.10.3 checks suppliers against your responsible AI approach, and A.10.4 takes customer needs into account.
A supplier’s certificate stops at the supplier’s boundary. Microsoft’s ISO/IEC 42001 compliance page makes the point directly: customers still have to bring in their own assessor for the controls inside their own organization. File the certificate as supplier evidence, then assess the use you make of the service. Contract clauses carry most A.10 evidence: model change notice, incident notice, data use limits and audit rights. The vendor assessment method is set out in third-party AI supplier controls.
What Annex B, C and D add to the controls
Annex B of ISO/IEC 42001 is normative implementation guidance with one section for each Annex A control, numbered to match. Clause 6.1.3 asks you to consider it when you decide how to implement a control. Annex B is where control topics get concrete, such as what to record about data resources or which groups an impact assessment should consider.
Annex C is informative and lists candidate AI objectives, from accountability and fairness to transparency and explainability. It also lists risk sources, such as level of automation and system life cycle issues. The objectives feed clause 6.2 and the risk sources feed clause 6.1.2. Annex D is also informative. It covers using the AIMS across sectors and integrating it with other management system standards.
How Annex A relates to ISO/IEC 27001 Annex A
ISO/IEC 42001 Annex A and ISO/IEC 27001 Annex A share a role and differ in subject. Both are reference control sets that the Statement of Applicability is checked against. The 27001:2022 set holds 93 information security controls in four themes. The 42001 set holds 38 AI controls over nine areas and gives impact assessment an area of its own.
Three structural differences matter for a team that runs both. First, 27001 keeps its control guidance in a companion standard, ISO/IEC 27002, while 42001 keeps it inside Annex B. Second, 27001 clause 6.1.3 asks the Statement of Applicability to show whether every needed control has been put in place. Public reproductions of 42001 clause 6.1.3 do not list that element, although an implementation status column is still good practice. Third, 42001 lets roles shape applicability far more than 27001 does. The control-by-control carry-over is mapped in how the two Annex A sets compare in practice.
Mapping Annex A to the NIST AI RMF
A crosswalk listed on NIST’s AI Resource Center maps NIST AI RMF subcategories to ISO/IEC 42001 clauses and Annex B guidance sections. Three caveats apply. Microsoft provided the crosswalk. It maps the final draft of 42001 instead of the published text, and NIST states that listing a crosswalk does not imply endorsement. The rows below are taken from that crosswalk; B numbers mirror the Annex A control numbers.
| NIST AI RMF subcategory (theme) | Main Annex B sections the crosswalk maps it to (selection) |
| GOVERN 1.6 (inventory of AI systems) | B.4.2 to B.4.6 |
| GOVERN 2.1 (roles and lines of communication) | B.3.2, with clause 5.3 |
| GOVERN 6.1 and 6.2 (third-party risk and contingency) | B.10.2 and B.10.3 |
| MAP 2.3 (scientific integrity and TEVV, including data) | B.7.2 to B.7.6, with B.6.1.3 and B.6.2.7 |
| MEASURE 2.6 (regular safety evaluation) | B.6.2.8, with B.6.2.4 and B.6.2.6 |
| MANAGE 1.1 (whether the system meets its intended purpose) | B.9.2 to B.9.4 |
A team that already reports against the NIST AI RMF 1.0 can reuse evidence through these rows, after checking each mapping against the published 42001 text. The full list sits with the other crosswalks on NIST’s AI Resource Center.
Other control sets map to Annex A too. Version 1.1 of the Cloud Security Alliance’s AI Controls Matrix, out since June 2026, has 247 control objectives in 18 domains and a mapping to ISO/IEC 42001. Cloud teams use it to find technical controls that sit below the level of an Annex A line.
What auditors do with Annex A
Certification auditors use Annex A as the frame for testing your control set, and they read the reasons behind each selection before sampling the controls themselves. ISO/IEC 42006 sets rules for AIMS certification bodies. Its final draft requires the audit team, taken together, to cover knowledge of all Annex A controls and their implementation. At Stage 1 the auditor reads the Statement of Applicability and its reasons. At Stage 2 the auditor samples records to see whether the selected controls operate in practice.
The strongest preparation is a trace you can show on demand: a risk, the control chosen to treat it, the owner, and three recent records. One ISO/IEC 27001 practitioner on a public forum named weak mapping of risks back to Annex A controls as one of two findings that come up time after time. The same weakness carries straight into ISO/IEC 42001 audits. GAICC’s Lead Implementer training on selecting and evidencing controls practices that trace, with modules on clause 6 planning and on Stage 1 and Stage 2 audits.
[TRAINER INSIGHT NEEDED: Which Annex A control do GAICC instructors see implementers struggle most to evidence at Stage 2, and what record finally satisfied the auditor?]
Where to start, by your situation
Annex A work starts in different places depending on your role and existing systems.
- Organizations that only buy AI begin with A.9, A.10 and A.5, then build the A.4 register. Most A.6 build controls will need a recorded justification in place of an implementation.
- Teams that build or fine-tune models carry the most evidence in A.6 and A.7, so dataset and model records belong under version control from the first sprint.
- An organization already certified to ISO/IEC 27001 can reuse document control, internal audit and supplier review, then add the AI-specific controls. Check where the Statement of Applicability sits within the documentation set.
- Anyone mapping clauses against controls can pair this register with what the implementer produces, clause by clause.
- Program leads planning the whole rollout should sequence the controls inside the wider work of implementing an AIMS.
- Lead Implementer exam candidates should learn the nine area titles, the two A.6 objectives and the selection logic in clause 6.1.3. Practice reasoning about applicability instead of memorizing control numbers. GAICC’s 42001 control implementation course pairs that material with an exam simulator.
Frequently asked questions
How many controls are there in ISO 42001?
Annex A of ISO/IEC 42001:2023 lists 38 controls under ten control objectives in nine areas, A.2 to A.10. A.6, the AI system life cycle, is the largest area with nine controls, and each control has a matching guidance section in Annex B. Confirm the wording of every control against a licensed copy before you build your register.
Is Annex A mandatory in ISO 42001?
Annex A is normative, so the comparison step in clause 6.1.3 is required and the Statement of Applicability must justify every inclusion and exclusion. Individual controls are not automatically required, and the note to the 3.26 definition says you may need fewer or more. Whether any organization is obliged to adopt ISO/IEC 42001 itself is a separate matter, taken up in what ISO 42001 solves for US organizations.
Is there an ISO 42001 controls list in Excel?
ISO sells ISO/IEC 42001 as a PDF or paper document, and its iso.org page lists no spreadsheet edition. The standard’s copyright notice bars reproducing its text without permission, which is why the register on this page carries only IDs, short titles and GAICC’s own paraphrase. Those columns can be copied into a spreadsheet as the starting point for your Statement of Applicability.
Can you fail a certification audit over an Annex A control?
Yes, if an included control does not operate or an exclusion has no traceable reason. Either gap gives the auditor grounds for a nonconformity under 6.1.3, or under 8.3, which requires the treatment plan to be carried out and verified. Stage 2 is where such gaps show, because the auditor samples records to see whether the selected controls operate.
Does every Annex A control need its own procedure?
Not necessarily. One document can serve several controls: a single AI policy usually covers both A.2.2 and clause 5.2, even though some controls, such as A.5.3 on impact assessment results, ask for specific records. The list of documents the standard requires is set out in the ISO 42001 documentation guide.
How often should the Annex A selection be reviewed?
Review the selection whenever the risk assessment reruns, which clause 8.2 requires at planned intervals and on significant change. Clause 8.3 then sends any new risk back through the 6.1.3 treatment process. Typical triggers are a new AI system, a change of role or a new supplier model, and each SoA version stays under document control.
