ISO 42001 Annex A Controls Explained: 38 Controls with Implementation Examples

ISO 42001 Annex A controls are the 38 reference controls in the AI management system standard, from the AI policy through to customers. Each one below has a plain example you can adapt. The Statement of Applicability then records whether a control applies, why, and who owns it. This is not a certificate, and it is not legal advice.

How ISO 42001 Annex A controls are grouped

Count ISO 42001 Annex A controls before you argue about wording. There are 38, identifiers fixed from A.2.2 to A.10.4. You assess every control. You may exclude some ISO 42001 Annex A controls with a reason. A reason is a sentence a stranger can test. “Not our culture” is not a reason. “This product does not report to an external authority, and no contract asks us to” can be a reason, until the contract changes.

Use this ISO 42001 controls list as a completeness check, not as a slogan page. Print the ISO 42001 controls list only if you will write an owner beside each identifier. The ISO 42001 controls list does not include secret extra controls. If a blog adds A.11, ignore it. Tick the ISO 42001 controls list during the gap review, before anyone designs a portal. The ISO 42001 controls list in this article is the identifier order of ISO 42001 Annex A controls, with one example each.

The groups follow the annex. Policy and roles first. Then resources. Then impact. Then the life cycle of a system you build. Then data. Then what you tell users and outsiders. Then how people use the system. Then suppliers and customers. Clause 6 of the AIMS still holds risk and objectives. Annex A is the reference for controls. An AI risk assessment lives in the register. An AI impact assessment lives with the system. They cite these controls. They are not a substitute for the rows below.

The ISO 42001 controls list, grouped the way Annex A is built

Read each example as a picture from a product firm, not as text to paste over your logo. If the sentence does not fit, write a better one. Do not leave the cell blank.

Policy, roles and resources

The first block of ISO 42001 Annex A controls covers policy, alignment and review. Roles and resources are ISO 42001 Annex A controls with names and assets, not posters. A policy nobody can find, or a model with no owner, fails here before you ever reach testing.

A.2.2 AI policy. Leadership signs a short AI policy that names which products are in scope and which role may approve a new model for production.

A.2.3 Alignment with other organizational policies. The AI policy points to the information security policy and the privacy notice instead of inventing a second rule for the same customer data.

A.2.4 Review of the AI policy. The policy owner reviews it every year and also when a product adds a model that can refuse a job, a loan or a claim.

A.3.2 AI roles and responsibilities. Each in-scope system has a named business owner and a named technical owner on the inventory, not a shared mailbox called ai-team.

A.3.3 Reporting of concerns. Staff get a channel outside the sprint board to report a biased output or a suspected misuse, and the log shows who closed it.

A.4.2 Resource documentation. The inventory lists the model, the data it learned from, the vendor tool and the people allowed to change the prompt or the weights.

A.4.3 Data resources. The hiring-screen row names the resume corpus and the historical hire labels, with a retention date beside each set.

A.4.4 Tooling resources. The sheet names the evaluation notebook, the feature store and the third-party moderation API, with a contract owner next to each.

A.4.5 System and computing resources. Production region, tenancy and the fallback path are written down so an auditor can see where the model actually runs.

A.4.6 Human resources. The firm lists the reviewers who may override the model and the competence note that shows they were shown how.

A bought chatbot is still in this block. A subscription is not an exit. You still have data going in, a vendor, a region and a human who can switch it off.

Impact and the life cycle

Impact items are the ISO 42001 Annex A controls that stop you writing low with no person attached. Life-cycle items are where ISO 42001 Annex A controls meet design, test, deploy and logs. This is the long stretch, and it is where a file named Final_v7 usually hides an old test result.

A.5.2 AI system impact assessment process. A short procedure says an impact assessment is required before deployment and again when intended use changes.

A.5.3 Documentation of AI system impact assessments. Each assessment is a record with a date, a version and an owner, not a paragraph buried in a sales deck.

A.5.4 Assessing AI system impact on individuals or groups of individuals. For a hiring screen, the record names candidates as the people affected and career-break applicants as a group.

A.5.5 Assessing societal impacts of AI systems. A credit model used at scale notes the effect on access to finance in a district, beyond one applicant.

A.6.1.2 Objectives for responsible development of AI system. The build team sets an objective such as no release if the agreed fairness check on a protected group fails.

A.6.1.3 Processes for responsible AI system design and development. Design review includes a misuse prompt, a data-source check and a sign-off before code moves to staging.

A.6.2.2 AI system requirements and specification. The specification states the intended user, the decision the model may recommend and the decisions it must not take.

A.6.2.3 Documentation of AI system design and development. The design note records model type, features, known limits and why a simpler rules engine was rejected.

A.6.2.4 AI system verification and validation. A held-out test and a business check both finish before release, and the results sit in the evidence folder with a date.

A.6.2.5 AI system deployment. Go-live needs a change ticket, a rollback step and a check that the impact record is still true for this version.

A.6.2.6 AI system operation and monitoring. The weekly view tracks drift, override rate and complaints, and a named person looks at it.

A.6.2.7 AI system technical documentation. A note in plain language explains inputs, outputs and limits so a customer-success lead can repeat it without inventing detail.

A.6.2.8 AI system recording of event logs. The system keeps decision or prompt logs long enough to investigate an incident, with access limited to a named role.

If you buy the system, several life-cycle rows move to the supplier. They do not vanish. The SoA should say who holds the test evidence. Annex III duties under the EU AI Act have applied since 2 August 2026. These records help a buyer. They are not a presumption of conformity.

Data, users and third parties

Data items among ISO 42001 Annex A controls need a source, a quality check and a purpose. Information items in ISO 42001 Annex A controls tell users and outsiders what happened. Use and third-party items finish ISO 42001 Annex A controls: intended use, suppliers, customers. Together they stop the firm treating a vendor login as a governance program.

A.7.2 Data for development and enhancement of AI system. Training data and later fine-tune data are listed apart from live prompts, each with a purpose.

A.7.3 Acquisition of data. The row says whether data was bought, licensed, generated or taken from customers, and which contract allows that use.

A.7.4 Quality of data for AI systems. A check flags missing labels, duplicated resumes and outdated bands before they enter training.

A.7.5 Data provenance. Each set has a source, a collection date and a pointer to the license or consent note that justifies keeping it.

A.7.6 Data preparation. Cleaning steps, including what was dropped and why, are written so a later reviewer can follow the logic.

A.8.2 System documentation and information for users. The product page states what the model does, what it refuses, and how a human can challenge an output.

A.8.3 External reporting. Where a contract or a regulator requires an AI incident report, the owner knows the clock and where the template sits.

A.8.4 Communication of incidents. A severity scale says which failures go to affected users, which go to the board and which stay on the internal log.

A.8.5 Information for interested parties. Customers or works councils get the facts they need on purpose and oversight, without a dump of model weights.

A.9.2 Processes for responsible use of AI systems. The user team has a procedure for staying inside intended use, including what to do when someone pastes a client file into a public chatbot.

A.9.3 Objectives for responsible use of AI system. One objective is that staff do not send customer contracts to an unapproved tool, checked by a quarterly sample.

A.9.4 Intended use of the AI system. The inventory states intended use in one sentence, and a prohibited-use line sits under it.

A.10.2 Allocating responsibilities. The vendor contract says who monitors drift, who reports an incident and who owns the impact record.

A.10.3 Suppliers. Each AI supplier is reviewed for data use, sub-processors and access to logs before the purchase order is signed.

A.10.4 Customers. Where you are the supplier, the schedule states the customer’s duties, such as lawful training data and use only for the agreed purpose.

Personal data in those rows meets the DPDP Act on a known clock. As of 31 October 2026, rules in force cover definitions and the Data Protection Board. Main fiduciary duties commence on 13 May 2027. Your data rows should already name purpose and source. ISO 27001 access control still matters here. It does not describe provenance.

What to write in the Statement of Applicability

The Statement of Applicability is the table that says which ISO 42001 Annex A controls apply. A Statement of Applicability line needs a justification even when the answer is no. Write the Statement of Applicability so a Stage 1 auditor can pick one row and ask for evidence. Update the Statement of Applicability when a system enters or leaves scope. This sketch shows how a Statement of Applicability row is filled.

An empty Statement of Applicability is the blank column leadership notices too late. Owners named against ISO 42001 Annex A controls should be people who can produce the record. Blank justification cells on ISO 42001 Annex A controls are a documentation finding waiting for Stage 1. File the Statement of Applicability with the risk register so the two dates stay in step. If the register was updated in March and the SoA still describes last year’s chatbot, the sample fails even when every control “exists” somewhere in a drive.

Applicable means you operate it. Not applicable needs a reason tied to scope. A control owner is a person who can show the record, not a department name. Copy-paste justifications across the rows are obvious in the first ten minutes of Stage 1.

How a Stage 2 sample uses ISO 42001 Annex A controls

Give the internal auditor the ISO 42001 controls list and a sample of five rows, not all 38 on day one. The certification body will do something similar. Picture a Tuesday sample of the support copilot: owner, intended use, last test date, impact note and the SoA line. The story has to match production. A surveillance audit later asks whether those five rows are still true after a model change. Bring the same owner who signed the row.

When a new system arrives, walk the ISO 42001 controls list again for that system. Do not renumber the ISO 42001 controls list to match an old ISO 27001 spreadsheet. The identifiers are the standard’s. Your cross-reference can sit in an extra column. Close the project by reading the ISO 42001 controls list aloud in the working group once. Awkward, and it catches blanks. The row everyone skips is usually A.5.5 or A.8.4, because society and incident messages feel softer than a test report. They are still rows.

Check the body on the NABCB or IAF directory before you treat a logo as proof it is accredited for this scope. Seven Step does not issue the certificate. A certification body does, after Stage 1 on the documents and Stage 2 on the operation. A surveillance audit comes after that. Software can hold the SoA. It will not decide the justification. A focused firm with a small inventory can be ready for Stage 1 in about 90 days if leadership shows up. That is readiness. It is not a certificate in 90 days. Full implementation is often three to six months, depending on how many systems are real.

Fill one system on the SoA

Get the SoA template and we will mark ISO 42001 Annex A controls for one real system with you. Bring the inventory, even if it is still a sheet. Start at https://www.sevenstepconsulting.com/contact-us/ or read the service path at https://www.sevenstepconsulting.com/iso-42001-aims-artificial-intelligence-management-system/.