ISO/IEC 42001, SOC 2 and NIST AI RMF: Which One Your Buyer Is Actually Asking For

Three names come up in nearly every AI procurement conversation — ISO/IEC 42001, SOC 2 and the NIST AI Risk Management Framework — and they are routinely treated as three grades of the same thing. They are not. One certifies an organisation, one is an auditor's opinion about controls over a window of time, and one is a method with nothing to issue at all. Knowing which is which is usually the difference between a six-figure programme and a two-week piece of work.

None of the three tells you whether a model behaves acceptably on your population. That is worth saying at the top, because it is the assumption underneath most of the confusion, and the rest of this article is in some sense a long footnote to it.

The short version

1. ISO/IEC 42001 certifies the organisation, not the model

ISO/IEC 42001 specifies requirements for an AI management system: the governance, roles, controls and continual improvement around how an organisation builds and runs AI.

The shorthand "ISO 27001 for AI" is more useful than it first sounds. Like an information-security management system, an AI management system says nothing about whether any particular model is good. It asks whether the organisation has a repeatable way of identifying AI risk, assigning ownership for it, and reviewing decisions as things change — and whether it followed that way the last time something actually changed.

In practice an assessment walks a handful of concrete artefacts: a documented AI policy, a risk methodology applied to each system in scope, defined roles for who signs off before a model ships, and evidence that the process was followed. It is a management-systems audit, closer to a paperwork trace than to a red-team exercise.

The gap we see most often is not a missing policy — nearly every organisation can produce one. It is a policy that does not match how a model was actually approved six months ago. An assessor asks for one specific example and traces it end to end. Where the paper trail and the policy disagree, the paper trail is the finding.

2. SOC 2 is an opinion about controls, over a window

SOC 2 is an attestation: a licensed CPA firm's opinion on whether a service organisation's controls were suitably designed (Type I), and whether they operated effectively across a review period, typically six to twelve months (Type II).

The word doing the damage is "compliant". When a vendor says "we're SOC 2 compliant", two follow-up questions decide whether that sentence carries any information at all: Type I or Type II, and which Trust Services Criteria? SOC 2 is modular. A report can cover security alone, or security plus availability, confidentiality, processing integrity and privacy. The badge on the website does not say which, and the difference between a Type I on security and a Type II across five criteria is roughly the difference between a plan and a year of evidence.

For an AI vendor, a SOC 2 can legitimately cover access control around training data, change management for model deployments, and incident response. It does not mean any independent party evaluated whether the model is accurate, fair, or fit for the decision you are about to point it at.

If a lending, hiring or clinical decision touches a vendor's model, a security-scoped SOC 2 is silent on the thing you actually need to know — whether the model performs consistently across the people it decides about. That is a model-level question and it takes a model-level examination.

Ask for the report, not the badge, and read the scope section first. It is usually one paragraph, and it tells you exactly what was and was not tested.

3. NIST AI RMF is a method, and there is nothing to hold up

The NIST AI Risk Management Framework organises AI risk work into four functions — Govern, Map, Measure and Manage — and issues no certificate of any kind.

Because it is voluntary, it gets read as the lightweight option. It is the opposite: it is one of the more demanding structures available, and it is demanding precisely because nothing external forces the cycle to run.

Govern is the foundation and the one most often skipped. Who is accountable for AI risk, is that accountability written down, and can someone raise a concern about a model before it ships without it costing them? Everything else assumes Govern is in place.

Map is context: what this system is for, who it affects, and what could go wrong for those specific people rather than for AI in the abstract. Measure applies real testing to the risks Map identified, quantitative and qualitative both. Manage is the decision — mitigate, transfer, avoid or accept — and the record of who made it.

The cycle repeats as a model, its data or its deployment context changes; it is not completed at launch. In financial services that maps onto existing model-risk practice under supervisory guidance cleanly enough that the AI RMF reads as an extension of a model governance function rather than a parallel one.

4. What none of the three tells you

All three are about arrangements. None of them is about behaviour.

An organisation can hold an ISO/IEC 42001 certificate, a Type II SOC 2 across five criteria and a mature AI RMF practice, and still be running a model that performs materially worse for one group of applicants than another. Nothing in that stack would necessarily surface it, because none of those exercises runs the model against the population it decides about and looks at the distribution of the results.

That is the gap an AI audit exists to close, and it is why the standards and the audit are complements rather than alternatives. The standards ask whether you have a process. The audit asks what your system did.

5. Which one to reach for

The honest answer is that it depends entirely on who is asking, so start there rather than with the standards.

• A security questionnaire is blocking a deal. SOC 2, and check what your buyer's questionnaire actually maps to before scoping the criteria.
• Procurement named ISO/IEC 42001. Then it is ISO/IEC 42001, and the useful first move is a gap assessment rather than an engagement with a certification body — most of the cost is in the remediation, not the certificate.
• A regulator, a board or a partner bank is asking how you manage AI risk. NIST AI RMF gives you the structure to answer in, and no certificate to wait for.
• Nobody has asked yet, and you want the machinery. Build against the AI RMF and treat ISO/IEC 42001 as the blueprint. Both are worth following whether or not you ever certify.

If more than one applies, the sequence that wastes least is usually: get the governance arrangement working first, evidence it second, certify it third. Certifying a process nobody follows produces a certificate and a finding.

6. What we can do against these, and what we cannot

iDharma audits AI systems. It is not an accredited certification body, and the distinction is not a technicality.

ISO/IEC 42001, ISO/IEC 27001, SOC 2 and PCI-DSS are certification and attestation schemes: only an accredited certification body or a licensed assessor can issue the certificate or sign the report. What we do against those four is a readiness assessment — we assess your readiness against the standard and prepare the evidence and gap list the body will ask you for. The certificate comes from them.

Against the rest — the EU AI Act, the NIST AI RMF, GDPR, sector model-risk guidance — the work is an audit, and the judgement is ours to make and ours to sign. Which is which for every instrument we cover is marked on the framework catalog, read off a single field rather than decided page by page.

Three questions worth asking

Which of these has someone actually asked us for, by name, in writing? Standards programmes started without an answer to this tend to end without one.

If we hold one already — what was in its scope? Not the badge; the scope paragraph. Most people who rely on a SOC 2 have never read the one they rely on.

What would any of these have caught about how our model actually behaves? If the answer is nothing, that is not an argument against the standard. It is the argument for pairing it with something that examines the system.