ISO 42001 Templates and Checklists: The Documents the Standard Actually Requires

You do not have to guess which templates an ISO 42001 project needs. The standard writes the list for you. ISO/IEC 42001:2023, the AI management system standard, requires specific documented information at specific clauses, and each of those required records has a template behind it.

That is the most useful way to think about templates and checklists: not as a generic pack to download, but as a set of documents the standard names, each tied to the clause it satisfies. Get that mapping right and your documentation is audit-ready by design rather than by luck.

This guide from the AI Governance Certification Institute (AIGCI) lays out the templates the standard requires, the checklists that keep you audit-ready, and how the documents connect into one system. It is the detail behind what training includes.

Templates and Checklists Do Two Different Jobs

Before the list, separate the two, because people often lump them together and then wonder why a folder of templates still leaves them unprepared for an audit.

A template is a document you produce and keep: an AI policy, a risk register, a Statement of Applicability. It is the evidence itself. A checklist is a tool you verify against: a list of what documented information you should hold, or the points an internal auditor will test. One creates the record; the other confirms the record exists and holds up. A complete toolkit has both.

Maintain or Retain: Two Kinds of Documented Information

ISO 42001 draws a quiet but important line between the documents you keep current and the records you keep as proof. Missing it is why some projects maintain a tidy policy folder yet cannot answer an auditor who asks for evidence.

The standard tells you to maintain certain documented information, the living documents that must always reflect the present, such as the scope statement and the AI policy. It tells you to retain other documented information, the dated records that prove something happened, such as a completed risk assessment, an internal audit report, or management review minutes. Maintained documents answer what the system is; retained records answer what the system did. A sound approach to records management keeps the two apart, with version control on what you maintain and a clear retention trail on what you retain.

Keep that distinction in view as you read the clause list below, because each required item is really one or the other, and auditors test them differently.

The Templates the Standard Requires, by Clause

Read ISO 42001 clause by clause and a clear template list falls out of it. The table below maps each piece of required documented information to the clause it comes from and the template that captures it. For the clauses themselves in full, see the clauses they map to.

Two of these do the heaviest lifting and are worth building carefully. The AI policy template sets the direction everything else hangs off, and the risk register is where your AI risks become owned, rated, and trackable rather than a vague worry.

Why These Documents, and Why They Look Familiar

If the clause list above feels recognizable, that is by design, and knowing why saves you effort.

ISO/IEC 42001:2023 was developed by ISO/IEC JTC 1/SC 42, the artificial intelligence subcommittee of the joint ISO and IEC technical committee, and it is built on the harmonized high-level structure that ISO uses across its management system standards. That shared structure, defined in Annex SL of the ISO/IEC Directives, is why clauses 4 to 10 and the documents they require line up with standards like ISO 9001 and ISO/IEC 27001: the same scope statement, policy, risk and treatment records, and audit and review records carry across. If your organization already keeps documented information for another ISO management system, you are extending a pattern you know rather than starting from zero.

It also explains the Statement of Applicability, which comes from the same management system tradition. The Annex A controls are a reference set, not a mandatory checklist, and the Statement of Applicability is the reasoned record that sits on top of them: it lists which controls you judged necessary, the justification for including them, whether they are implemented, and the justification for excluding any. Treating it as a box to tick is the fastest way to fail an audit. Treating it as a decision log you can defend is what the standard actually asks for, which is why its template carries more weight than almost any other document in the set.

The Checklists That Keep You Audit-Ready

Templates create your records; checklists make sure nothing is missing before an auditor finds the gap. Four are worth keeping close:

•     A documented-information checklist, listing every record the standard expects, so you can confirm each one exists and is current.

•     An internal audit checklist, walking each clause and asking what evidence proves it, the same lens an internal auditor applies, which doubles as audit preparation.

•     A management review checklist, covering the inputs and outputs leadership must consider, so the review is a decision, not a formality.

•     A certification-readiness checklist, a final pass that confirms the whole system is complete before an external audit.

The quiet value of a checklist is that it finds the missing document while you can still produce it, rather than in the audit when you cannot.

The ISO 42001 Documentation Checklist You Can Copy

Here is a short readiness checklist you can copy and use today. Work down it and mark each item yes or no; every no is a document to produce before an audit.

•     Is the AIMS scope defined and documented, with inclusions and exclusions clear? (4.3)

•     Is there an approved AI policy that sets direction and principles? (5.2)

•     Are roles, responsibilities, and authorities assigned in writing? (5.3)

•     Is there a repeatable risk assessment, with results in a risk register? (6.1.2)

•     Is there a Statement of Applicability justifying included and excluded controls? (6.1.3)

•     Has an AI system impact assessment been done for in-scope systems? (6.1.4)

•     Are AI objectives set and measurable? (6.2)

•     Is there evidence of competence for people doing AIMS work? (7.2)

•     Is documented information version-controlled and approved? (7.5)

•     Are operational controls and changes recorded? (8.1)

•     Is monitoring and measurement defined, with results kept? (9.1)

•     Has an internal audit been planned and run at intervals? (9.2)

•     Are management reviews held, with decisions recorded? (9.3)

•     Is there a nonconformity and corrective action log? (10.2)

If you can answer yes to every line with a document behind it, your documentation is in good shape. Where you cannot, you now have a precise to-do list rather than a vague worry.

A Minimum Viable Documentation Set to Start

If the full list feels daunting, start with the documents that unlock everything else. A small, correct core beats a large, half-finished pile.

Five records form that core: a defined AIMS scope, an AI policy, a risk assessment with a populated risk register, a Statement of Applicability, and an AI system impact assessment for your highest-impact system. With those in place under ISO/IEC 42001:2023, you have the spine an auditor looks for first and the inputs the remaining records depend on. The monitoring, audit, and review templates then build naturally on top, because they evaluate the system the first five define.

Starting with the core also avoids a common trap: producing many peripheral documents while the central ones, the policy and the risk picture, stay vague.

How Many Documents Do You Actually Need?

People often ask for a number, as if more documents meant better governance. The number is the wrong target.

What matters is coverage, not count. A lean system that answers every required clause with one clear record each is stronger than a sprawling one with twenty overlapping documents and a gap at Clause 9. Aim to satisfy each requirement once, with a document someone actually maintains, rather than to maximize the size of the folder. An auditor counts gaps, not pages. So resist the urge to pad it out: a tight set of records you can defend end to end will always beat a thick one you only half understand, and it stays far easier to keep current.

It helps to know roughly where the number lands. Read the standard’s clause requirements and you get on the order of fourteen records across clauses 4 to 10, the ones in the table above. On top of that sits a separate Annex A layer, a set of thirty-eight controls grouped under nine objectives, which adds its own documents depending on which controls apply to your scope. That is why published counts range from the high teens to the low twenties: they are counting the Annex A layer and optional bundling differently. Build from the clause list first, then add only the Annex A records your scope genuinely calls for.

How the Templates Connect: One Record Feeds the Next

The templates are not a flat folder of unrelated files. They form a chain, and understanding the chain is what turns a document set into a management system.

The flow runs like this. Your risk assessment identifies and rates AI risks; those risks drive risk treatment, which you record in the Statement of Applicability by deciding which controls apply. In parallel, an AI system impact assessment weighs the effects on people and feeds the same risk picture. The controls you select then produce their own evidence, and the monitoring, audit, and review records close the loop by checking that the controls actually work.

Seen that way, a template is never finished in isolation. Each one is an input to another, which is exactly why a random pack of downloads rarely holds together under audit and a mapped, connected set does.

What Makes a Template Worth Using

Not all templates are equal, and the difference shows the moment you try to use one. A template worth keeping is editable, mapped to a specific clause or Annex A control, and filled with a realistic example you can adapt rather than a blank form you must decode. A weak template is a generic document with the word AI inserted, offering structure you still have to invent.

The fastest way to tell the difference is to ask whether a template would survive an auditor's questions: why is this control here, and where is the evidence? Templates built for those questions save weeks; templates built to look complete cost you them. A worked, standard-mapped set is the core of the practical toolkit.

Template Skeletons You Can Copy

To make this concrete, here are the bare structures of three core documents. Copy the headings, then fill them for your own AI systems. These skeletons give you the shape; the full, example-filled and clause-mapped versions sit in the kit below.

AI Policy Outline

•     Purpose and scope of the policy

•     Principles: fairness, transparency, accountability, safety, and human oversight

•     Roles and responsibilities for AI governance

•     Approach to AI risk and acceptable use

•     Compliance and regulatory commitments

•     Review, approval, and update cycle

Risk Register Columns

•     Risk ID, AI system, and risk description

•     Affected individuals or groups

•     Likelihood, impact, and overall rating

•     Risk owner and chosen treatment or controls

•     Status and next review date

Statement of Applicability Columns

•     Annex A control reference

•     Applicable: yes or no

•     Justification for inclusion or exclusion

•     Implementation status

•     Evidence or document reference

These three carry most of the weight of an AIMS. A skeleton gets you past the blank page; turning it into audit-ready evidence is the work the rest of this guide describes.

Free or Paid: Which Templates Are Worth Keeping

The free-versus-paid question comes up constantly, and the honest answer is that the label matters less than the mapping.

A free template that is genuinely mapped to a clause and editable can serve you well, while a paid one that is generic is a poor trade. What you really pay for in a good set is the mapping to ISO/IEC 42001:2023, the worked examples, and the assurance that the documents connect to one another. If a free template gives you those, use it. If it leaves you inventing the structure, the time you spend becomes the real cost, and it usually exceeds the price of a mapped set.

Where Templates End and Judgment Begins

A template is a starting point, not a finished system, and treating it as the latter is the most common documentation mistake.

A filled-in template with no working control behind it is theater: it looks like governance and governs nothing. The template gives you the structure and the prompts; you still have to make the decisions, run the controls, and generate the real evidence for your own AI systems. Frameworks such as the NIST AI Risk Management Framework help you reason about what belongs in the risk and impact templates, but no document fills itself.

This matters more as regulation tightens. As the EU AI Act pushes organizations to show documented governance rather than assert it, the templates are only as good as the real activity they record. Use them to save structure and time, not to manufacture an appearance of control.

Common Documentation Mistakes

A few mistakes turn a good template set into an audit liability:

•     Copying a template without tailoring it, so the document describes a generic company rather than yours.

•     Treating the Statement of Applicability as a box to tick, rather than a justified record of real decisions.

•     Letting versions drift, so the live document and the approved one no longer match.

•     Documenting intent instead of activity, where the record claims a control that does not actually run.

•     Producing records once and never updating them as the AI systems themselves change.

Who Owns Each Document

A template with no owner goes stale, so decide who maintains each one from the start.

In practice, leadership owns the AI policy and the management review, the implementer owns the Statement of Applicability and the operating procedures, risk owners own their entries in the risk register, and the internal auditor owns the audit records. Assigning an owner to each document is itself part of the roles and authorities the standard requires, and it is the difference between a living system and a one-time paperwork exercise.

Frequently Asked Questions

Does ISO 42001 Require Specific Documents?

Yes. The standard calls for documented information at specific clauses, including the AIMS scope, the AI policy, risk assessment and treatment records, the Statement of Applicability, the AI system impact assessment, and records of monitoring, internal audit, management review, and corrective action. Each of those is a template you need.

How Many Documents Does ISO 42001 Require?

There is no single official number. The clause requirements across sections 4 to 10 produce roughly fourteen records, and the Annex A controls add more depending on your scope, which is why published lists range from the high teens into the low twenties. Treat any fixed count as an interpretation rather than a rule, and aim to cover every requirement that applies to you rather than to hit a number.

What Templates Do I Need to Get Certified?

At minimum, the records the standard requires across clauses 4 to 10, plus a Statement of Applicability covering the Annex A controls. The exact set depends on your scope, but the by-clause list above is the backbone. An auditor will expect each required record to exist, be current, and reflect real activity.

Are Free ISO 42001 Templates Any Good?

Some are useful starting points; many are generic documents with AI language added. Judge a template by whether it is editable, mapped to a specific clause or control, and built to survive an auditor's questions. A free template that forces you to invent the structure can cost more time than it saves.

What Is the Difference Between a Template and the Statement of Applicability?

A template is any document you fill in; the Statement of Applicability is one specific, required record that lists which controls apply and justifies any you exclude. It is produced from your risk treatment, so it sits downstream of your risk assessment rather than being a standalone form.

Do Templates Guarantee I Pass the Audit?

No. Templates give you the right structure and save time, but an auditor checks whether the records reflect real controls and decisions, not whether a form is filled in. A complete set of templates backed by genuine activity passes; a complete set of empty templates does not.

Get the Mapped Set, Not a Random Pack

The value of templates is in having them mapped to the standard and connected to each other, so your documentation holds together under audit. Beyond the free checklist and skeletons above, AIGCI assembles the complete, example-filled set as the full documentation kit, built from the clauses up and connected so the documents feed one another. It comes with the Lead Implementer certification, and you can see every option among the ISO 42001 courses, each built from the clauses up rather than downloaded piecemeal.