The NIST AI Risk Management Framework and ISO/IEC 42001 are cited as alternatives in vendor materials and procurement questionnaires. They are not alternatives. One is voluntary guidance applied to a system in its deployment context; the other is a certifiable management-system standard applied to an organisation.
The framework
AI RMF 1.0, published January 2023, organises risk work into four functions: GOVERN, MAP, MEASURE, and MANAGE. GOVERN cuts across the other three rather than preceding them. The framework states explicitly that its actions are not a checklist and need not be performed in order, and describes an iterative process running through the lifecycle.
Its outcomes are the useful part. The core includes evaluating risk in the deployment context, documenting risks that were not measured, deciding whether development or deployment should proceed, documenting residual risk, and assigning responsibility for disengaging systems. None of those produces a score or a pass threshold, and the absence of one is deliberate.
The generative AI profile, published July 2024, adds the cautions that matter for language systems: evaluate capability claims empirically, avoid extrapolating from narrow or anecdotal assessments, and verify generated sources and citations during pre-deployment measurement and ongoing monitoring. It also acknowledges limits in estimating these risks at all.
NIST reports that the framework is being revised. A revision announcement is not a successor document, and the January 2023 baseline remains the inspected text.
The management system
ISO/IEC 42001:2023 is a management-system standard for establishing, operating, and improving an organisation’s management of AI, structured around a plan-do-check-act cycle. The catalogue description distinguishes organisational policies and procedures from the details of individual AI applications, and that distinction is the whole practical point.
Certification is performed by external certification bodies. ISO does not issue certificates, certification and accreditation are different things, and the status of an accredited certificate can be verified through the issuer.
So a supplier holding a 42001 certificate has evidence that some defined organisational scope runs a management process. Whether the system being handed to you sits inside that scope is a question the certificate does not answer, and it is the question worth asking.
The two columns that stay separate
An organisational claim and an application claim answer different things, and a transfer review needs both.
The organisational questions are which entity, activities, sites, and interfaces the asserted scope includes; who owns risk decisions and ongoing review; what competence and corrective-action evidence supports the process; and what certificate, issuer, scope, and current status can actually be verified.
The application questions are whether this deployment and its use fall inside that scope; who can monitor, override, and stop this particular service; whether the recipient can interpret this system’s tests, limitations, and incidents; and what deployment-specific evidence supports the acceptance decision.
A broad governance claim from a supplier stays unverified until the scope statement and certificate are in hand and mapped against the transfer. Neither document supplies a measured benefit, a cost saving, or a reduced error rate, and the public explanatory material’s suggested benefits are not results.
The rule
What stays fixed is the object each instrument addresses: a system in context, or an organisation running a process. What changes is which one your counterparty is presenting, and the recurring procurement error is accepting evidence about the organisation as evidence about the system.
Where the framing fails
The framework becomes a gate list. Converting four iterative functions into sequential approval stages produces a process that files documents at fixed points and stops re-examining anything. The framework’s own non-checklist language is the direct contradiction, and the loss is the iteration: unmeasured risks are supposed to stay visible, not be cleared once.
An empty field becomes a favourable score. Where a risk cannot currently be measured, the honest record keeps the gap and names who owns it. Converting unmeasurable into acceptable is how residual-risk documentation turns into a formality.
One source is counted twice. A framework’s PDF and its online core are one intellectual source. Citing both as corroboration inflates the evidence base for a position neither independently supports.
Not to be confused with
Supervisory guidance. Neither instrument is banking supervision, and neither settles whether a US bank’s application falls within model risk management.
A product certificate. Nothing here certifies that a system works, is accurate, or is safe to deploy. Both instruments are about how decisions get made and recorded.