The minimum documentation of an AIMS: what ISO/IEC 42001 actually requires

In the AI maturity assessments we run, the scene repeats itself almost identically: a shared folder full of PDFs, a policy written a year ago and never opened again, a few presentation slides passed off as a procedure. The company believes it already has the documentation for an AI management system. What it actually has is scattered fragments of one.

The starting misconception

The first misunderstanding about ISO/IEC 42001 concerns what an audit actually looks for: the volume of pages produced matters less than people assume, what an auditor checks is whether those documents are actually used to decide something. A risk register last updated before the project even launched is useless to anyone, least of all to someone asking to see the latest revision and its date.

Documentation, inside an AI Management System, works more as decision infrastructure than as proof of compliance: it lets an organization choose with solid grounds, and account for that choice when someone questions it later, why that model was picked, who assessed the risk, what happens if the system stops behaving as expected.

The documents the standard actually requires

Strip away the noise and the minimum core comes down to a handful of connected families, more than a flat list.

• AI policy and objectives, the starting point that fixes what the organization means by responsible AI use and against which measurable targets
• Roles and responsibilities, who owns each AI system, who answers for it, who approves exceptions
• Risk assessment and treatment, the procedure that classifies every system before it goes into production
• AI risk register, kept alive, not a document closed at project sign-off
• AI system inventory, an updated list of what the organization uses, builds, or buys, with its lifecycle status
• Operating procedures, how a live system is monitored, how an incident is handled, how a model gets updated
• Training plan, ground worth its own piece, since people's competence is itself an auditable requirement
• Management review records, proof that the system gets reviewed periodically by whoever has the authority to decide, not just maintained by whoever wrote it

Eight families of connected documents, not eighty scattered files in a shared drive.

The treatise nobody needs to write

Many companies start out convinced they need to produce a treatise, and stall before they begin. What's needed is a system sized to the actual scale and risk of the AI systems in use, not an encyclopedic manual built for a multinational running a hundred use cases in production when the real count is three.

Organizations that already run a certified management system, ISO 27001 for information security or ISO 9001 for quality, start ahead. The harmonized structure ISO/IEC 42001 shares with those standards lets a company reuse context analysis, document control, and management review instead of duplicating everything from zero. The risk register can become an extension of the one that already exists, not a parallel system nobody looks at after the first month.

Sequence matters more than content

The most common mistake is about order rather than technique: procedures get written before context and objectives are defined, or an AI system inventory gets built months after those systems are already in production, documenting after the fact what should have been decided beforehand. An AIMS assembled this way looks more like a retroactive justification than a management system.

The right sequence starts with context, who the interested parties are and what they expect from how the organization uses AI, then moves to policy, risk assessment, inventory, and finally operating controls. Each step leans on the one before it. Skipping one to reach the certificate faster produces a fragile system, one that holds up on paper and gives way at the first real check.

Before starting

Anyone tasked with putting order into this starting point does well to pause before writing the first document, and ask what the organization actually knows about itself: how many AI systems it really runs, at what risk, at what maturity. That's the same ground covered by AI Assessment, mapping before formalizing, because a document written without that map stays paper with a date on it, not a management system under ISO/IEC 42001.

The question we'll pick up in the next piece of this series is the AI system inventory itself: how it's built, what it actually needs to contain, and why almost no company has one that's actually current when it says it does.