Which documents does an ISO 42001 auditor expect? A checklist per clause

One of the first things a certification auditor does is review the documentation of your AI management system. During stage 1 of the certification audit this largely happens remotely: the auditor assesses whether the documented information is complete enough to make stage 2 worthwhile. Organizations starting with ISO/IEC 42001 therefore want to know early on which documents they need as a minimum. This article walks through what an auditor expects to find, chapter by chapter, based on our own audit practice and the guidance in the internal audit module of the Secure Audit platform.

How ISO 42001 handles documentation

The standard uses the term documented information for two things at once: documents you create and maintain (policy, procedures, methodologies) and records that serve as evidence that processes actually run (minutes, reports, logs, approvals). Clause 7.5 requires the AIMS to contain the documented information the standard itself prescribes, plus whatever the organization deems necessary for an effective management system. The standard does not prescribe a fixed format. A scope statement can be a page in the AIMS manual, a separate document or a record in a GRC tool.

That sounds permissive, but in practice the auditor assesses two things: is everything present that the standard requires, and does document control work (versions, approval, access, currency). Get both right and you are through most of the stage 1 audit.

Chapter 4: context and scope

For the context clauses, the auditor expects an AI-specific context analysis covering external factors (AI regulation such as the EU AI Act, societal expectations, the competitive field) and internal factors (AI maturity, available expertise, data infrastructure). A generic context analysis from the ISMS that says nothing about AI does not count. In addition: a stakeholder register with the requirements per interested party, including an overview of applicable AI legislation, and records showing that people subject to AI-driven decisions have been recognized as interested parties.

For clause 4.3 the scope statement is the core document, together with the AI system register. That register comes back in almost every phase of the audit: without a current overview of AI systems, including the organization's role per system (provider, producer or deployer), no other clause can be assessed properly.

Chapter 5: leadership and policy

This is about the AI policy, signed by top management, with evidence of communication: an intranet publication, training records or acknowledgments from staff. Also a RACI matrix or similar record of roles and responsibilities for AI governance, job descriptions for AI-related roles and, where one exists, the charter of an AI governance committee or ethics board. Board minutes that address AI governance show that top management involvement goes beyond a signature under the policy.

Chapter 6: risks, impact and objectives

This chapter carries the heaviest documentation load. The auditor expects an AI risk assessment methodology with criteria and acceptance thresholds, completed risk assessments for the in-scope AI systems, a risk treatment plan and records of accepted residual risks. On top of that, the Statement of Applicability, stating for each Annex A control whether it applies and why.

The same pattern applies to the AI system impact assessment (clause 6.1.4): a procedure with criteria and triggers, plus completed assessments per system. Keep in mind that the risk assessment and the impact assessment answer different questions; we wrote a separate article about that. Finally, a register of AI objectives with measurable indicators and a plan setting out who does what and when.

Chapter 7: resources, competence and document control

For competence (7.2) the auditor wants to see a competence matrix or skills framework for AI roles, a training plan and training records with certificates. For awareness (7.3), an awareness program and evidence of participation. For communication (7.4), a communication plan that also covers external communication on AI, including incident communication.

Clause 7.5 itself requires working document control: a register or master list of AIMS documentation, a procedure for creating and updating documents, and access control on the storage location. A gap analysis of required versus available documentation is not a requirement of the standard, but it is the most useful working document on the way to certification.

Chapter 8: operation

Chapter 8 demands operational evidence. Procedures for developing, deploying and changing AI systems, with records showing they are followed: deployment approvals, change records, monitoring reports. Repeated risk assessments and impact assessments belong here too: chapter 8 requires these to be performed again at planned intervals and after significant changes, so the auditor looks for a schedule and for recent reassessments. For outsourced processes: contracts and control records for the outsourced AI activities.

Chapter 9: monitoring, internal audit and management review

Three clusters. For monitoring (9.1): a measurement framework with KPIs for the AIMS and the AI systems, dashboards or reports, and records of drift detection and data quality checks. For the internal audit (9.2): an audit programme that covers all requirements of the standard within the cycle, audit reports with findings and evidence references, and records of auditor competence and independence. For the management review (9.3): agenda, input package, attendance records showing top management participation, and minutes with decisions and actions.

Chapter 10: improvement

A nonconformity register with, for each nonconformity, the root cause analysis, the corrective action and the effectiveness review afterwards. Plus an improvement log that also captures lessons from AI incidents. Auditors mainly look at follow-up here: a register full of open actions without deadlines does not inspire confidence.

Annex A: documentation according to your SoA

Which Annex A documentation you need follows from the Statement of Applicability. Common items: model cards and data sheets per AI system (A.6.2.7), documentation of intended use and limitations (A.9.4), data documentation with provenance, quality criteria and bias assessments (A.7), user documentation and information for interested parties (A.8), logging requirements and log retention (A.6.2.8), and supplier files with AI-specific contract clauses and due diligence assessments (A.10). Organizations that only procure and use AI have a lighter package here than organizations that develop models themselves.

Where it goes wrong

We see four recurring patterns. ISMS documents are reused with a find-and-replace from information security to AI, without any substantive AI analysis. There is no document register, so nobody knows what the current version is or what is missing. Procedures exist but records are missing: there is a beautiful impact assessment procedure and zero completed assessments. And documentation is drawn up once for the audit and never maintained afterwards, which becomes visible at the first surveillance audit.

Practical: start with a document register

Our approach in implementation projects: first set up a register listing, per clause and per applicable Annex A control, the required documents and records, the owner and the status. Fill that register from a gap analysis and close the gaps in order of dependency (context and scope first, then risk and policy, then the operational documentation). The internal audit module of the Secure Audit platform contains the expected documents, criteria and interview questions for each ISO 42001 element, so you can check per clause whether your file is audit-ready. Contact us for a no-obligation conversation.