The documented information certification auditors ask for — what each document must contain, and the order to build them in
The first wall most organizations hit when preparing for ISO/IEC 42001 certification is a simple question: "What documents do we actually have to produce?" The standard requires extensive documented information, but reading the clause text alone doesn't tell you what a working document set looks like. This article lists the ten documents a certification audit will examine, what each must contain, and where auditors tend to probe.
Two kinds of documentation — and why the second one decides audits
ISO/IEC 42001 expects two distinct types of documented information:
- Procedures — documents that define how the organization performs an activity.
- Records — evidence that the activity actually happened as the procedure describes.
An audit checks both. A beautifully written procedure with no execution records behind it is a nonconformity, not a head start. Keep that in mind for every document below: each one is only as strong as the records that sit underneath it. (For where the gaps typically surface, see the five nonconformities most likely to appear in your ISO 42001 audit.)
The ten documents
1. AI policy — Clause 5.2
The top-level document declaring the principles under which the organization develops and operates AI. It must be approved by top management and communicated across the organization.
- Purpose and scope of the AI management system
- Commitments to fairness, transparency, accountability, and safety
- Commitment to meeting applicable legal and regulatory requirements
- Commitment to continual improvement
- Management approval and issue date
Where auditors probe: whether the policy actually reached the workforce — intranet posting records, awareness-training evidence, and whether staff can describe it.
2. AIMS scope document — Clause 4.3
Defines which AI systems, organizational units, and processes fall inside the management system — and what is excluded, with justification.
- List of in-scope AI systems
- In-scope organizational units
- Exclusions and the reasoning behind them
- Internal and external context — interested parties, regulatory environment
Where auditors probe: a scope drawn so narrowly that the organization's real AI operation sits outside it. Whether externally sourced AI (SaaS features, model APIs) is inside the boundary gets particular attention.
3. AI risk assessment and treatment plan — Clauses 6.1.2 and 6.1.3
The document at the heart of the system: identify, analyze, and evaluate the risks of each AI system, and record how each will be treated. Clause 6.1.3 also requires a Statement of Applicability — the record of which Annex A controls apply and why any were excluded — so plan for the two documents together.
- Risk register per AI system
- Likelihood and impact evaluation for each risk
- Risk rating (e.g., critical / high / medium / low)
- Treatment strategy — avoid, mitigate, transfer, accept
- Mitigating controls with named owners
- Residual risk level and management sign-off
Where auditors probe: a register that covers only IT-security threats. If AI-intrinsic risks — bias, opacity, oversight failure — are absent, expect a finding. Our ISO/IEC 23894 overview covers the AI risk sources to draw from.
4. AI system impact assessment — Clauses 6.1.4 and 8.4
Where the risk assessment looks inward at the organization, the impact assessment looks outward: how does each AI system affect individuals, groups, and society?
- Description of the AI system under assessment
- Affected stakeholders
- Positive and negative impacts
- Specific consideration of vulnerable groups
- Mitigation measures and monitoring plan
Where auditors probe: systems that would classify as high-risk under the EU AI Act attract the closest review here. See our ISO/IEC 42005 overview for how to structure the assessment.
5. AI objectives and plans to achieve them — Clause 6.2
The concrete, measurable goals of the AI management system and how the organization intends to reach them.
- Measurable objectives (e.g., "maintain bias-detection coverage above 95%")
- Specific activities to achieve each objective
- Responsible function and owner
- Deadline and progress-measurement method
- Required resources
Where auditors probe: abstract objectives. "Improve AI safety" is not an objective; "retrain quarterly and hold the bias metric within ±5%" is.
6. Competence and training records — Clauses 7.2 and 7.3
Defines the competence requirements for people working under the AIMS, and evidences the training that fills the gaps.
- Competence requirements per AI-related role
- Gap-analysis results
- Training plan and completion records
- AI ethics and safety awareness training records
- External certificates and qualifications
Where auditors probe: whether awareness training actually happened — attendance lists, the training material itself, and evidence of comprehension.
7. Internal audit program and reports — Clause 9.2
The organization's own check that the AIMS conforms to ISO/IEC 42001 and to its own requirements.
- Audit program — frequency, scope, method, auditors
- Audit checklist
- Results — nonconformities, opportunities for improvement, conformities
- Corrective-action plans for findings
- Evidence of internal auditor competence
Where auditors probe: independence — an internal auditor auditing their own work is a finding — and whether audit results flow into management review.
8. Management review minutes — Clause 9.3
The record that top management periodically reviews the AIMS for continuing suitability, adequacy, and effectiveness.
- Status of actions from previous reviews
- Changes in internal and external AI issues
- Progress against AI objectives
- Internal audit results summary
- Risk and opportunity status
- Adequacy of resources
- Improvement decisions with owners
Where auditors probe: evidence that top management genuinely participated. A meeting attended only by middle managers may not qualify as management review.
9. Nonconformity and corrective-action log — Clause 10.2
Tracks every nonconformity found through internal audits, complaints, or monitoring — from root cause to verified closure.
- Date found and how it surfaced
- Description of the nonconformity
- Immediate correction taken
- Root-cause analysis
- Corrective-action plan and implementation status
- Effectiveness verification, completion date, owner
Where auditors probe: repeat findings of the same type — a strong signal that root-cause analysis is not really being done.
10. AI supplier management procedure and evaluation records — Annex A.10
How the organization manages the third parties that supply its AI services, models, and data — one of the requirements that most distinguishes ISO/IEC 42001 from earlier management systems.
- Inventory of AI suppliers — model APIs, AI SaaS, data providers
- Supplier selection criteria
- Method for evaluating each supplier's AI governance
- AI responsibility clauses in contracts
- Periodic evaluation records
Where auditors probe: organizations consuming external model APIs with no supplier records at all — a common and avoidable finding.
Which documents to build first
If you can't prepare everything at once, this sequence works with the dependencies rather than against them:
| Priority | Document | Why this position |
|---|---|---|
| 1 | AI policy · Scope document | Everything else depends on them — direction and boundary |
| 2 | Risk assessment · Impact assessment | The audit's center of gravity, and the most time-consuming |
| 3 | AI objectives · Competence and training records | Objectives follow the risk results; training records need time to accumulate |
| 4 | Supplier management records | After the external-AI inventory is known |
| 5 | Internal audit · Management review · Corrective-action log | The operating-evidence layer — aim to complete a full cycle about three months before the certification audit |
Three mistakes that undermine a good document set
- Documents in form only. A template with the company name swapped in is visible to an auditor within minutes — the content doesn't match how the organization actually works.
- No version control. Every document needs a version number, date, revision history, and approver. Without them, confidence in the whole documentation system drops.
- Procedure–record mismatch. If the procedure says "monitored monthly" and the records show three months of gaps, that is a nonconformity — not an oversight.
The bottom line
ISO/IEC 42001 certification is not about producing documents; it is about operating them. When these ten documents connect to each other — policy setting direction, risk and impact assessments feeding objectives, audits feeding management review, findings feeding corrective action — they demonstrate a management system that actually runs. Start with the AI policy and the scope document, and build outward from there rather than aiming for a perfect set on day one.
Not sure which of these documents your organization already has covered? Our free AI governance readiness assessment takes about 10 minutes, requires no document uploads, and shows where your preparation stands against ISO/IEC 42001.
Related
🔍 Where audits go wrong: the 5 nonconformities most likely to appear in your ISO 42001 audit.
🔧 Already hold ISO 27001? The control-by-control path: extending an ISO 27001 ISMS to ISO 42001.
📘 The standard itself: the ISO/IEC 42001 reference overview.
🗺 The whole portfolio: part of our SC 42 AI Standards Map — the international AI standards portfolio, explained.