ISO 42001 documentation: the documents and records an AI management system needs, and what it does not

What counts as documentation in ISO/IEC 42001?

The standard uses one term, documented information, for everything it expects you to control, whether it sits in a policy library, a ticketing tool or a model registry. Format does not matter; control does.

Two kinds of documented information behave differently. Documents describe how the AI management system is meant to work: the scope statement, the AI policy, the risk criteria, a procedure for approving a new model for release. They change when practice changes, and the superseded version is withdrawn. Records prove what actually happened: a completed impact assessment for a credit-scoring model, a validation report, an event log, internal audit findings. Records are not edited after the event; if a conclusion changes, a new assessment is recorded and the old one stays as history.

Teams that treat an impact assessment as a living document tend to overwrite last quarter's conclusions, removing the trail that shows reassessment happened.

Which documents and records does ISO/IEC 42001 require?

ISO/IEC 42001 follows the harmonised structure shared by ISO management system standards, so part of its documentation list will look familiar to anyone who runs ISO/IEC 27001 or ISO 9001. The AI-specific items sit mainly in clauses 4, 5, 6 and 8. The table works at the level of clause titles; the clauses themselves are covered in the requirements guide.

Certification bodies look early at two items. The Statement of Applicability must agree with the risk register, and the treatment plan carries a management approval whose owner and date the auditor will ask for.

Documentation that follows from your Annex A choices

The 38 reference controls in Annex A are not a documentation list, but several of them are about documentation by their nature. Once a control is marked applicable in your Statement of Applicability, the records it describes become evidence the auditor can ask for. Examples from the control titles:

• Resource documentation for each AI system: data, tooling, computing and human resources (A.4).
• Documentation of each AI system impact assessment (A.5).
• Design and development records, verification and validation results, technical documentation and event logs across the life cycle (A.6).
• Records of where data came from, how it was acquired, how its quality was checked and how it was prepared (A.7).
• System documentation and information for users, and records of incidents communicated (A.8).
• Agreed allocation of responsibilities with suppliers and customers (A.10).

This is where role matters. A company that develops models will carry most of the life-cycle and data records. A company that only uses AI systems supplied by others will often justify excluding some development controls and put its weight on intended use, supplier responsibilities and information for users. What the auditor tests is whether the justification in the Statement of Applicability is accurate, and whether the records for every applicable control exist. The Annex A guide explains each group; deciding which systems and roles fall inside the boundary belongs to the scope guide.

A minimal document set for a small AI team

For a small team with a handful of AI systems, the set below usually meets the clauses. Each line can be a short page or a configured register.

Much of this already exists in engineering tools. A validation report in the repository or a release approval in the ticketing system is an acceptable record if it is retrievable and protected from change; the AIMS points to it rather than copying it. See also the guide for start-ups and small AI teams.

What you do not need, and what to avoid

ISO/IEC 42001 requires no AIMS manual, no numbered set of procedures and no document mirroring each clause. Four habits create paperwork without adding assurance.

Copying a template pack

Generic AI policy templates describe systems you do not have and controls you do not run; the first interview with a system owner exposes the gap.

Procedures nobody follows

A twelve-step release procedure that engineers bypass is worse than a three-line rule they apply.

A register and a Statement of Applicability that disagree

If the risk register treats a bias risk with a control that the Statement of Applicability excludes, the auditor has found an inconsistency before reading anything else. Update both together.

Impact assessments written once

Clause 8 expects reassessment at planned intervals and on significant change. A folder of assessments all dated the week before Stage 1 tells the certification body that the process is not yet operating. The common mistakes guide covers the other patterns that lead to findings.

How Effivity holds AIMS documentation

Effivity, used in 50+ countries, is included with a Sterling engagement at no additional cost. For ISO/IEC 42001 it holds the controlled documents with versioning and approval, the risk register and treatment plan, objectives, competence records, the internal audit programme, corrective actions and management review, and a register configured for your AI system inventory. Engineering records are linked, not duplicated, giving the auditor one path from a risk to its control and evidence. The Effivity guide has the detail.

ISO/IEC 42001 documentation: questions buyers ask