ISO/IEC 42001 Annex A Implementation Guide
Annex A of ISO/IEC 42001 sorts its reference controls into nine areas, A.2 to A.10. For each one, this guide explains what it is about in plain words, what a well-run implementation looks like, the evidence an auditor typically samples, the findings auditors commonly raise, and the PlayCISO tools that help you get there. Search it, filter it, then decide which controls apply in your Statement of Applicability.
Area-level guidance in our own words, not the text of the standard. Check exact control wording in your copy of ISO/IEC 42001. Not certification advice.
A.2 Policies related to AI
What it is about: Top management sets direction for how the organisation develops, provides or uses AI, writes it down in an AI policy, makes sure it does not contradict the security, privacy, quality or procurement policies already in place, and reviews it when things change.
What good looks like
- One AI policy, approved by top management, that states why the organisation uses AI, the principles it holds itself to and who is accountable.
- The policy cross-references the information security, privacy, data, procurement and acceptable-use policies, and none of them contradict it.
- Staff, contractors and relevant suppliers can find the policy and know what it asks of them.
- A review date and a review trigger list (new regulation, new kind of AI system, significant incident) are written down, and the last review is recorded.
Evidence auditors sample
- The approved AI policy with version, approver and approval date.
- Minutes or a decision record showing top management approved it.
- How it was communicated: intranet page, training module, acknowledgement records.
- The record of the most recent review and what changed.
- A mapping or note showing alignment with other organisational policies.
Common findings
- The AI policy exists but was never formally approved, or the approver is not top management.
- The policy is generic and does not reflect the AI systems actually in scope.
- The privacy or procurement policy says something different about AI use, and nobody noticed.
- No evidence of review since first issue, even after a significant change such as adopting generative AI.
- Staff interviewed cannot say where the policy is or what it means for their work.
A.3 Internal organization
What it is about: People need to know who owns each AI system, who approves it, who manages its risks and who answers when something goes wrong. The organisation also gives staff and others a way to report concerns about AI systems without fear.
What good looks like
- Named owners for each in-scope AI system, with their authority written down (approve, pause, retire).
- A RACI or equivalent that covers model owners, data owners, risk, security, privacy, legal and the approval body.
- A reporting channel that explicitly covers AI concerns (bias, misuse, unsafe output), with a defined triage route.
- Separation between those who build a system and those who approve it for release, where the risk calls for it.
Evidence auditors sample
- Role descriptions or a RACI covering AI responsibilities.
- Appointment letters, committee terms of reference or org charts naming AI owners.
- The concern-reporting procedure and a sample of reports and how they were handled (anonymised).
- Interviews with system owners who can describe their responsibilities.
Common findings
- Roles are defined on paper, but nobody is named for one or more in-scope systems.
- The governance committee exists but has no record of decisions on AI systems.
- The whistleblowing or speak-up channel does not mention AI, and staff do not think to use it for AI concerns.
- The person who built the model also signs off its release, with no independent check, for a high-impact system.
A.4 Resources for AI systems
What it is about: Each AI system depends on resources: the data it learns from or works on, the tooling and libraries used to build it, the compute and hosting it runs on, and the people who build, run and oversee it. The organisation identifies and records these so it can manage risks and plan for change.
What good looks like
- An AI system inventory where each entry lists its data sources, models, key tooling, hosting and owners.
- Competence requirements set for the people who design, operate and oversee AI systems, with records of how they are met.
- Dependencies on external models, APIs and datasets are visible, not buried in project notes.
- Resource records are updated when a system changes, for example a model or hosting swap.
Evidence auditors sample
- The AI system inventory or register with resource fields completed.
- An AI bill of materials or equivalent for a sampled system.
- Competence requirements per role and training or qualification records.
- Capacity or hosting records for a sampled production system.
Common findings
- The inventory is missing systems that staff mention in interviews (shadow AI, vendor features switched on).
- Resource records were written at project start and never updated after the model or provider changed.
- No defined competence requirements for people overseeing AI output, only for developers.
- Third-party model or dataset dependencies are not recorded at all.
A.5 Assessing impacts of AI systems
What it is about: Separate from the organisational risk assessment, the organisation assesses the possible consequences of an AI system for the people and groups it touches and for society, across its life cycle, and keeps the results. ISO/IEC 42005 gives detailed guidance on how to do this.
What good looks like
- A documented impact assessment method with clear triggers: new system, significant change, new use or new population.
- A completed, dated assessment for every in-scope system, with the assessor and the decision recorded.
- Consideration of individuals and groups (including vulnerable groups) and wider societal effects, not only the organisation's own risk.
- Results feed the risk treatment, the design and the information given to users.
Evidence auditors sample
- The impact assessment procedure.
- Completed impact assessments for sampled systems, with approval records.
- Evidence that an assessment was revisited after a change to the system or its use.
- Links from assessment outcomes to risk treatment actions or design changes.
Common findings
- Impact assessments exist for some systems but not all in scope, often missing for bought-in AI features.
- The assessment only looks at risk to the organisation, not at individuals or society.
- A system changed materially (new data, new users) and the assessment was not updated.
- Outcomes are recorded but nothing shows they changed any decision.
A.6 AI system life cycle
What it is about: The organisation defines how AI systems are designed and developed responsibly, then manages each stage: requirements, design records, verification and validation, deployment, operation and monitoring, technical documentation and event logging. This is usually the largest area in an audit.
What good looks like
- A documented AI life cycle with gates, each with entry and exit criteria and a named approver.
- Requirements and intended use written down before build, including performance, robustness and fairness criteria.
- Verification and validation results kept, including security and adversarial testing proportionate to the risk.
- Deployment goes through change management, with a rollback plan.
- Production monitoring for performance, drift, misuse and incidents, with thresholds that trigger action.
- Technical documentation and event logs kept for each system to the level its risk needs.
Evidence auditors sample
- The life cycle procedure and gate criteria.
- For a sampled system: requirements, design decisions, test reports, release approval and change tickets.
- Monitoring dashboards or reports, and records of alerts that were acted on.
- Technical documentation such as model cards or system cards.
- Event log samples and the retention setting.
Common findings
- Gates are defined, but a sampled release skipped one with no recorded exception.
- Acceptance criteria were set after testing, or not at all.
- No adversarial or security testing for a system exposed to untrusted input.
- Monitoring exists for one flagship model only; other production systems are unmonitored.
- Prompt or configuration changes to a generative AI system happen outside change control.
- Technical documentation describes an earlier version of the system.
A.7 Data for AI systems
What it is about: Data shapes how an AI system behaves. The organisation manages the data used to develop and improve AI systems: how it is acquired and on what rights, how its quality is defined and checked, where it came from, and how it is prepared, so results can be explained and reproduced.
What good looks like
- A data management process for AI that covers acquisition, quality, provenance and preparation.
- For each training or fine-tuning dataset: source, licence or legal basis, date acquired and owner recorded.
- Data quality requirements defined per system (completeness, representativeness, labelling accuracy) and checked before use.
- Preparation steps (cleaning, labelling, splitting, augmentation) documented well enough to reproduce.
- Dataset documentation, such as a dataset card, kept alongside the model it fed.
Evidence auditors sample
- The data management procedure for AI.
- Dataset records or dataset cards for a sampled system.
- Licences, contracts or legal-basis records for third-party or personal data.
- Data quality check results and any exceptions approved.
- Preparation scripts or pipeline records.
Common findings
- Provenance and licence are unknown for a third-party or scraped dataset.
- Quality requirements are not defined, so nothing shows the data was fit for purpose.
- Preparation was done by hand in a notebook that no longer exists, so the training set cannot be reproduced.
- Personal data used for training without a recorded legal basis or privacy review.
A.8 Information for interested parties
What it is about: People who use, are affected by, or oversee an AI system need enough information to use it properly and understand its limits. The organisation decides what to tell users and other interested parties, meets its external reporting obligations, and has a way to communicate AI incidents.
What good looks like
- Users get documentation covering intended use, known limitations and how to get help or contest an outcome.
- People are told when they are interacting with an AI system where that matters, or where law requires it.
- External reporting obligations (regulators, customers, contracts) are identified, with owners and deadlines.
- An incident communication process says who is told what, by whom and how fast when an AI system causes harm.
Evidence auditors sample
- User-facing documentation, notices or help content for a sampled system.
- A register of external reporting obligations.
- The incident communication procedure and any records of its use.
- Records of information requests from interested parties and the responses.
Common findings
- User documentation does not mention known limitations or failure modes.
- No list of external reporting obligations, so the organisation could not say what it must report and to whom.
- The general incident process does not mention AI incidents or affected individuals.
- Customer contracts promise information about AI use that nobody is providing.
A.9 Use of AI systems
What it is about: When the organisation uses AI systems, whether built in-house or bought, it defines what responsible use means, sets objectives for it, and makes sure each system is used only for the purpose it was designed and assessed for, with human oversight where it is needed.
What good looks like
- A documented process for responsible use, covering approval of new uses and human oversight.
- Objectives for responsible use that can be measured, such as override rates or complaint volumes.
- An intended-use statement for each system, and checks that actual use stays within it.
- Guardrails for staff use of generative AI tools: what data may go in, which tools are approved.
Evidence auditors sample
- The responsible-use process and acceptable-use rules for AI.
- Intended-use statements and the approval for any extension of use.
- Human oversight records, such as review samples, overrides and escalations.
- Monitoring of actual use against intended use.
Common findings
- A system approved for one purpose is now used for another, with no new assessment.
- Human oversight is described in the procedure, but the reviewers approve everything without checking.
- Staff use unapproved generative AI tools with customer data, and nothing detects it.
- Responsible-use objectives exist but are not measured.
A.10 Third-party and customer relationships
What it is about: Most AI systems involve other parties: model providers, data suppliers, cloud platforms and the customers who use what you build. The organisation allocates responsibilities across that chain, manages its AI suppliers, and considers its customers' needs and obligations.
What good looks like
- A documented split of responsibilities between you, each AI supplier and your customers.
- AI suppliers assessed before onboarding with AI-specific questions: training data, model changes, security testing, incident notice.
- Contracts that cover model or version changes, data use, incident notification and audit rights.
- Customer-facing commitments about AI use recorded and met.
Evidence auditors sample
- A supplier register flagging AI suppliers, with assessment records.
- Contracts or data processing terms for a sampled AI supplier.
- A shared-responsibility matrix or equivalent.
- Customer agreements or documentation describing AI-related obligations.
Common findings
- A model provider changed the underlying model with no notice, and the contract does not require it.
- Supplier assessments use a generic security questionnaire with nothing on AI.
- Responsibilities for monitoring or incident response fall between you and the supplier, and nobody owns them.
- Model licence terms restrict the commercial use the organisation is making.
Area-level guidance in our own words. It does not list individual controls or quote the standard: check the exact wording in your copy of ISO/IEC 42001.
TL;DRKey facts about Annex A
5 points
- ISO/IEC 42001 Annex A groups its reference controls into nine areas, A.2 to A.10: policies, internal organisation, resources, impact assessment, AI system life cycle, data, information for interested parties, use of AI systems, and third-party and customer relationships.
- For each area this guide says what it is about, what good looks like, the evidence an auditor typically samples, the findings auditors commonly raise, and the PlayCISO tools that help.
- You decide which Annex A controls apply, and justify any you exclude, in your Statement of Applicability.
- The guide stays at area level and is written in our own words. Check the exact control wording in your copy of the standard.
- Reading, searching and filtering are free. Copy as checklist and Markdown export are part of Pro.
How to use Annex A in an implementation project
Annex A is not a checklist you work through from top to bottom. The management system clauses come first: set the scope and context (clause 4), leadership and the AI policy (clause 5), then assess AI risks and decide how to treat them (clause 6). Annex A is what you compare your chosen treatments against, so nothing obvious is missed. The result is the Statement of Applicability: each control included or excluded, with a reason.
Most teams organise the work by area and give each one an owner. Start where the evidence is thinnest. For organisations that buy AI rather than build it, that is usually supplier management (A.10), impact assessment (A.5) and responsible use (A.9). For model builders it is usually the life cycle (A.6) and data (A.7).
When the controls are running, check them in an internal audit and take the results to management review before your certification audit. The certification countdown plans those steps back from your target date.
Frequently asked questions
What is ISO/IEC 42001 Annex A?
Annex A of ISO/IEC 42001 is a reference set of control objectives and controls for an AI management system. It is grouped into nine areas, A.2 to A.10: policies related to AI, internal organization, resources for AI systems, assessing impacts of AI systems, AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships. Annex B gives implementation guidance for the same controls.
Do I have to implement every Annex A control?
No. You determine the controls you need from your AI risk assessment and risk treatment, compare them with Annex A, and record in a Statement of Applicability which controls you include, whether they are implemented, and why any are excluded. An auditor will expect a sound justification for each exclusion. The PlayCISO SoA builder walks through each area.
Which Annex A area do auditors spend most time on?
It depends on what you build or use, but the AI system life cycle area is usually the largest: auditors sample a system and follow it from requirements through testing, release approval, monitoring and documentation. Impact assessment, data provenance and supplier management are also frequent sources of findings, especially for organisations that buy rather than build their AI.
What evidence should I prepare for an Annex A audit?
Expect the auditor to sample records, not just procedures: an approved AI policy and its last review, named owners for each system, completed impact assessments, test and release records for a sampled system, dataset provenance and licences, user documentation, supplier assessments and contracts. Each area in this guide lists the evidence typically sampled.
Why does this guide not list the individual controls?
ISO/IEC 42001 is a copyrighted standard, and paraphrasing control by control with numbers invites errors. The guide works at area level, which is how most implementation projects are organised, and tells you to check the exact wording in your licensed copy. Buy the standard from ISO or your national standards body.
Is this guide free?
Yes, reading, searching and filtering the whole guide is free. Copying the areas you filtered as a tick-box checklist, and downloading the guide as Markdown, are part of Pro ($5/month or $40/year).
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.