AI Governance Frameworks Compared

Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser

This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.

These six instruments get presented as a logo wall, as though they were six flavours of the same thing. They are not. One is legislation that applies whether or not you adopt it. Two are management-system standards certified by an accredited body against your organisation. Two are voluntary frameworks that confer no obligation. One is an attestation regime in which a CPA firm reports on your controls. Confusing them produces concretely wrong decisions, so this page separates them first and compares them second.

FrameworkWhat it isVersionCan you be certified?
EU AI Act
European Parliament and Council of the European Union
RegulationRegulation (EU) 2024/1689No — enforcement, not certification
ISO/IEC 42001
ISO/IEC
Certifiable standard2023Yes — by an accredited body, against your organisation
ISO/IEC 27001
ISO/IEC
Certifiable standard2022Yes — by an accredited body, against your organisation
NIST AI RMF
National Institute of Standards and Technology (U.S. Department of Commerce)
Voluntary framework1.0No — voluntary guidance
CSA AICM
Cloud Security Alliance
Voluntary framework1.1No — voluntary guidance
SOC 2
American Institute of Certified Public Accountants (AICPA)
AttestationTrust Services Criteria (2017, as revised)No — a CPA firm issues a report, not a certificate

The most common mistake in AI governance procurement is treating these as substitutes. They are not, and the differences are structural rather than a matter of emphasis:

You cannot opt out of a regulation. The EU AI Act applies to systems in its scope regardless of whether you have adopted anything. Nothing else on this page has that property.

You cannot be certified against a regulation. Certification is something an accredited body does against a standard. There is no "EU AI Act certificate", from us or anyone else, and a vendor offering one is describing something that does not exist.

A management-system standard certifies your organisation, not your model. ISO/IEC 42001 and ISO/IEC 27001 describe systems an organisation operates. "This model is ISO 42001 compliant" is a category error in the same family as "this laptop is ISO 9001 certified".

An attestation is an opinion about a defined scope over a defined period. A SOC 2 report tells you what an auditor tested and what exceptions they found. It does not tell you the organisation passed, because there is no pass mark.

Voluntary guidance is genuinely voluntary. NIST AI RMF and CSA AICM confer nothing and require nothing. That is their strength — no certification theatre — and their weakness, in that a document with no deadline attached tends not to get revisited.

What they have in common is the underlying work. A team that writes down an intended purpose, assesses risk, governs its data, defines human oversight, logs what happens and monitors the result is doing most of what all six ask for. That is why this tool keeps a canonical control layer and maps out of it, rather than maintaining six parallel checklists that would say the same thing six times.

Legal obligation

Applies to you whether or not you adopt it.

EU AI Act Regulation — applies whether or not you adopt it

  • Version Regulation (EU) 2024/1689
  • Publisher European Parliament and Council of the European Union
  • In force 2024-08-01
  • Last verified 2026-09-13

The European Union's horizontal AI law. It regulates AI systems by their intended purpose and the risk that purpose creates — not by model size, architecture or where the model runs. It bans a short list of practices outright (Article 5), defines two routes into the high-risk tier (Article 6), attaches transparency duties to certain systems regardless of tier (Article 50), and splits obligations between providers, deployers, importers and distributors.

What this tool does not do

  • This tool performs a readiness assessment, not a conformity assessment. Conformity assessment under the Act is a formal procedure, and for some high-risk systems it involves a notified body.
  • Classification under Articles 5 and 6 turns on facts about intended purpose and real-world use that a questionnaire cannot establish. Where the answers are ambiguous the result is MANUAL REVIEW, not a verdict.
  • We do not assess the general-purpose AI model obligations that sit with model providers (Chapter V). Those rest with the organisation that trains and releases the weights.
  • Nothing here is legal advice, and no output of this tool has any standing before a market surveillance authority.

Official source ↗

Read the EU AI Act page →

Certifiable management systems

Audited by an accredited body against your organisation, not your model.

ISO/IEC 42001 Certifiable standard — audited against your organisation

  • Version 2023
  • Publisher ISO/IEC
  • Last verified 2026-09-13

The first management-system standard for artificial intelligence. ISO describes it as specifying requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS) within an organisation. Its subject is the ORGANISATION — its policies, roles, risk process, lifecycle controls and improvement loop — not any individual model or deployment.

What this tool does not do

  • ISO/IEC 42001 certifies an organisation's management system through an accredited certification body. A model, a deployment, or an assessment produced here cannot be "ISO 42001 compliant".
  • The standard's control text is copyrighted and sold by ISO. This tool stores control identifiers and our own short descriptions, never the published wording.
  • Our mapping shows where a deployment-level control relates to an organisational clause. Relating is not satisfying: an implemented technical control does not discharge a management-system requirement on its own.

Official source ↗

Read the ISO/IEC 42001 page →

ISO/IEC 27001 Certifiable standard — audited against your organisation

  • Version 2022
  • Publisher ISO/IEC
  • Last verified 2026-09-13

The established information-security management-system standard, with its control set in Annex A. It is in scope for AI deployments because most of what an AI system needs — access control, logging, cryptography, supplier management, incident response — is ordinary information security applied to a new kind of asset.

What this tool does not do

  • Certification is issued by an accredited body against the organisation's scoped management system, not against a deployment.
  • Annex A control text is copyrighted. Identifiers and our own descriptions only.
  • An AI deployment raises risks (training-data provenance, model theft, prompt injection) that ISO/IEC 27001 does not address directly — which is what ISO/IEC 42001 and CSA AICM are for.

Official source ↗

Read the ISO/IEC 27001 page →

Voluntary frameworks and attestation

Adopted by choice, or reported on by an auditor you engage.

NIST AI RMF Voluntary framework — no obligation, no certification

  • Version 1.0
  • Publisher National Institute of Standards and Technology (U.S. Department of Commerce)
  • Last verified 2026-09-13

A voluntary framework NIST published to help organisations manage risks across the AI lifecycle. It is organised around four core functions — GOVERN, MAP, MEASURE and MANAGE — with GOVERN cutting across the other three. NIST also publishes a Generative AI Profile as a companion, applying the core to generative systems specifically.

What this tool does not do

  • The framework is voluntary. It creates no obligation and there is no certification against it.
  • AI RMF 1.0 is the version this tool maps to, and NIST has signalled a revision. Our mapping records the version it was written against; treat a mapping to a superseded version as stale until re-verified.
  • The AI RMF describes outcomes rather than prescribing implementations, so a mapping from a specific technical control to a category is interpretive by nature and is labelled accordingly.

Official source ↗

Read the NIST AI RMF page →

CSA AICM Voluntary framework — no obligation, no certification

  • Version 1.1
  • Publisher Cloud Security Alliance
  • Last verified 2026-09-13

A control framework for securing and governing AI systems, built in the lineage of CSA's Cloud Controls Matrix. CSA describes AICM v1.1 as comprising 247 control objectives across 18 security domains, with published mappings to the major AI governance frameworks including ISO/IEC 42001, ISO/IEC 27001 and the EU AI Act.

What this tool does not do

  • CSA publishes AICM under its own terms. This repository stores control identifiers, our own short descriptions and mapping metadata — not CSA's control text.
  • We map a deliberately small subset of AICM relevant to single-deployment LLM inference. The full matrix is far broader, covering model development and cloud-provider responsibilities this tool does not assess.
  • AICM is not an audit standard and confers no certification.

Official source ↗

Read the CSA AICM page →

SOC 2 Attestation — a CPA firm reports on your controls

  • Version Trust Services Criteria (2017, as revised)
  • Publisher American Institute of Certified Public Accountants (AICPA)
  • Last verified 2026-09-13

An attestation engagement in which an independent CPA firm reports on a service organisation's controls against the Trust Services Criteria: security (the common criteria), and optionally availability, processing integrity, confidentiality and privacy. A Type I report addresses design at a point in time; a Type II report addresses operating effectiveness over a period.

What this tool does not do

  • SOC 2 is an attestation performed by a licensed CPA firm. There is no "SOC 2 certification", and no tool can produce a SOC 2 report.
  • The Trust Services Criteria are AICPA material. We store criterion identifiers and our own descriptions only.
  • Our mapping points at the common criteria most often relevant to an AI deployment. Your auditor defines the actual scope, and a control we flag may sit outside it.

Official source ↗

Read the SOC 2 page →

Frequently asked questions

Which framework should we adopt first?
If you deploy AI in the EU, the AI Act is not a choice — start by classifying your systems under Article 6, because everything else depends on the answer. Beyond that it depends on why you are asking. If a customer is demanding evidence, ISO/IEC 42001 or SOC 2 depending on which they asked for. If you want a thinking structure for your own team, NIST AI RMF, because it is free, readable and does not pretend certainty. If your concern is specifically AI security, CSA AICM.
Can certification against one satisfy another?
Generally no, and assuming otherwise is expensive. A harmonised-standards route exists under the AI Act — conformity with harmonised standards published in the Official Journal confers a presumption of conformity with the requirements they cover — but that is a specific legal mechanism attached to specific listed standards, not a general principle that certification counts. Check what is actually listed rather than assuming your existing certificate carries over.
Why does this tool map to a canonical control layer instead of directly between frameworks?
Because direct framework-to-framework mappings imply equivalence between instruments that are not equivalent, and because the number of pairs grows quadratically. Mapping each framework to a shared internal control layer means one edge per framework per control, and it forces every relationship to state its own type and confidence — direct, strong, partial, conceptual, or a structural gap where the target framework genuinely has nothing.
What is a structural gap in your mappings?
A recorded finding that a framework has no control addressing something. The clearest example: ISO/IEC 27001:2022 has nothing covering prompt injection, and secure coding is the nearest neighbour without being close. Forcing that mapping would tell a reader they are covered when they are not, so we record the gap instead. A mapping database that never says "nothing here" is not being careful.

Keep going