Preparing Checklists From Clauses 4 to 10 and Annex A

An audit checklist is a working tool. It helps auditors stay systematic, remember every question they need to ask, and track evidence as they gather it. A checklist is not a tick-box substitute for thinking; it is thinking that has been organised in advance. Checklists make audits repeatable and fair across auditors.

A good checklist maps to the standard explicitly. Clauses 4 to 10 of ISO/IEC 42001 structure the standard, and Annex A lists controls specific to AI systems. Your checklist should follow this structure. Clause 4 checklist items might ask: Has the organisation identified interested parties and their relevant requirements? Has context been assessed? Is scope clearly documented? Clause 5 items might ask: Is there a top-level AI policy? Have roles and responsibilities been assigned? Is there an AI governance committee with a defined charter? A structured checklist ensures no clause is forgotten.

Checklists should use open-ended questions, not yes/no boxes. An open-ended question forces the auditor to think and document reasoning. “Is there an AI policy?” allows a yes/no tick. “Describe the AI policy and explain how it addresses AI risk across the organisation” requires the auditor to understand what they are examining. The answer reveals whether the policy is real or rhetorical. Open-ended questions produce better audit evidence.

For each control area, your checklist should identify the evidence to be gathered. Evidence might be documents: the policy itself, approved AI system inventory, model cards, data governance procedures. Evidence might be interviews: ask data scientists how they are trained, ask system owners how they monitor performance, ask team leads how they approve changes. Evidence might be records: logs of system access, approval workflows, incident reports. A good checklist lists what kinds of evidence exist for each control and where to find them so auditors know what to look for.

Your checklist should also note the risk context. If a clause addresses high-risk systems, the checklist should be more detailed. If a clause is less relevant to your organisation, the checklist can be more concise. This prevents effort from being wasted on low-risk areas. A checklist that treats all controls as equally important wastes audit time.

Checklists should include cross-reference fields. If Clause 6 (risk assessment) connects to Annex A.5 (AI system risk assessment), note that connection. If Clause 9 (monitoring) connects to EU AI Act Article 15 (accuracy and reliability targets if your organisation is subject to the Act), note that too. Cross-references prevent audit silos where one auditor checks Clause 6 without understanding what controls Clause 8 demands from the same systems. Good checklists show how clauses depend on each other.

Many organisations develop separate checklists for system-level audits and process-level audits. A system-level checklist focuses on a specific AI system: model documentation, data used, deployment controls, monitoring, incident response. A process-level checklist focuses on how the organisation governs AI: policy, roles, competence, governance meetings, change control. Both are necessary because they examine different things.

A checklist should be reviewed and updated annually, or more frequently if the standard is revised or your identified risks change. A checklist that has not been used in a year may become stale. Version your checklists so that you know which version was used in each audit, and whether findings from the last audit have been incorporated into the new checklist. Versioning checklists makes it possible to track how audit approach evolves.

Some organisations find it helpful to maintain a question library: a collection of all good audit questions that auditors have found effective over time. When you create a new checklist for a new audit area, you can draw from this library rather than starting from scratch. A question library also ensures consistency across auditors so that all auditors ask similar questions when auditing similar systems.

A final note on checklists: they are working documents for auditors, not documents to share with auditees. An auditee who sees the checklist in advance might prepare answers to check boxes rather than demonstrating genuine understanding. Keep checklists internal to the audit function and use them to guide your work, not to structure auditee responses.

Over time, develop separate checklists for different audit topics. A checklist for auditing a data governance procedure is different from a checklist for auditing a model deployment. A checklist for auditing policy and roles differs from a checklist for auditing monitoring. Specialised checklists are more effective than generic ones because they focus on the specific things that matter for each area. A rich library of well-developed checklists makes audits faster and more consistent.