They should run the two tracks together. ISO 42001 can structure governance, evidence, and accountability, but it does not remove legal obligations under the EU AI Act. The practical choice is to use certification work to populate the technical documentation and oversight artefacts that regulation will still require.
Should ISO 42001 and EU AI Act work be sequenced or run in parallel?
Teams should not treat this as an either-or sequence. ISO 42001 is a management system that helps define ownership, controls, evidence, and review cadence, while the eu ai act is a legal and regulatory obligation. The safest operating model is to run both tracks together so governance work produces artefacts that can support compliance without delaying the legal track.
That parallel approach matters because certification work often creates the same core outputs the regulatory programme will need anyway: inventory, risk treatment, documented responsibilities, change control, internal review, and retained evidence. If teams wait for one workstream to finish before starting the other, they usually duplicate analysis, delay documentation, and discover too late that governance language does not yet satisfy legal traceability requirements.
Practically, the deciding question is not “which one comes first?” but “which deliverables can be shared without losing compliance precision?” Where the same control, record, or decision supports both, build it once and make it strong enough for the stricter obligation. Where the EU AI Act requires a specific legal artefact, keep that requirement explicit rather than assuming ISO 42001 alone will cover it.
Where the two programmes overlap, and where they do not
ISO 42001 is useful because it provides the operating rhythm for AI governance, including accountability, policy, review, documentation, and continuous improvement. That makes it a good container for organising the work. The EU AI Act, however, is the external rule set, so legal classification, role allocation, technical documentation, and conformity-related obligations must be tracked as explicit compliance tasks, not as incidental by-products of certification.
The overlap is strongest in areas such as governance structure, risk assessment, evidence retention, oversight, and traceability. Teams can often use the same underlying facts, records, and decisions in both programmes. The difference is that certification asks whether the management system is coherent and repeatable, while regulation asks whether the system meets statutory duties for the AI use case in question.
That distinction is why sequencing should be governed by dependency, not by prestige. If a deliverable is foundational to both, start it immediately. If a deliverable is only needed for one track, do not hold the other track hostage while waiting for it. In practice, the most efficient path is to create a single evidence backbone and then map it to the separate ISO and EU AI Act obligations.
How to choose the work order without creating rework
Start with a joint gap assessment that identifies which AI systems are in scope, which legal obligations attach, and which management-system controls already exist. From there, prioritize the artefacts that unblock both tracks at once: system inventory, governance ownership, documented risk treatment, approval records, monitoring responsibilities, and evidence retention. This gives the legal team and the certification team a shared source of truth.
A Agentic AI Compliance Guide is useful here because it shows how AI governance, audit evidence, and regulatory obligations can be organised together without collapsing them into one requirement set. For teams that also need broader identity and access governance around automated systems, Ultimate Guide to NHIs , Regulatory and Audit Perspectives is a useful companion for structuring evidence, ownership, and auditability.
Use the certification track to harden the operating model, but keep a separate checklist for the legal minimums that certification does not define. The practical test is simple: if a record would be questioned by a regulator, it needs to be written as a compliance artefact, not just as an internal governance note.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF sets the technical controls, while ISO/IEC 42001:2023, EU AI Act and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | AI management system | The question is about sequencing AI governance work and certification. |
| Recommendation — Use the AI management system to organise ownership, evidence, and review cadence. | ||
| EU AI Act | AI regulatory obligations | The question asks how work should be sequenced against EU AI Act obligations. |
| Recommendation — Track legal obligations separately and ensure compliance deliverables are completed on time. | ||
| NIST AI RMF | AI Risk Management Framework | AI governance and risk treatment are central to the workstream overlap. |
| Recommendation — Align risk governance, documentation, and accountability to the AI risk lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | The question concerns governance structure and documented accountability across programmes. |
| Recommendation — Translate shared governance into documented policy, ownership, and evidence controls. | ||
Practitioner Guidance
What to prioritise: Build one control and evidence backbone first, then map it to both ISO 42001 and the EU AI Act. The fastest path is usually inventory, ownership, risk classification, and documentation, because those are the artefacts most likely to be reused across both tracks.
What to verify: Check that each shared artefact still answers the stricter question. A good governance record is not automatically a sufficient compliance record if it does not support the required legal traceability, classification, or accountability statement.
Common mistake: Treating ISO 42001 certification as a proxy for regulatory readiness. Certification can improve discipline and evidence quality, but it does not remove the need to assess the AI Act obligations directly and keep them visible in the programme plan.
Practitioner takeaway: Run the programmes in parallel, not in series, and use ISO 42001 to strengthen the evidence model while the EU AI Act defines the legal floor.
Related resources from NHI Mgmt Group
- How should security teams build one control library for EU AI Act, NIST AI RMF, and ISO 42001 compliance?
- How should security teams sequence NIST AI RMF, ISO 42001, and the EU AI Act in an enterprise program?
- How should security teams decide whether a cheaper AI model is worth using for cyber work?
- How do teams decide whether to optimise AI workloads or invest in greener infrastructure first?