ISO 42001 Mandatory Documents: The Complete List Every AIMS Implementer Needs

If you've started an ISO/IEC 42001 implementation, you've probably encountered a question that stops most teams cold: what documents do we actually have to produce?

The standard doesn't hand you a tidy checklist. Across ten clauses and a substantial Annex A of controls, ISO 42001 scatters its documentation requirements in ways that aren't always obvious on a first read. Miss a mandatory document and your auditor will flag a nonconformity. Create everything but get the format or management process wrong, and you'll face the same result. This 5,200-word guide covers every document, what each must contain, and how to build them in the right sequence.

The short answer: ISO/IEC 42001 requires 19 mandatory documents in total — 14 at the clause level and up to 5 from Annex A controls, depending on your organisation's scope. This guide maps all 19 clause by clause, then by Annex A control, and explains what each one needs to contain, why auditors look for it, and how to avoid the common traps that sink otherwise solid implementations. If you're new to the standard, start with our ISO 42001 certification guide before coming back here.

Why ISO 42001 Documentation Isn't Just a Filing Exercise

Before diving into the list, it helps to understand what ISO 42001 actually expects from documented information.

The standard is clear: documentation exists to guide the operation of your AI management system (AIMS), serve as evidence of conformity, demonstrate process effectiveness, and identify improvement opportunities. Documentation should add value to the AIMS rather than be an end goal in itself.

Auditors aren't counting pages. They're evaluating three things about every document they examine:

A document that exists but fails on format or governance is still a nonconformity. Build author, date, version, and approval fields into every template before you write your first document.

ISO 42001 also separates two types of required documentation. Some documents must be maintained — policies, procedures, plans you keep current and update over time. Others must be retained — records that capture point-in-time evidence of something that happened. The tables below mark which type each requirement demands.

The Complete ISO 42001 Mandatory Documents List

Section 1: Clause-by-Clause Requirements (14 Documents)

Each of these is non-negotiable. An auditor examining your AIMS will look for all fourteen before reaching any controls-level review. The absence of any single one is typically classified as a major nonconformity — your certification audit cannot conclude successfully until it is resolved.

Section 2: Annex A Control Documentation Requirements (5 Documents)

ISO 42001's Annex A contains the controls your organisation selects through the risk treatment process. Several controls carry their own explicit documentation requirements. These are not optional if the control is applicable.

These five documents are distinct from the Statement of Applicability. Producing an SoA that marks A.4.2 as "applicable" without actually maintaining a resource document is a nonconformity — auditors will ask to see the underlying document, not just the SoA entry. For a deeper look at how these controls fit into the broader control framework, see our ISO 42001 controls guide.

What Each Document Must Actually Contain

Understanding the list is one thing. Understanding what goes inside each document is where most implementations run into trouble. The following breaks down the critical content requirements for the documents where teams most commonly go wrong.

1. AIMS Scope (Clause 4.3)

The scope document establishes which AI systems, activities, and organisational boundaries fall within your management system. It must reflect your internal and external context (Clause 4.1) and the requirements of interested parties (Clause 4.2). For a detailed treatment of scoping alone, see our guide on defining your ISO 42001 scope.

2. AI Risk Assessment (Clause 6.1.2)

This is the engine of your AIMS. The risk assessment must capture the process and the results — not just the methodology. ISO 42001 Annex C outlines AI-specific risk sources that go beyond conventional information security: fairness, transparency, explainability, privacy, safety, and accountability.

3. Statement of Applicability (Clause 6.1.3)

The SoA is the most scrutinised document in any AIMS audit. It must list every control — Annex A and any additional controls — with justification for both inclusion and exclusion. Exclusions need documented reasoning, not just a checkbox.

Several organisations integrate the SoA with their master document list into a single reference — practical for smaller organisations where maintaining multiple documents creates unnecessary overhead.

4. Documented Information Management Procedure (Clause 7.5)

This procedure governs the lifecycle of every other document on this list. Without it, your documentation set has no governance backbone. A practical tip: assign dates in YYYY-MM-DD format across all documents — it makes version management and audit preparation significantly easier.

The Five Annex A Controls That Require Their Own Documents

A.4.2 — Resource Documentation

Beyond the general operational records required under Clause 8.1, this control requires documenting resources needed for AI activities at each lifecycle stage specifically — mapping data, compute infrastructure, personnel expertise, and tools to the stages where they're needed.

A.5.3 — AI System Impact Assessment Documentation

Where your organisation determines that an impact assessment is required, the results must be documented and retained for a defined period — one your organisation sets in its documented information management procedure. Impact assessments examine effects on individuals, groups, and society. Documentation should capture the scope, methodology, findings, and any design or deployment decisions the assessment produced.

A.6.2.3 — AI System Design and Development Documentation

This control requires documentation of design and development decisions — the rationale behind how an AI system was built, not just what it does. For organisations developing AI in-house, this is often the most technically demanding documentation requirement. For organisations using third-party AI, the equivalent documentation may come from suppliers, making A.6.2.7 the primary control.

A.6.2.7 — AI System Technical Documentation

The organisation must determine what technical documentation is needed for each audience category and provide it in appropriate form. Regulatory authorities need model-level detail. End users need accessible explanations of what the system does and doesn't do. Partners need integration specifications. One document trying to serve all audiences typically serves none of them properly.

A.8.2 — System Documentation and Information for Users

Users must receive sufficient information to use AI systems appropriately. In regulated sectors — financial services, healthcare, public sector — this user-facing documentation often intersects directly with legal disclosure requirements.

The Auditor's Examination Order

Understanding how auditors sequence their document review helps prioritise where implementation effort goes. Knowing this before you build your documentation set changes how you invest time.

When validating any document, auditors apply four criteria: complete (all expected content is present), correct (conforms to the standard and other reliable sources), consistent (internally coherent and aligned with related documents), and current (up to date).

Maintained vs. Retained: Getting the Distinction Right

Maintained documented information refers to living documents — policies, procedures, plans — that the organisation keeps current and updates when circumstances change. These need a formal change control process, version numbering, and documented approval on each revision.

Retained documented information refers to records — evidence that something happened. Records capture a point-in-time state and are not revised after the fact. They require a retention schedule specifying how long they're kept and what happens when the period ends.

Getting this wrong creates real problems. Treating records as living documents and revising them after the fact raises questions about evidence integrity. Treating policies like records and not updating them when the organisation changes creates scope and accuracy gaps that auditors flag.

Common Documentation Gaps Auditors Consistently Find

These gaps appear repeatedly across ISO 42001 audits. Knowing them before you build is more useful than discovering them during audit preparation. In my experience working with organisations across MEA on ISO 42001 implementation, the SoA exclusion gap and the procedure-versus-practice gap are by far the two most frequent reasons a first-attempt audit stalls. Both are completely preventable with the right build sequence.

A Practical Build Order for Your Documentation Set

Building the documentation set in the right sequence reduces rework significantly. The most common sequencing mistake is jumping to Phase 3 (Annex A documentation) without a completed, approved SoA from Phase 2 — you don't yet know which controls are applicable and which aren't.

Conclusion

ISO 42001 requires nineteen documents across its clauses and Annex A. But the standard is clear on one point: documentation is a means, not an end. The purpose of every document on this list is to make your AIMS work better, evidence that it does, and give you a foundation for improving it over time.

The implementations that survive audit aren't the ones with the most documentation. They're the ones where the documentation is coherent — where scope reflects actual AI operations, the risk assessment drives the SoA rather than the reverse, procedures match what people actually do, and records show a system in motion.

Related ISO 42001 Reading

Frequently Asked Questions