ISO/IEC 42001 is the international standard for an AI management system (AIMS). It was published in December 2023, and an organisation can be certified against it. ISO 42001 does not certify that a model is safe or accurate. It certifies that your organisation runs a repeatable, audited system for governing the AI it builds, provides or uses. For engineering teams, that system becomes real through evidence, and this guide explains what the standard asks for and which artefacts engineers produce.
A note on scope: this is an explainer written in our own words, not a reproduction of the standard. ISO/IEC 42001 is a copyrighted document sold by ISO and national standards bodies. Before you make implementation or certification decisions, consult the standard and a qualified auditor.
What ISO/IEC 42001 actually is
ISO/IEC 42001:2023 was developed by the joint ISO/IEC committee for artificial intelligence. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system within an organisation. It applies to organisations of any size that develop, provide or use AI systems.
The key word is management system. If you know ISO/IEC 27001 or ISO 9001, the shape is familiar. It doesn't tell you which model or accuracy threshold to use. It requires you to decide those things deliberately, assign owners, act, measure and improve. Where the EU AI Act is law and the NIST AI RMF is a voluntary framework, ISO 42001 is a certifiable standard for how an organisation governs AI.
For risk tiers, roles and lifecycle gates, see our enterprise AI governance framework. This article covers the standard itself and the evidence an AIMS audit depends on.
The structure: clauses 4 to 10 and Plan-Do-Check-Act
ISO 42001 follows the harmonised structure that ISO uses for management-system standards. That is why ISO/IEC 27001-certified organisations can often extend existing processes instead of building new ones. The auditable requirements sit in clauses 4 to 10, which map onto Plan-Do-Check-Act.
PLAN DO
4 Context of organisation 8 Operation
5 Leadership (run risk + impact
6 Planning (risks, impacts, processes, operate
objectives) controls)
7 Support (resources,
competence, documents)
^ |
| v
ACT CHECK
10 Improvement 9 Performance evaluation
(nonconformity, (monitoring, internal
corrective action) audit, mgmt review)In plain terms: context (4) means knowing your issues, interested parties, your role as developer, provider or user, and the AIMS scope, which can be one business unit rather than the whole enterprise. Leadership (5) sets the AI policy and assigns roles. Planning (6) covers AI risk assessment and treatment, AI system impact assessment and measurable objectives. Support (7) covers resources, competence, awareness and documented information. Operation (8) means actually running those processes and keeping the evidence. Performance evaluation (9) means monitoring, internal audit and management review, and improvement (10) means corrective action and continual improvement.
Annex A controls, by theme
Like ISO/IEC 27001, ISO 42001 has a normative Annex A: a reference set of control objectives and controls. Published summaries describe it as nine control objectives with 38 controls. You select controls based on your risk assessment, justify exclusions and record decisions in a Statement of Applicability. The themes are:
- Policies related to AI: an AI policy, aligned with other policies and reviewed periodically.
- Internal organisation: defined roles and responsibilities for AI, and a way for people to raise concerns.
- Resources for AI systems: documenting the data, tools, compute and people an AI system depends on.
- Assessing impacts of AI systems: assessing and documenting consequences for individuals, groups and society.
- AI system life cycle: responsible design and development, requirements, verification and validation, deployment, operation, monitoring and technical documentation.
- Data for AI systems: data management, acquisition, quality, provenance and preparation.
- Information for interested parties: information for users, channels to report adverse impacts, and incident communication.
- Use of AI systems: responsible use, in line with intended purpose.
- Third-party and customer relationships: allocating responsibilities, supplier controls and customer needs.
The standard also has informative annexes. Annex B gives implementation guidance for the controls. Annex C lists possible AI-related organisational objectives and risk sources. Annex D discusses using the AIMS across domains and sectors. Annex B is the one engineers will use most.
Related standards: 23894, 42005, 42006 and 27001
ISO 42001 sits within a family of standards. Know which ones are certifiable and which only give guidance.
| Standard | What it is | Certifiable? | How it relates to 42001 |
|---|---|---|---|
| ISO/IEC 23894:2023 | AI risk-management guidance built on ISO 31000 | No (guidance) | Informs the AI risk assessment and treatment process |
| ISO/IEC 42005:2025 | Guidance on when and how to assess and document AI system impacts on people and society | No (guidance) | Supports the impact-assessment requirement |
| ISO/IEC 42006:2025 | Requirements for bodies that audit and certify AI management systems, supplementing ISO/IEC 17021-1 | Applies to certification bodies | Raises the bar for who may issue a credible 42001 certificate |
| ISO/IEC 27001 | Information security management system standard | Yes | Same structure, so the two integrate. 42001 adds the AI-specific concerns |
A practical point: 42001 doesn't replace 27001. A prompt-injected tool call that leaks data is a security failure first; see AI security for enterprises.
How it relates to the EU AI Act and NIST AI RMF
EU AI Act. The Act is binding law with obligations that depend on an AI system's risk category and on your role (provider, deployer and others). ISO 42001 is a voluntary, organisation-level standard. They overlap heavily: risk management, data governance, documentation, human oversight and monitoring appear in both. But ISO 42001 certification is not, by itself, proof of compliance with the Act. The Act gives a legal presumption of conformity through harmonised European standards, which European standardisation bodies (CEN and CENELEC) are developing for that purpose. ISO 42001 is not one of them, though it influences that work. Treat an AIMS as the foundation, then map the Act's system-specific obligations on top. See our guide to the EU AI Act for Indian IT and GCC teams.
NIST AI RMF. The US NIST AI Risk Management Framework is voluntary, non-certifiable and organised around four functions: Govern, Map, Measure and Manage. Many teams use its vocabulary to decide what to do about AI risk and ISO 42001 to run that work as an auditable system. NIST has published crosswalks between its framework and ISO AI standards.
In India, AI systems that process personal data also have to satisfy the Digital Personal Data Protection Act. See our guide to the DPDP Act for AI applications.
The engineering translation: what evidence you produce
Auditors look for evidence that the system works: records, not slide decks. Most of that evidence comes from engineering, and it overlaps almost entirely with what a good AI team should produce anyway:
- Model and AI system inventory: owner, purpose, role, model and provider, data sources, tools it can call, users and risk tier. If it isn't in the inventory, it isn't governed.
- Risk and impact assessments: risks to the organisation and impacts on the people affected, each with treatment decisions and a named approver.
- Data documentation: provenance, lawful basis or licence, quality checks, preparation and retention.
- Evaluation records: versioned test sets, thresholds and per-release results (see LLM evaluation), plus adversarial findings from AI red teaming.
- Monitoring: traces, quality and safety signals, drift and alert owners. This is AI observability applied to a control objective.
- Incident process: what counts as an AI incident, severity, escalation, post-incident review and corrective action.
- Supplier controls: model-provider due diligence, data-use terms and a record of model versions you depend on.
The table maps each requirement theme to the artefact an engineer typically owns. It is a practical mapping, not an official clause-by-clause crosswalk.
| Requirement theme | Engineering artefact | Where it usually lives |
|---|---|---|
| Context and scope | AI system inventory with roles and boundaries | Service catalogue or CMDB with AI fields |
| AI risk assessment and treatment | Per-system risk register entry with chosen controls | Risk tool, linked from the inventory |
| AI system impact assessment | Impact record: affected groups, harms, mitigations | Design review template, signed before pilot |
| Resources for AI systems | Architecture diagram, model and tool list | Repository docs and infrastructure as code |
| Life cycle: verification, validation, change | Evaluation suite, release report, prompt and model version history | CI artefacts, Git, change tickets |
| Data for AI systems | Data sheet: sources, provenance, quality, retention | Data catalogue or ingestion repository |
| Operation and monitoring | Dashboards, alerts, drift and quality reports | Observability stack |
| Information for interested parties | User documentation, AI disclosure, problem-reporting channel | Product docs, UI copy, support workflow |
| Use of AI systems | Intended-use statement and human-oversight design | System card and approval workflow |
| Third-party relationships | Supplier assessment, data terms, model dependency list | Procurement records, dependency manifest |
| Incidents and improvement | Incident tickets, reviews, corrective-action log | ITSM tool such as ServiceNow or Jira |
The pattern that works is evidence as a by-product. When CI produces evaluation reports on every release, traces are kept automatically and incidents go through your ITSM tool, the audit becomes a retrieval exercise. Evidence assembled by hand the week before the auditor arrives is inconsistent, and auditors notice.
Building these habits works better through shared training than through a policy PDF. Cloudsoft's corporate training for engineering teams covers evaluation, observability, security and governance artefacts on the same stack your teams ship with.
How certification works
Certification is carried out by independent certification bodies. Look for a body accredited for ISO/IEC 42001 by a recognised accreditation body. In India that is typically NABCB, and abroad it is the national accreditation body of the relevant country. ISO itself does not certify organisations. With ISO/IEC 42006 now published, expect certification bodies to show AI-specific auditor competence.
The typical journey resembles other ISO certifications:
- Scope and gap assessment against the requirements.
- Implementation: policy, roles, risk and impact processes, the Statement of Applicability, controls and evidence.
- Operate for a period: auditors want records, an internal audit and a management review, not just documents.
- Certification audit: usually a readiness review, then an assessment of implementation and effectiveness.
- Maintain: periodic surveillance audits and recertification on the certification body's cycle.
Timelines and cycle details depend on scope and size, so confirm them with your certification body.
Common misunderstandings
- "Certified means the model is safe." No. Certification says the management system meets the standard and was operating when audited. A certified organisation can still ship a chatbot that invents a refund policy. A good AIMS makes that rarer, faster to detect and properly corrected, but it says nothing about any particular output.
- "It's a product certification." It certifies an organisation's management system within a defined scope. Always read the scope statement on a supplier's certificate.
- "We must implement all of Annex A." Controls are selected through risk assessment, with exclusions justified in the Statement of Applicability.
- "It only applies if we train models." Organisations that only use or integrate third-party models are within its intended audience. For integrators, the supplier, use and monitoring themes matter most.
- "It's a compliance team project." Without engineering evidence there is nothing to audit. Governance owns the system, and engineering produces most of the proof.
Getting started: a GCC or IT services firm
Global capability centres in Hyderabad and Bengaluru, and Indian IT services firms, often meet ISO 42001 first as a client questionnaire item. A GCC usually operates within its parent's governance. A services firm may be a developer for one client and an AI user internally. A pragmatic sequence:
- Decide role and scope. Are you developing for clients, operating systems, using AI internally, or all three? Start with one delivery unit or practice.
- Build the inventory first, including internal assistants and AI coding tools. Most firms find more AI in use than they expected.
- Extend ISO/IEC 27001 if you hold it. Reuse document control, internal audit, management review and supplier processes, then add AI risk and impact assessments and life-cycle controls.
- Standardise templates: one system card, one impact-assessment template, one release evaluation report and one AI incident category, used by every project.
- Split responsibilities in contracts. The client is often the deployer and you are the developer. Write down who owns model choice, data, evaluation sign-off, monitoring and incident response.
- Train the people who produce the evidence: delivery leads, engineers and testers.
- Operate, audit internally, then certify with an accredited body.
Illustrative example: an IT services firm building for an insurer
Consider a Hyderabad IT services firm building a claims-triage assistant for a European insurer. It summarises claim documents, suggests a routing queue and drafts requests for missing documents, and a human handler approves every action. The insurer's procurement team asks whether the firm operates an AIMS aligned to ISO 42001.
The firm puts its AI delivery practice in scope and records the assistant as a system it develops for a client that deploys it. The impact assessment names the affected groups (claimants and handlers), the risk of unfair routing delays for some claim types, and personal and health data in prompts and logs. The recorded treatments:
- Human approval for every routing decision and outbound message, designed so that handlers review rather than rubber-stamp (see human-in-the-loop AI).
- An evaluation suite of anonymised historical claims with faithfulness and routing-agreement thresholds, run in CI on every prompt or model change and attached to the change ticket.
- PII redaction before logging, a data sheet for the retrieval index, and retention aligned with the insurer's policy.
- Monitoring of override rates by claim type as an early skew signal, with an alert owner on each side.
- A supplier record for the model provider and a contract annex that splits responsibilities.
- An AI incident category in the shared ticketing tool, with joint post-incident reviews.
None of these exists only for the auditor. Each makes the system easier to ship and defend.
Building systems like this end to end is what Forward Deployed Engineers do. Cloudsoft's AI Forward Deployed Engineer FDE PRO program includes a Secure Banking AI Assistant project where evaluation, security and audit evidence are part of the build.
FAQ
What is ISO 42001?
ISO/IEC 42001 is an international, certifiable standard, published in December 2023, that specifies requirements for an AI management system. It covers how an organisation governs the AI it develops, provides or uses.
Is ISO 42001 certification mandatory?
No. It is a voluntary standard. Organisations usually certify when customers or partners expect independent assurance of how they govern AI.
Does ISO 42001 certification mean an AI system is safe?
No. It certifies that an organisation's AI management system meets the standard within a stated scope. It does not certify that any model or output is accurate, fair or safe. That still depends on each system's evaluation, monitoring and controls.
How is ISO 42001 different from ISO 27001?
Both use the same management-system structure. ISO/IEC 27001 manages information security risk, while ISO/IEC 42001 addresses AI-specific concerns such as impact on people, data quality and provenance for AI, the AI life cycle and responsible use. The two can be integrated.
Does ISO 42001 make us compliant with the EU AI Act?
Not on its own. The two overlap substantially, so an AIMS is a strong foundation, but the EU AI Act places legal obligations on specific AI systems according to their risk category and your role. Map those obligations separately and take legal advice.
Who issues ISO 42001 certificates?
Independent certification bodies, ideally accredited for ISO/IEC 42001 by a recognised national accreditation body. ISO publishes the standard but does not certify organisations. ISO/IEC 42006 sets additional requirements for bodies that audit AI management systems.
What do engineers need to produce for an ISO 42001 audit?
Typically an AI system inventory, risk and impact assessments, data documentation, versioned evaluation records, production monitoring evidence, an AI incident process with post-incident reviews, and supplier records for model providers. Ideally these are generated as part of normal delivery.
If your organisation is preparing for an AIMS and needs engineering, delivery and testing teams to produce audit-ready evidence as part of normal work, explore Cloudsoft's corporate AI training programmes, delivered in our Ameerpet classroom or live online. Call +91 96660 19191 to discuss a team programme or book a free demo.
