The security questionnaire used to ask about SOC 2. Now it often has a section on AI: how do you identify AI risks, who approves new models, how do you monitor them? Two frameworks dominate the answers, and they are often presented as alternatives. They aren't.
Two different kinds of thing
| NIST AI RMF | ISO/IEC 42001 | |
|---|---|---|
| What it is | A voluntary framework for managing AI risk | A standard for an AI management system |
| Structure | Four functions: govern, map, measure, manage1 | Management system clauses plus AI-specific controls2 |
| Certification | None; you use it | Certifiable by accredited bodies |
| Strength | Practical risk thinking across the AI lifecycle | Repeatable governance with audit and continual improvement |
| Typical audience | Internal teams, US government and buyers | Enterprise customers and international markets wanting assurance |
A common way to put it: the NIST framework is something you use, while ISO/IEC 42001 is something you certify against4. Commentators note that ISO's management-system elements, such as internal audit, management review and continual improvement, have no direct equivalent in the NIST framework3.
They map onto each other
NIST's AI Resource Center hosts a crosswalk between the AI RMF and ISO/IEC 42001. Commentators point out that it was contributed by the community rather than written by NIST, and that inclusion doesn't imply endorsement35. Informally, the four NIST functions line up with ISO's leadership and policy, context and impact assessment, monitoring, and review and improvement activities3. Treat such mappings as starting points rather than proof of coverage.
Use NIST to decide what to do about AI risk. Use ISO/IEC 42001 to prove you do it consistently. They answer different questions.
How I'd sequence them
- Start with an AI system register. Every framework, and every regulation, begins with knowing which AI systems you have, what they do and who owns them.
- Apply the NIST functions to your highest-risk systems first. Map context and impacts, measure with real evaluations, manage with controls and incident response.
- Build the evidence as you go: evaluation results, approval records, incident postmortems, training records. These are what auditors and customers ask for.
- Add the management system when customers or markets ask for certification: policy, roles, internal audit, management review.
- Map once to many. The same controls support the EU AI Act, SOC 2 and Gulf regimes such as DIFC Regulation 10.
Where engineering carries the load
Frameworks fail when they live only in documents. The controls that hold up in an audit are the ones built into systems: a model gateway that enforces approved models and logs every call, evaluation pipelines that gate releases as in evaluating AI agents, incident handling as in AI incident postmortems, and role-based training as in AI literacy. Build those and the paperwork follows; write the paperwork alone and it drifts from reality within months.
How I can help
I help AI companies build governance that satisfies enterprise buyers and regulators, with the controls engineered into the platform. As a fractional CTO I can own the programme. Or analyse your challenge and bring the result to a call.
- 1AI Risk Management FrameworkUS National Institute of Standards and Technology
- 2
- 3NIST AI RMF vs ISO/IEC 42001 crosswalkSubstack commentary
- 4NIST AI RMF or ISO 42001?BalancedSec
- 5