Documentation for ISO 42001

ISO 42001 requires documented information. You can obtain the standard from NEN , and it follows the same High Level Structure as other ISO standards. This is not a thick binder of procedures that nobody reads, but working documentation that supports your system. On this page we explain what you need and how to keep it practical.

Mandatory documentation

The standard explicitly requires certain documents. You must have these for certification.

Scope of the AIMS

What: A document that describes which parts of your organisation and which AI systems fall within the AI management system.

Why: The auditor must know what is being assessed. You cannot certify everything, and it would be a problem if half turned out to be outside the scope.

In practice: 1-2 pages. Describe which AI systems, which locations and which processes. Be specific.

AI policy

What: A document that describes the intentions and direction of the organisation regarding AI. Signed by top management.

Why: The policy is the basis for all other decisions. It communicates what your organisation is aiming for with AI.

In practice: 2-4 pages. Describe your principles (transparency, fairness, accountability), your objectives and your governance. No corporate speak, but concrete guidelines.

The policy must be communicated to the relevant employees. A policy that sits in a drawer does not count.

Risk assessment and treatment

What: Documentation of the risk management process: how do you identify, analyse and treat AI risks? Plus the results: which risks have you identified and what are you doing about them?

Why: The risk analysis determines which controls you take. Without a documented analysis, the auditor cannot assess your choices.

In practice: A risk register (spreadsheet) with the risks, scores and treatment for each AI system. Plus a description of the methodology.

AI system impact assessment

What: Documentation of the impact of your AI systems on individuals, groups and society.

Why: This is unique to ISO 42001. You must show that you have considered the wider consequences of your AI.

In practice: A template per AI system covering: description, stakeholders, impact per dimension (fairness, privacy, safety), mitigation measures.

Read more about the AI impact assessment.

Verklaring van Toepasselijkheid (statement of applicability, SoA)

What: A document that states, for each Annex A control, whether you have selected it, and why or why not.

Why: You do not have to implement all 38 controls. But you must be able to explain your choices.

In practice: A table with all controls. For each control: applicable (yes/no), reason, implementation status.

Objectives

What: Documented objectives for the AI management system.

Why: Without measurable objectives, you cannot assess whether the system is effective.

In practice: 3-5 concrete objectives with metrics. For example: “95% of new AI systems go through an impact assessment before deployment.”

Evidence of competence

What: Evidence that employees carrying out AI-related tasks have the necessary competences.

Why: You must be able to show that people are qualified for their work.

In practice: Training records, certificates, CVs, training plans.

Results of internal audits

What: Reports from internal audits, including findings and follow-up.

Why: Internal audits are mandatory. You must be able to show that you carry them out and follow them up.

In practice: An audit report for each audit with scope, findings and corrective actions.

Results of management reviews

What: Minutes or reports of management reviews.

Why: Top management must review the AIMS periodically. This must be documented.

In practice: Minutes with the required input (performance, audits, risks) and output (decisions, actions).

Nonconformities and corrective actions

What: Records of nonconformities (things that go wrong) and the actions you take.

Why: Continual improvement requires learning from mistakes. You must be able to demonstrate this.

In practice: A register or ticket system with nonconformities, root cause analysis, corrections and status.

How much documentation is enough?

The standard does not say how long documents should be. What matters is:

Completeness: Are all required elements present?

Currency: Is the documentation up to date?

Usability: Is the documentation used? Do people know where it is?

Traceability: Can an auditor follow the logic?

More documentation is not better. A start-up can meet the standard with 20 pages of documentation. A multinational needs more, but not necessarily proportionally more.

Document management

ISO 42001 also requires you to manage your documentation.

Version control

Documents must have versions. You must be able to see what the current version is and what has changed.

Approval

Important documents (policies, procedures) must be approved by the right person.

Availability

Documents must be available to those who need them. Not hidden in someone’s inbox.

Protection

Documents must be protected against unauthorised changes or loss.

Retention

You must keep documents, including old versions. The auditor may ask for historical information.

Tooling

You do not need fancy software. But tooling can help.

Simple

Google Drive / SharePoint: Store documents with folders and versions.
Wiki (Notion, Confluence): Procedures and manuals.
Spreadsheets: Risk registers, SoA, AI system register.

Specialised

GRC platforms: Vanta , Drata , Secureframe - Compliance management with automation.
ISMS tools: ISMS.online , Advisera - Specifically for management systems.
MLOps platforms: MLflow , Weights & Biases - For technical AI documentation.

What fits?

Start-up: Google Drive, Notion and spreadsheets are fine.
SME: Consider a GRC platform if you combine several frameworks.
Enterprise: A GRC platform is almost essential for oversight and audits.

The minimum set for a start-up

If you want to start lean, focus on:

AI policy (2 pages)
Scope (1 page)
AI system register (spreadsheet)
Risk register (spreadsheet)
Impact assessment template (reusable)
Statement of applicability (table)
Audit minutes (after the audit has been carried out)
Management review minutes (after the review has been carried out)

This is not much. Start with these and build out where needed.

Documentation and the audit

The auditor asks for documentation as evidence. Prepare for this:

Stage 1: The auditor reviews your documentation. Is everything present? Is it coherent?

Stage 2: The auditor asks for specific documents as evidence. “Show me the impact assessment for system X.” “Where is the approval for this risk?”

Tips:

Know where everything is
Make sure documents are current
Do not print or open documents for the first time during the audit
Have someone who can search quickly

Common mistakes in ISO 42001 documentation

Too much documentation. Pages of text that nobody reads. Keep it short and relevant.

Not up to date. Procedures from two years ago while the process has changed.

Not findable. “It is somewhere…” is not a good answer during an audit.

Not communicated. Excellent documents that nobody knows about.

Copy-pasting from other standards. ISO 27001 documentation with “AI” added. The auditor will see through that.

Documentation as a tool

Do not treat documentation as audit paperwork. A checklist per requirement shows which evidence you keep and where. Good documentation helps your organisation:

Onboard new employees faster
Keep consistency across teams
Retain knowledge when people leave
Analyse incidents and learn from them
Improve based on measurements

If you only write documentation for the auditor, you miss its value.