A certification audit rarely fails because an organisation cannot produce a policy. It fails because the policy is disconnected from the AI systems actually in use, the people accountable for them, and the evidence needed to prove that controls operate. That is the practical starting point for how to prepare ISO 42001: build an AI management system that reflects real decisions, real risks and real operational ownership.
ISO/IEC 42001 is the first certifiable management system standard for artificial intelligence. It gives organisations a structured way to govern AI across its lifecycle, from procurement and design through deployment, monitoring and retirement. For compliance teams already managing GDPR, information security or quality frameworks, the management-system model will be familiar. The AI-specific work is not.
Set the scope before building documentation
Do not begin by drafting an AI policy. Begin by deciding what the AI management system, or AIMS, covers. The scope should state the legal entity, business functions, locations, AI activities and systems included. It should also identify justified exclusions.
A narrow pilot scope can be proportionate where an organisation has limited AI deployment. However, it must not exclude the systems creating the material risk simply to make certification easier. If customer-facing machine learning, generative AI used in decision-making, or a high-impact third-party tool sits outside the scope, an auditor will expect a credible rationale.
This scope decision should be anchored in a complete AI inventory. Record each system, its owner, purpose, users, data categories, supplier or development team, deployment status and affected stakeholders. Include conventional machine-learning models, generative AI tools, embedded AI in software products and externally procured systems. Shadow AI use is often the first material gap: a sanctioned list of systems is not an inventory if staff are using unapproved tools outside it.
The inventory becomes the system of record for the rest of the programme. Without it, risk assessments are incomplete, controls cannot be assigned consistently and management reporting is speculative.
How to prepare ISO 42001 through governance ownership
ISO 42001 requires leadership commitment, defined responsibilities and an AI policy aligned to organisational objectives. In practice, that means translating broad executive support into named accountabilities.
Senior management should approve the policy, establish the risk appetite and receive performance information. The AIMS owner coordinates the framework and reports on its effectiveness. System owners remain accountable for the systems in their portfolios. Legal, privacy, security, procurement, data science and operational teams need defined responsibilities where their work affects AI risk.
Avoid creating a governance committee that exists only on an organisation chart. Define its mandate, membership, escalation thresholds and decision rights. For example, the committee may approve high-risk use cases, accept residual risk above a threshold, review significant incidents and authorise production deployment where required controls are evidenced.
This is also where ISO 42001 needs to connect with the EU AI Act. The two frameworks overlap, but they are not interchangeable. ISO 42001 establishes a management system for governing AI risks and objectives across the organisation. The EU AI Act creates role-specific legal obligations for providers, deployers, importers and distributors, including requirements that vary by risk category. A sound preparation programme maps legal duties into the AIMS rather than treating certification as a substitute for legal compliance.
Build a risk method that reaches beyond cyber security
Many organisations start with their existing information-security risk register. Reuse its governance mechanics where sensible, but do not force AI risks into a cyber-only model. AI risk includes fairness and discrimination, explainability, human oversight, data quality, model performance, misuse, intellectual property, environmental impact and effects on individuals or groups.
Set a documented assessment method before assessing systems. It should define likelihood and impact scales, risk acceptance criteria, review frequency, required approvers and escalation rules. The method needs to consider intended use, reasonably foreseeable misuse, affected persons, lifecycle stage and dependencies on third parties.
For each AI system, retain a clear assessment trail: the system description, relevant risks and impacts, existing controls, residual risk, treatment actions, accountable owner and approval decision. This is more defensible than a single generic enterprise AI risk assessment copied across every use case.
The level of analysis should be proportionate. An internal writing assistant used for low-sensitivity drafting does not need the same scrutiny as an AI system supporting recruitment, credit decisions, access to essential services or safety-critical operations. Proportionate does not mean undocumented. It means applying the right depth of control to the risk.
Select controls and turn them into operating evidence
Annex A of ISO/IEC 42001 provides a reference set of AI management controls. Organisations must determine which controls are applicable, justify exclusions and document this in a Statement of Applicability. Treat this as an operational design exercise, not a box-ticking spreadsheet.
Controls may cover AI policies, internal organisation, resource management, impact assessment, lifecycle management, data management, information for interested parties, use of AI systems and third-party relationships. The relevant question is not whether a control can be marked as complete. It is whether the organisation can demonstrate how it operates.
For a supplier-managed AI tool, evidence may include due diligence records, contractual requirements, data-processing terms, security review, intended-use limitations, supplier monitoring and a documented exit approach. For an internally developed model, evidence may additionally cover training-data governance, testing criteria, version control, validation, release approval and post-deployment monitoring.
A control register should identify the control objective, implementation status, system applicability, control owner, supporting evidence, review date and linked risk. This prevents a familiar failure mode: evidence scattered across inboxes, shared drives, procurement folders and engineering tools, with no reliable route from risk to control to proof.
Make lifecycle governance visible
ISO 42001 expects controls across the AI system lifecycle. The exact lifecycle differs between an organisation building models and one primarily procuring software, but the governance gates should be visible in both cases.
Before acquisition or development, record the business purpose, intended users, affected stakeholders, data requirements and preliminary risk classification. Before deployment, verify that testing, security, privacy, legal review, human oversight arrangements and owner acceptance are complete. After deployment, monitor performance, incidents, significant changes and continued suitability.
Define what counts as a material change. A new model version, altered decision threshold, new data source, different user group, expanded geographical deployment or changed supplier terms may all require reassessment. If this trigger is absent, organisations can certify a management system while allowing AI systems to drift beyond their approved risk position.
Incident management must also account for AI-specific events. Model degradation, discriminatory outputs, unsafe recommendations, harmful automation, data leakage through prompts and failures of human oversight need routes for reporting, investigation, containment and corrective action.
Prepare the management-system evidence
Certification readiness depends on documented information, but volume is not the goal. Auditors look for controlled, current artefacts that show the AIMS is planned, implemented, evaluated and improved.
At minimum, preparation should produce a coherent scope, policy, AI inventory, stakeholder and context analysis, risk methodology, system-level assessments, objectives, Statement of Applicability, control records, competence records, operational procedures, internal-audit results, management-review minutes and corrective-action records. The evidence should be version-controlled, owned and easy to retrieve.
Set measurable AI objectives that management can actually review. Examples include completing risk assessments before production deployment, closing overdue high-risk treatment actions, reviewing critical suppliers on schedule, or ensuring named owners confirm material system changes. Avoid objectives such as “maintain responsible AI” unless they are paired with measurable indicators.
Training should be role-based. A procurement team needs to recognise AI supplier due-diligence requirements. System owners need to understand approval gates and monitoring duties. Senior managers need sufficient awareness to make risk acceptance decisions. Generic annual awareness training alone will not establish competence.
Test the system before the certification audit
Run an internal audit once the AIMS has operated long enough to generate evidence. It should test whether practice matches the documented process, not merely whether documents exist. Sample systems across different risk profiles, trace decisions through to approvals, and ask owners to demonstrate how they monitor their systems.
Follow with a formal management review. Senior management should consider audit findings, performance against objectives, changes in internal and external issues, stakeholder feedback, incidents, supplier performance, resource needs and improvement opportunities. Record decisions, owners and deadlines.
A pre-assessment can be useful, particularly for organisations seeking their first management-system certification. It is not mandatory, and it should not become an expensive substitute for doing the foundational work. The better test is whether an independent reviewer can select an AI system and quickly see its purpose, owner, classification, risks, applicable controls, evidence and current status.
Purpose-built governance tooling can reduce the administrative burden by linking the inventory, legal classification, assessments, controls, actions and board reporting in one place. The value is not another dashboard. It is a traceable evidence chain that survives staff changes, audit sampling and regulatory scrutiny.
The most useful preparation milestone is not the date of the external audit. It is the point at which a system owner can explain, without chasing spreadsheets, why an AI system is permitted to operate, what risks remain, who accepted them and what will trigger the next review.