Introduction: ISO/IEC 42001 and the Governance of Artificial Intelligence
ISO/IEC 42001:2023 is the world's first certifiable international management system standard dedicated to Artificial Intelligence. Published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in December 2023, it establishes the requirements for an Artificial Intelligence Management System (AIMS). In the same way that ISO/IEC 27001 provides an auditable framework for information security and ISO 9001 for quality, ISO 42001 gives organisations that develop, provide or use AI systems a structured, risk-based and repeatable way to govern them across their entire lifecycle.
The standard responds to a rapidly tightening regulatory and commercial climate. The EU AI Act, the NIST AI Risk Management Framework, India's emerging Digital India Act and the DPDP Act, and sector regulators worldwide are all demanding demonstrable, documented AI governance. ISO 42001 is deliberately designed to be the operational backbone that lets an organisation evidence that governance to auditors, regulators, customers and boards. Because it follows the ISO Harmonised Structure (the ten-clause Annex SL format), it integrates cleanly with ISO 27001, ISO 27701, ISO 9001 and ISO 22301 that many CyberSigma clients already run.
This deep-dive is written for boards, AI governance officers, CISOs, data-science leaders and internal auditors who need an auditor-grade, control-by-control understanding of what ISO 42001 requires, how to scope and implement an AIMS, and precisely what evidence a certification body (or a CyberSigma readiness assessor) will expect to see. It covers all ten management clauses, the Annex A control objectives and controls, the supporting Annex B guidance and the referenced Annexes C and D, plus mappings to adjacent frameworks.
Copyright and licensing note
ISO/IEC 42001:2023 is a copyrighted standard owned by ISO and IEC. Its full normative text, control wording and annex tables must be purchased from ISO, IEC or an authorised national standards body (for example BIS in India, or the BSI/ANSI resellers). This guide is an original explanatory work authored by CyberSigma; it paraphrases requirements for educational purposes and does not reproduce the copyrighted text of the standard. Organisations pursuing certification must obtain a licensed copy of the standard for their implementation team.
What is ISO/IEC 42001?
ISO/IEC 42001 specifies the requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System within the context of an organisation. It is a management-system standard, not a technical or product standard: it does not tell you which algorithms to use or set numerical accuracy thresholds. Instead it requires you to build a governance system that ensures AI is developed and used responsibly, that AI-specific risks and impacts are identified and treated, and that the organisation can demonstrate ongoing conformity.
The scope of the standard is intentionally broad. It applies to any organisation, regardless of size, sector or whether it builds AI in-house, procures it, fine-tunes third-party models or embeds AI into its products and services. Crucially, ISO 42001 addresses concerns that are unique to AI and are not fully covered by ISO 27001 or privacy standards: automated decision-making, machine learning that continues to change after deployment, transparency and explainability, fairness and bias, the treatment of individuals and society affected by AI outputs, and the need for human oversight over autonomous behaviour.
The standard is built around several defining constructs. First, roles across the AI value chain: an organisation may be an AI provider, AI producer, AI customer, AI partner, AI subject or a relevant authority, and it may hold more than one role. Second, the AI system lifecycle: inception, design and development, verification and validation, deployment, operation and monitoring, and retirement. Third, an AI system impact assessment (AISIA) that evaluates consequences for individuals, groups and society. Fourth, a set of AI-specific controls in Annex A that are selected and justified through a Statement of Applicability, mirroring the ISO 27001 model.
| Attribute | Detail |
|---|
| Full title | ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system |
| Type | Certifiable management system standard (Annex SL / Harmonised Structure) |
| Published | December 2023 |
| Issuing bodies | ISO and IEC (Joint Technical Committee ISO/IEC JTC 1/SC 42, Artificial intelligence) |
| Core deliverable | Artificial Intelligence Management System (AIMS) |
| Certification | Yes, by accredited certification bodies (three-year cycle with surveillance audits) |
| Key annexes | Annex A (controls), Annex B (implementation guidance), Annex C (AI objectives and risk sources), Annex D (domains and sectors) |
| Related standards | ISO/IEC 23894 (AI risk), ISO/IEC 22989 (AI concepts and terminology), ISO/IEC 23053 (ML framework), ISO/IEC 27001, ISO/IEC 27701 |
Who Must Comply with ISO 42001?
ISO 42001 is voluntary in the sense that no single law universally mandates it by name. However, it is rapidly becoming a de facto expectation in procurement, a defensible basis for demonstrating compliance with AI regulation, and in many tenders an explicit requirement. Any organisation whose products, services or internal operations meaningfully depend on AI should treat it as strategically important. The following table summarises who is most affected and why.
| Organisation type | Why ISO 42001 applies |
|---|
| AI developers and model builders | Directly responsible for design-time risks: data quality, bias, robustness, documentation and safe release of models and AI products. |
| SaaS and platform providers embedding AI | Customers increasingly demand assurance that embedded AI features are governed, explainable and monitored; certification differentiates in tenders. |
| Enterprises deploying third-party AI | Even without building models, deploying LLMs, decisioning or automation creates accountability for outcomes and requires impact assessment and oversight. |
| Regulated sectors (BFSI, healthcare, insurance) | Sector regulators and audit expectations require documented governance over automated decisions affecting customers and patients. |
| Public sector and government | High scrutiny over fairness, transparency and accountability of AI used in citizen-facing decisions. |
| Suppliers to EU / large enterprises | EU AI Act obligations and enterprise vendor-risk programmes push AIMS certification down the supply chain. |
| Managed service and outsourcing providers | Operate AI on behalf of clients; contractual and assurance obligations flow through the AI value chain roles. |
- Regulatory drivers: EU AI Act (risk-tiered obligations), NIST AI RMF alignment, DPDP Act 2023 and emerging Indian AI advisories, sector regulators (RBI, IRDAI, SEBI expectations on model governance).
- Commercial drivers: RFP and vendor-security questionnaires now routinely ask for AI governance evidence; certification shortens sales cycles.
- Governance drivers: boards and audit committees seeking assurance over AI risk following high-profile bias, hallucination and safety incidents.
- Insurance and liability drivers: demonstrable AI governance supports professional indemnity and cyber cover positions.
Structure of ISO/IEC 42001
ISO 42001 is organised in two layers. The first layer is the management-system requirements in Clauses 4 to 10, following the Harmonised Structure common to all modern ISO management standards. These clauses are normative: to be certified, an organisation must satisfy every applicable requirement. The second layer is the Annex A reference control set (organised into control objectives and controls), which the organisation selects from and justifies via a Statement of Applicability, supported by the implementation guidance in Annex B and the risk-source and domain material in Annexes C and D.
| Clause / Annex | Title | Purpose |
|---|
| Clause 4 | Context of the organisation | Understand internal/external issues, interested parties, AIMS scope and the organisation's AI roles. |
| Clause 5 | Leadership | Top-management commitment, AI policy, and assignment of roles and responsibilities. |
| Clause 6 | Planning | Risk assessment and treatment, AI system impact assessment, and AIMS objectives. |
| Clause 7 | Support | Resources, competence, awareness, communication and documented information. |
| Clause 8 | Operation | Operational planning and control, and execution of AI risk treatment and impact assessment. |
| Clause 9 | Performance evaluation | Monitoring, measurement, internal audit and management review. |
| Clause 10 | Improvement | Continual improvement and management of nonconformities and corrective action. |
| Annex A | Reference controls | Normative control objectives and controls that may be selected to treat AI risks. |
| Annex B | Implementation guidance | Detailed guidance on implementing each Annex A control. |
| Annex C | AI-related objectives and risk sources | Potential organisational objectives and sources of AI risk to consider. |
| Annex D | Use of the AIMS across domains and sectors | How the AIMS applies in different domains and sectors. |
Annex A groups its controls into a set of control objectives. The commonly referenced structure of Annex A control areas is summarised below; each area contains one or more specific controls (identified as A.x.y within the standard).
| Annex A area | Focus | Indicative controls |
|---|
| A.2 Policies related to AI | Establishing and reviewing AI policy and topic-specific policies | Management direction for AI, alignment with other organisational policies |
| A.3 Internal organisation | Accountability, roles and reporting for AI | AI roles and responsibilities, reporting of concerns |
| A.4 Resources for AI systems | Documenting and managing AI resources | Data, tooling, system and computing/human resources, resource documentation |
| A.5 Assessing impacts of AI systems | Assessing consequences for individuals, groups and society | AI system impact assessment process, documentation, and consideration of affected parties |
| A.6 AI system life cycle | Responsible development across the lifecycle | Objectives, design, verification and validation, deployment, operation and monitoring, documentation, event logging |
| A.7 Data for AI systems | Governance of data used to build and run AI | Data acquisition, quality, provenance and preparation |
| A.8 Information for interested parties | Transparency to users and affected parties | System documentation, information to users, reporting and communication of incidents |
| A.9 Use of AI systems | Responsible use and intended purpose | Responsible use policy, objectives for responsible use, intended-use adherence |
| A.10 Third-party and customer relationships | Managing suppliers and customers in the AI value chain | Allocation of responsibilities, supplier management, customer obligations |
Master Assessment Checklist
This is the operational heart of the guide. It walks through every management-system clause (4 to 10) and every Annex A control area, stating for each what an assessor must verify and the typical evidence that demonstrates conformity. Use it as the working audit programme for an internal readiness assessment or a pre-certification gap analysis. No control area is skipped.
Clause 4 - Context of the organisation
| What to verify | Typical evidence |
|---|
| Internal and external issues relevant to AI have been determined (4.1) | Context analysis, PESTLE/SWOT for AI, regulatory horizon scan, documented issues register |
| Needs and expectations of interested parties are identified (4.2) | Stakeholder register covering AI subjects, customers, regulators, employees; captured requirements |
| The organisation's AI roles are determined (provider, producer, customer, partner, subject, authority) | Role determination record mapping each AI system to the organisation's role(s) |
| AIMS scope is defined and documented (4.3) | Scope statement listing AI systems, locations, boundaries, exclusions with justification |
| The AIMS is established and maintained (4.4) | AIMS manual/framework document, process interaction map, references to controls |
Clause 5 - Leadership
| What to verify | Typical evidence |
|---|
| Top management demonstrates leadership and commitment (5.1) | Board/steering-committee minutes, resourcing decisions, accountability statements |
| An AI policy is established, appropriate, and communicated (5.2) | Approved AI policy, distribution records, intranet publication |
| The AI policy includes commitment to requirements and continual improvement | Policy content review against 5.2 requirements |
| Roles, responsibilities and authorities are assigned and communicated (5.3) | RACI matrix, AI governance charter, appointment letters for AI governance officer |
Clause 6 - Planning
| What to verify | Typical evidence |
|---|
| Risks and opportunities for the AIMS are addressed (6.1.1) | Risk and opportunity register, planning records |
| An AI risk assessment process is defined and applied (6.1.2) | Documented risk methodology (aligned to ISO/IEC 23894), risk criteria, risk register |
| An AI risk treatment process produces a treatment plan and Statement of Applicability (6.1.3) | Risk treatment plan, Statement of Applicability with inclusion/exclusion justification |
| AI system impact assessments are conducted (6.1.4) | AISIA process, completed impact assessments for in-scope systems |
| AIMS objectives are established, measurable and planned (6.2) | Documented AI objectives, KPIs, plans indicating who/what/when/how measured |
| Planning of changes is controlled (6.3) | Change plans, impact-of-change records |
Clause 7 - Support
| What to verify | Typical evidence |
|---|
| Resources for the AIMS are determined and provided (7.1) | Budget, headcount, tooling and infrastructure allocation records |
| Competence of persons doing AI work is ensured (7.2) | Competency matrix, training records, certifications, role requirements |
| Awareness of the AI policy and their contribution is ensured (7.3) | Awareness campaign records, attestation logs, e-learning completion |
| Internal and external communication is planned (7.4) | Communication plan defining what, when, with whom and how |
| Documented information is created, controlled and available (7.5) | Document control procedure, version history, access controls, retention records |
Clause 8 - Operation
| What to verify | Typical evidence |
|---|
| Operational processes are planned, implemented and controlled (8.1) | Operating procedures, control criteria, records of process execution, control of outsourced processes |
| AI risk assessment is performed at planned intervals and on change (8.2) | Dated risk assessment records, triggers for reassessment |
| AI risk treatment is implemented (8.3) | Evidence controls are operating, residual-risk acceptance records |
| AI system impact assessments are performed operationally (8.4) | Completed AISIA records tied to lifecycle stages and changes |
Clause 9 - Performance evaluation
| What to verify | Typical evidence |
|---|
| Monitoring, measurement, analysis and evaluation are performed (9.1) | Metrics dashboards, monitoring records, analysis reports with methods and intervals |
| Internal audits are planned and conducted (9.2) | Audit programme, audit plans, auditor independence, audit reports, findings |
| Management reviews are conducted at planned intervals (9.3) | Management-review minutes covering required inputs and documented decisions/outputs |
Clause 10 - Improvement
| What to verify | Typical evidence |
|---|
| Continual improvement of the AIMS is pursued (10.1) | Improvement register, trend analysis, evidence of enhancements |
| Nonconformities are managed and corrective action taken (10.2) | Nonconformity log, root-cause analyses, corrective action records, effectiveness reviews |
Annex A.2 - Policies related to AI
| What to verify | Typical evidence |
|---|
| An AI policy giving management direction exists and is approved | Approved AI policy document with owner and approval date |
| Topic-specific policies (data, transparency, human oversight) support the AI policy | Suite of subordinate policies cross-referenced to the AI policy |
| AI policies align with other organisational policies (security, privacy, quality) | Cross-mapping showing consistency with ISO 27001/27701 policies |
| Policies are reviewed at planned intervals and on significant change | Review schedule, review sign-off, change history |
Annex A.3 - Internal organisation
| What to verify | Typical evidence |
|---|
| AI roles and responsibilities are defined and allocated | RACI, job descriptions, AI governance charter |
| A mechanism exists to report concerns about AI systems | Whistleblowing/concern-reporting procedure, logged reports and dispositions |
| Segregation of duties for critical AI decisions is considered | Access and approval workflow evidence, dual-control records |
Annex A.4 - Resources for AI systems
| What to verify | Typical evidence |
|---|
| Data resources are identified and documented | Data inventory, dataset catalogue, data resource register |
| Tooling and system resources are documented | Model registry, tooling inventory, environment documentation |
| Computing and human resources are documented | Compute inventory, capacity records, skills/roles allocation |
| Resource documentation is maintained across the lifecycle | Versioned resource documentation, review records |
Annex A.5 - Assessing impacts of AI systems
| What to verify | Typical evidence |
|---|
| A process to assess AI impacts on individuals, groups and society exists | Documented AISIA methodology and criteria |
| Impact assessments consider harms, fairness, and affected parties | Completed impact assessments identifying affected groups and mitigations |
| Impacts are assessed at appropriate lifecycle stages and on change | AISIA records linked to inception, deployment and change events |
| Results are documented and feed risk treatment | Traceability from impact findings to treatment plan entries |
Annex A.6 - AI system life cycle
| What to verify | Typical evidence |
|---|
| Responsible design and development objectives are defined | Design specifications, responsible-AI requirements, acceptance criteria |
| Verification and validation are performed before deployment | Test plans, model evaluation reports, bias/robustness/accuracy test results |
| Deployment is controlled and authorised | Release/change approvals, deployment checklists, rollback plans |
| Operation and monitoring detect drift and performance degradation | Monitoring dashboards, drift-detection alerts, retraining triggers |
| AI systems and lifecycle activities are documented | Model cards, system documentation, data lineage, design records |
| Events are logged to support traceability and investigation | Event/audit logs, inference logs, log retention configuration |
Annex A.7 - Data for AI systems
| What to verify | Typical evidence |
|---|
| Data acquisition is governed and lawful | Data source register, licences/consent, data acquisition procedure |
| Data quality is defined and measured | Data quality criteria, profiling reports, quality metrics |
| Data provenance and lineage are recorded | Lineage diagrams, dataset versioning, provenance metadata |
| Data preparation and handling are controlled | Preprocessing pipelines documentation, labelling QA, transformation records |
Annex A.8 - Information for interested parties
| What to verify | Typical evidence |
|---|
| System documentation is provided to enable proper use | Technical documentation, model cards, intended-use statements |
| Information is provided to users about the AI system | User guidance, disclosures that content/decisions are AI-generated |
| A mechanism exists to report and communicate AI incidents | Incident reporting channel, communication procedure, incident notifications |
| Affected parties can obtain relevant information and redress | Transparency notices, explanation/appeal mechanism records |
Annex A.9 - Use of AI systems
| What to verify | Typical evidence |
|---|
| A responsible-use policy governs deployment and use | Responsible-use policy, acceptable-use rules for AI |
| Objectives for responsible use are defined | Responsible-use objectives tied to fairness, safety and oversight |
| AI systems are used according to intended purpose | Use monitoring, exception logs, misuse detection records |
| Human oversight is provided where required | Human-in-the-loop design records, override logs, escalation paths |
Annex A.10 - Third-party and customer relationships
| What to verify | Typical evidence |
|---|
| Responsibilities across the AI value chain are allocated | Contracts, responsibility allocation matrices, DPAs/AI addenda |
| Suppliers of AI components and data are managed | Supplier due-diligence records, supplier risk assessments, SLAs |
| Customer obligations and information needs are addressed | Customer guidance, contractual obligations, shared-responsibility statements |
| Third-party AI risks feed the organisation's risk assessment | Supplier risk entries reflected in the AI risk register |
Scoping the AIMS
Scoping determines what the AIMS and any certificate will cover. A poorly drawn scope either understates governance (and is rejected by auditors as not credible) or overextends it (and becomes unmanageable). Scope is defined in Clause 4.3 and must consider the external and internal issues, the interested parties, and the interfaces and dependencies between activities performed by the organisation and those performed by other organisations in the AI value chain.
- Enumerate the AI systems in use or under development and classify each by the organisation's role (provider, producer, customer, partner, subject, authority).
- Decide the organisational, physical and technical boundaries: which business units, sites, cloud environments and product lines are included.
- Identify interfaces with third parties (model vendors, data providers, cloud/compute, downstream customers) and how responsibilities are split.
- Justify any exclusions explicitly; blanket exclusion of high-impact AI systems will typically invalidate certification.
- Align the AIMS scope with existing ISO 27001/27701 scopes where they overlap to enable integrated audits.
- Document the scope as a controlled statement referencing the AI systems, roles, boundaries and exclusions.
Scoping tip
Start with an AI system inventory. Many organisations discover far more AI in their estate than expected once they include embedded vendor features, LLM assistants, RPA with ML components and analytics models. You cannot govern what you have not inventoried, so the inventory is the foundation of both scope and risk assessment.
Implementation Approach
A pragmatic ISO 42001 programme runs in phases that mirror the Plan-Do-Check-Act cycle embedded in the standard. CyberSigma typically delivers this over four to eight months depending on organisation size and AI estate complexity, with reuse of any existing ISO 27001 management system to accelerate delivery.
Phase 1 - Initiation and context (Weeks 1-4)
- Activities: secure top-management sponsorship, appoint the AI governance lead, run an AI system inventory, determine AI roles, analyse context and interested parties, and draft the AIMS scope.
- Deliverables: AI system inventory, role determination record, context and stakeholder analysis, draft AIMS scope, project charter and governance structure.
Phase 2 - Risk, impact and design (Weeks 4-10)
- Activities: define the AI risk methodology (aligned to ISO/IEC 23894), perform risk assessment, conduct AI system impact assessments, and select controls to build the Statement of Applicability.
- Deliverables: AI risk methodology, AI risk register, completed AISIAs, risk treatment plan, Statement of Applicability.
Phase 3 - Build and operationalise (Weeks 8-18)
- Activities: author the AI policy and topic-specific policies, implement Annex A controls (data governance, lifecycle controls, transparency, human oversight, supplier management), stand up monitoring and logging, and roll out competence and awareness training.
- Deliverables: AI policy suite, control procedures, model registry and documentation (model cards), monitoring and logging configuration, training records.
Phase 4 - Evaluate, audit and certify (Weeks 16-28)
- Activities: run performance monitoring, conduct the first internal audit, hold a management review, close nonconformities, then engage an accredited certification body for the Stage 1 (documentation) and Stage 2 (implementation) audits.
- Deliverables: internal audit report, management-review minutes, corrective action records, readiness report and certification body engagement leading to the certificate.
Maturity and Capability Model
While ISO 42001 certification is pass/fail against the requirements, CyberSigma uses a five-level capability model to benchmark readiness, prioritise remediation and communicate progress to boards. Certification readiness generally requires operating at Level 3 or above across all clauses and applicable controls.
| Level | Name | Characteristics | Certification readiness |
|---|
| Level 1 | Initial / ad hoc | AI used without governance; no inventory, policy or risk assessment; reliance on individuals | Not ready |
| Level 2 | Developing | Some policies drafted; partial AI inventory; risk assessment inconsistent; controls not embedded | Significant gaps |
| Level 3 | Defined | AIMS documented; risk and impact assessments performed; Annex A controls implemented and operating | Certification-ready |
| Level 4 | Managed | Controls measured with KPIs; monitoring and drift detection active; internal audit and management review mature | Strong certification position |
| Level 5 | Optimising | Continual improvement is data-driven; AI governance integrated with enterprise risk; predictive assurance | Exemplary / best practice |
Assessment and Audit Approach
Certification follows the standard accredited-audit model. Internal readiness assessments by CyberSigma mirror the same steps so there are no surprises at the certification audit.
- Scoping and readiness review: confirm the AIMS scope, AI roles and inventory, and assess documentation completeness.
- Gap analysis: assess each Clause 4-10 requirement and each applicable Annex A control against evidence, producing a gap register.
- Risk and impact validation: verify the AI risk assessment, treatment plan, Statement of Applicability and completed impact assessments are coherent and current.
- Control testing: sample-test operating effectiveness of implemented controls (data governance, lifecycle, transparency, oversight, supplier management).
- Internal audit and management review: confirm these have run, covered required inputs and produced documented outputs and actions.
- Nonconformity remediation: track corrective actions to closure with root-cause analysis and effectiveness checks.
- Stage 1 audit (certification body): documentation and readiness review against the standard.
- Stage 2 audit (certification body): on-site/remote assessment of implementation and effectiveness, leading to certification decision.
- Surveillance and recertification: annual surveillance audits and a full recertification at the three-year mark.
Evidence Request List
The following categorised list captures the documents and records an assessor will request. Assembling these into an evidence pack before the audit dramatically shortens the assessment.
- Governance and leadership: AI policy, governance charter, RACI matrix, top-management commitment records, board/steering-committee minutes.
- Context and scope: context analysis, interested-party register, AI role determination, AIMS scope statement.
- Risk and impact: AI risk methodology, AI risk register, risk treatment plan, Statement of Applicability, completed AI system impact assessments.
- Data governance: data inventory, dataset catalogue, data quality reports, provenance/lineage records, consent and licensing evidence.
- Lifecycle and models: model registry, model cards, design specifications, verification/validation and bias/robustness test reports, deployment approvals.
- Operations and monitoring: monitoring dashboards, drift-detection and retraining records, event/audit logs, incident register.
- Transparency: user disclosures, intended-use statements, explanation and redress mechanism records.
- Third parties: supplier due-diligence and risk assessments, contracts/DPAs with AI clauses, shared-responsibility statements.
- Competence and awareness: competency matrix, training and certification records, awareness attestations.
- Assurance: internal audit programme and reports, management-review minutes, nonconformity and corrective-action records, KPI reports.
Roles and Responsibilities
| Role | Responsibilities |
|---|
| Top management / Board | Own the AI policy, provide resources, set risk appetite, approve scope, review AIMS performance |
| AI Governance Officer / AIMS Manager | Run the AIMS day to day, maintain risk register and SoA, coordinate audits and reviews |
| Data Science / ML Engineering lead | Implement lifecycle controls, verification/validation, model documentation and monitoring |
| Data governance / Data owner | Ensure data quality, provenance, lawful acquisition and preparation controls |
| CISO / Information Security | Integrate AI risks with security controls, secure AI infrastructure and logging |
| DPO / Privacy | Ensure DPDP/GDPR alignment, data-subject rights and privacy impact for AI |
| Legal and Compliance | Map regulatory obligations (EU AI Act, DPDP), manage contracts and value-chain responsibilities |
| Internal Audit | Independently audit the AIMS and report to management |
| Business / product owners | Define intended use, ensure responsible use, own human oversight in operations |
KPIs to Track
- Percentage of AI systems in the inventory with a completed and current impact assessment.
- Percentage of applicable Annex A controls implemented and operating effectively.
- Number and ageing of open AI risks by severity, and residual risk within appetite.
- Model performance and drift metrics against thresholds, and number of drift-triggered retrains.
- AI incident count, mean time to detect and mean time to respond.
- Data quality metrics for training and production datasets (completeness, accuracy, bias indicators).
- Percentage of relevant staff completing AI governance competence and awareness training.
- Number of nonconformities from internal and external audits, and average time to close.
- Supplier AI risk assessments completed as a percentage of AI suppliers.
- Percentage of high-impact AI decisions with documented human oversight.
Readiness Checklist
- Top-management sponsorship secured and AI governance lead appointed.
- Complete AI system inventory produced and maintained.
- Organisation's AI roles determined for each system.
- Context, interested parties and AIMS scope documented and approved.
- AI policy and topic-specific policies approved and communicated.
- AI risk methodology defined and risk assessment completed.
- AI system impact assessments completed for all in-scope systems.
- Risk treatment plan and Statement of Applicability produced.
- Annex A controls implemented, including data governance, lifecycle, transparency, human oversight and supplier management.
- Monitoring, logging and drift detection operational.
- Competence and awareness training delivered and recorded.
- Internal audit conducted and findings addressed.
- Management review held with documented outputs.
- Nonconformities closed with corrective action and effectiveness verified.
- Evidence pack assembled and certification body engaged.
Common Gaps
- No comprehensive AI inventory, so shadow and embedded AI escapes governance and scope.
- Treating ISO 42001 as an extension of ISO 27001 and omitting AI-specific concerns like bias, transparency and societal impact.
- AI system impact assessments missing, superficial, or not repeated on significant change.
- Statement of Applicability that excludes controls without credible justification, especially for high-impact systems.
- No model documentation (model cards) or data lineage, breaking traceability and V&V evidence.
- Human oversight designed on paper but no override logs or escalation evidence in operation.
- Weak supplier and value-chain governance; third-party model and data risks not assessed.
- No drift or performance monitoring after deployment, so models degrade unnoticed.
- Policies not aligned or duplicated across security, privacy and AI, creating contradictions.
- Internal audit and management review skipped or lacking required inputs and documented outputs.
ISO 42001 Mapped to Other Frameworks
| ISO 42001 area | EU AI Act | NIST AI RMF | ISO/IEC 27001 | ISO/IEC 23894 |
|---|
| AI policy and governance (Clause 5, A.2/A.3) | Governance and accountability obligations | Govern function | Clause 5 leadership, A.5 policies | Risk governance |
| Risk assessment and treatment (Clause 6, 8) | Risk management system for high-risk AI | Map and Measure functions | Clause 6 planning, risk treatment | Core AI risk process |
| Impact assessment (A.5) | Fundamental rights impact assessment | Map (context and impacts) | DPIA linkage via A.18/27701 | Impact and consequence analysis |
| Data governance (A.7) | Data and data governance requirements | Map/Measure data quality | A.8 asset and data controls | Data-related risk sources |
| Lifecycle, V&V and monitoring (A.6) | Technical documentation, accuracy, robustness, post-market monitoring | Measure and Manage functions | Change and operations controls | Lifecycle risk treatment |
| Transparency and information (A.8) | Transparency and information to users | Govern/Manage transparency | Communication controls | Communication of risk |
| Human oversight (A.9) | Human oversight requirement | Manage (human factors) | Access and operational controls | Oversight controls |
| Third-party and value chain (A.10) | Provider/deployer obligations along the chain | Govern (third-party risk) | A.5.19-A.5.22 supplier controls | Third-party risk sources |
How CyberSigma helps
CyberSigma is a CERT-In empanelled cybersecurity and compliance partner with deep management-system experience across ISO 27001, ISO 27701 and now ISO/IEC 42001. Our AI governance practice delivers the full journey: AI system discovery and inventory, AIMS scoping and role determination, AI risk and impact assessments aligned to ISO/IEC 23894, Annex A control implementation, policy authoring, monitoring and drift-detection setup, evidence-pack preparation, internal audit and pre-certification gap assessment, and support through the accredited Stage 1 and Stage 2 audits. Where you already hold ISO 27001, we reuse your management system to accelerate certification and run integrated audits. Talk to CyberSigma to build an AI Management System that satisfies auditors, regulators and your board while making your AI genuinely trustworthy.
