A compliance team at a large regulated firm described their year to me like this: three separate workstreams, three separate spreadsheets, three separate sets of evidence requests, and a growing suspicion that they were doing the same work three times. They were right. The EU AI Act, the NIST AI Risk Management Framework, and ISO/IEC 42001 are different instruments with different legal weight and different vocabularies. Underneath, they keep asking for the same handful of things. Govern your AI. Assess its risks and impacts. Keep humans in the loop. Log what it does. Manage your data and your vendors. Improve when something breaks.
If three frameworks circle the same underlying controls, then implementing a control once and mapping it to all three should answer the same obligation three times. That is the whole idea behind cross-walk mapping, and for an enterprise carrying all three obligations at once it is the difference between a sustainable program and a permanent fire drill. This post explains why the overlap exists, where it breaks down, what auditors actually want from a mapping, and how to build one that holds up under board-level scrutiny.
The requirement: three frameworks, one underlying reality
Start with what each instrument is, because the differences are real and you cannot map well if you pretend they are identical.
The EU AI Act is law. It is risk-tiered: unacceptable-risk practices are prohibited, high-risk systems carry the heaviest obligations, and certain systems carry transparency duties. For high-risk systems it requires, among other things, a risk management system, data governance, technical documentation, automatic record-keeping (logging), transparency to users, human oversight, and accuracy, robustness, and cybersecurity measures. It carries penalties and conformity-assessment requirements. For systems in scope, it is not optional.
The NIST AI RMF is a voluntary US framework organized around four functions, Govern, Map, Measure, and Manage, that together describe how to identify, assess, and treat AI risk across a system's lifecycle. It is guidance rather than law, and it is deliberately non-prescriptive: it names the outcomes to achieve, not the exact control to deploy.
ISO/IEC 42001:2023 is the certifiable AI management system standard, built on Annex SL, with management clauses 4 to 10 and 38 Annex A controls under nine objectives (A.2-A.10). Of the three, it is the one you can be independently certified against.
Now take a single concrete obligation: human oversight of AI systems. The EU AI Act requires it explicitly for high-risk systems. The NIST AI RMF reaches it through the Manage function and human-AI configuration considerations. ISO/IEC 42001 covers it under control A.9 (Use of AI systems) and the responsible-use principles in the management clauses. Three frameworks, three citations, one control: a human approval gate on consequential AI actions, with a record that it operated. Implement that gate once, capture its evidence once, and you have material that responds to all three.
The same holds across the board. Logging and record-keeping maps to the EU AI Act's automatic-logging requirement, NIST's Measure and Manage monitoring expectations, and 42001's clause 9 and lifecycle controls. Data governance maps to the AI Act's data-governance article, NIST's Map and Measure data considerations, and 42001's A.7. Risk and impact assessment maps to the AI Act's risk management system, NIST's Map function, and 42001's clause 6 with control A.5. The overlap is not a coincidence. All three were written by people looking at the same set of AI risks.
Why it's hard in practice
If the overlap is so clean, why does everyone still do the work three times? Because mapping is harder than it looks, in three specific ways.
The frameworks sit at different altitudes. The EU AI Act is legally specific in some places and broad in others. NIST is outcome-based and deliberately leaves the how open. ISO/IEC 42001 is principle-based at the control level. A single control rarely maps one-to-one. It usually answers part of an obligation in each framework, and you have to be honest about the partial coverage rather than paper over it. A mapping that claims a single log answers the EU AI Act's entire record-keeping article is wrong and will not survive a regulator's scrutiny.
Vocabulary diverges. "Impact assessment" in 42001, "risk management system" in the AI Act, and "Map" in NIST overlap heavily but are not synonyms. Teams either treat them as identical, and miss real differences, or treat them as wholly separate, and duplicate work. Both errors are expensive at enterprise scale.
Evidence is the part people forget to map. Drawing lines between control requirements is one thing. Pointing each line at the same underlying evidence is another. A mapping spreadsheet that says "we satisfy all three" but points to three different, manually assembled evidence sets has saved you nothing. You still maintain three piles. The win only materializes when one control produces one stream of evidence that all three citations reference.
And the frameworks move. The EU AI Act has phased application dates and evolving guidance. NIST updates its profiles. ISO standards get revised. A static mapping built once decays, and across multiple jurisdictions it decays faster. Someone has to own keeping it current.
What good evidence looks like
An auditor or regulator examining a cross-walk is testing two things: that the mapping is honest and that the evidence is real and shared.
A defensible cross-walk has these properties:
- Control-centric, not framework-centric. It is organized around the underlying controls you actually operate (human oversight gate, access policy, data-governance process, audit log), with each control annotated by the framework obligations it addresses, and which part of each. Coverage is expressed as mapping evidence to objectives, not as a guarantee that any framework is fully satisfied.
- Honest about partial coverage. Where a control addresses 60 percent of an obligation, the mapping says so and names what else closes the gap. Auditors trust a mapping that admits limits far more than one claiming total coverage everywhere.
- Anchored to shared evidence. Each control points to one evidence source, ideally an operational record, that every mapped obligation can draw from. The same human-oversight log answers the AI Act, NIST, and 42001 questions about oversight, because it is the record of oversight happening.
- Versioned and dated. The mapping shows when it was last reviewed against each framework's current text, so a reviewer knows it reflects today's obligations rather than last year's.
The test is simple. Can a reviewer pick any obligation in any of the three frameworks, follow the mapping to a control, follow the control to a piece of evidence, and see that the evidence is the same one another framework's obligation also relies on? If yes, you have a real cross-walk. If the evidence forks into three, you have three programs wearing one spreadsheet.
The runtime-record approach
This is where mapping stops being a documentation exercise and becomes an operating choice. The reason cross-walk works in theory but fails in practice is that evidence is usually generated and stored per-framework. The fix is to generate it once, from operation, and reference it many times. That is the model Cytra is built on. A single control implemented in the managed gateway, say a deterministic policy that requires human approval for a class of agent actions executed in a deny-by-default sandbox, produces one signed, tamper-evident record in a hash-chained ledger. That one record is what the cross-walk points to for the EU AI Act's human-oversight obligation, NIST's Manage function, and ISO/IEC 42001's control A.9 simultaneously. One control, mapped once, answers the same obligation across all three. For teams not ready to govern every call, the standalone collector still captures the operational evidence the mapping references. To be exact, and this is for compliance officers rather than marketers: this maps your controls and evidence to the objectives of all three frameworks so you are aligned and audit-ready. It does not certify you against any of them, and it does not guarantee compliance with the EU AI Act, which remains a legal determination. The gateway is in private beta.
Takeaway: a cross-walk checklist
- Inventory the controls you actually operate, not the frameworks you owe. The control is the unit of reuse.
- Map each control to the EU AI Act, NIST AI RMF, and ISO/IEC 42001 obligations it addresses, and note which part of each it covers.
- Be explicit about partial coverage and name what closes the gaps. Honesty survives audits; completeness theater does not.
- Anchor every mapped obligation to one shared evidence source, ideally an operational record, so you maintain one pile, not three.
- Version and date the mapping against each framework's current text, and assign an owner to keep it current as the frameworks evolve.
- Test the mapping backward. Pick any obligation, trace it to a control, trace the control to evidence, and confirm other frameworks rely on the same evidence.
Done right, a cross-walk turns three workstreams into one. You implement a control because it is good practice, you capture its evidence because the system runs, and you let one record answer three frameworks at once. That is not a clever spreadsheet. It is the difference between governing your AI once and accounting for it three times.