An ISO/IEC 42001 AI management system (AIMS) needs a defined scope, an AI policy, roles, objectives, an AI risk and impact assessment method with results, a Statement of Applicability, an inventory of AI systems, lifecycle procedures, supplier controls and the usual audit and review records. The standard is paywalled, so confirm exact requirements in your copy.
What is ISO/IEC 42001?
It is an international management system standard for artificial intelligence, aimed at organisations that develop, provide or use AI. A certification body page from BSI describes it as extending the principles of ISO 27001 to AI security risks and data protection challenges, and says certification is done by accredited bodies after independent assessment. The standard text is paywalled and the ISO page returned an access block, so this guide describes the document set in general terms. Like other ISO management system standards, it follows the pattern of context, leadership, planning, support, operation, performance evaluation and improvement. Check clause numbers and mandatory documented information against your purchased copy.
Which documents form the core?
Governance documents
- AIMS scope. Which AI systems, products and business units, which roles you play (developer, provider, user), and the boundaries and exclusions.
- Context and interested parties. Customers, regulators, affected people, and what each expects.
- AI policy. Short, approved by top management, stating principles and commitments such as responsible use, safety, transparency and compliance with law, and how the policy is communicated.
- Roles and responsibilities. Named owner of the AIMS, accountable executives, system owners, reviewers.
- Objectives. Measurable aims with owners and dates.
Risk and impact documents
- AI risk assessment method. Scales, criteria, acceptance threshold and who approves.
- Risk register and treatment plan. Risks to the organisation and to people, selected treatments and owners.
- AI system impact assessment process and records. How you assess consequences for individuals and groups, and results for each system in scope. This is a distinguishing feature of an AI standard compared with a pure security standard.
- Statement of Applicability. Which of the standard's reference controls apply, why, and implementation status.
Operational documents
- AI system inventory. Name, purpose, owner, model and version, data sources, users, deployment, status. Include third party AI features you rely on.
- Lifecycle procedures. Requirements, design, data preparation, development, verification and validation, deployment, monitoring, retirement. Keep each short and tied to roles.
- Data governance. Data quality, provenance, labelling, privacy handling and retention for training and operation.
- Testing and evaluation records. What you tested, thresholds, results, dates, sign off.
- Human oversight and transparency. How people can understand, override or contest outputs, and what you tell users.
- Third party and supplier controls. Due diligence on model and data providers, contract terms, review dates.
- Incident and change procedures. What counts as an AI incident, escalation, communication, model change control.
Assurance and improvement records
- Competence and training records.
- Internal audit programme, reports and corrective actions.
- Management review minutes with decisions and resources.
- Corrective action register.
How long should each document be?
Short. Policies in one or two pages, procedures in a page or two, templates for records. An auditor wants to see that people follow the document, not that it is long. Write in the language your engineers and product managers use, and link to the real tools: model registry, ticket system, evaluation dashboards.
Which mistakes recur?
- An AI policy that lists values and no commitments or owners.
- An inventory that misses shadow AI, such as assistants used by sales or support.
- Impact assessments that copy generic text instead of describing the specific system and people affected.
- Risk register that covers security but not misuse, bias, reliability or transparency.
- No evidence from operation: monitoring, evaluation or review results.
- Treating suppliers as someone else's problem.
- Internal audit by the system builder.
Which related frameworks help?
The NIST AI Risk Management Framework, with its Govern, Map, Measure and Manage functions, is a voluntary companion that many teams use to structure risk work. NIST says it is being revised, so check the current version. Privacy and security management systems already in place can supply shared documents such as training, internal audit and management review.
What to do
- Buy the standard and read the requirements for documented information.
- Fix the scope and decide your roles for each AI system.
- Build the AI system inventory first.
- Write the AI policy, assign roles and set objectives.
- Define the risk and impact assessment methods and run them on the top systems.
- Draft the Statement of Applicability from the standard's control list.
- Write lifecycle, data, supplier and incident procedures in short form.
- Run internal audit and management review before booking certification.
Quick check
Is an AI policy mandatory for ISO 42001?
Management system standards of this kind expect a top management approved policy, so plan for one. Confirm the exact wording of the requirement in the standard text.
Who certifies an AI management system?
Accredited certification bodies assess and certify after an independent audit. Tools and consultants can help you prepare but cannot certify.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, which gives the team time for other work. For AI systems built on open source libraries and packages, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. Certification is decided by an accredited body.
Open the framework mapping demo or book a call.
Sources
The ISO pages and the standard text were blocked or paywalled when fetched, so the document list is a general guide, not a clause by clause requirement list.
Last reviewed: 18 October 2026.