Framework Crosswalk · pack v2026.07.30
NIST AI RMF vs ISO/IEC 42001: what actually carries over
45 requirement-level mappings connect NIST AI RMF and ISO/IEC 42001: 7 strong (completing one substantially satisfies the other) and 38 partial (it contributes, but more is needed). Neither framework substitutes for the other — this page shows exactly what carries over, requirement by requirement.
What carries over between NIST AI RMF and ISO/IEC 42001?
Strong mappings: completing one requirement substantially satisfies the other.
| NIST AI RMF | ISO/IEC 42001 | Why |
|---|---|---|
| NIST AI RMF GOVERN-1.2 | ISO/IEC 42001 5.2 | Both produce the documented AI policy embedding trustworthiness commitments; ISO adds the objectives framework and continual-improvement commitment. |
| NIST AI RMF GOVERN-2.1 | ISO/IEC 42001 5.3 | Both produce documented AI roles, responsibilities, and reporting lines communicated across the organization. |
| NIST AI RMF GOVERN-1.4 | ISO/IEC 42001 6.1.2 | A written procedure defining who assesses AI risk, when, by what method, and where results are recorded is the substance of the ISO risk assessment process; ISO additionally requires explicit risk criteria. |
| NIST AI RMF MAP-5.1 | ISO/IEC 42001 6.1.4 | Both are the documented AI impact assessment: likelihood and magnitude of consequences for individuals, groups, and society. |
| NIST AI RMF GOVERN-2.2 | ISO/IEC 42001 7.2 | Both require training people in AI-relevant roles on their responsibilities and retaining completion records. |
| NIST AI RMF GOVERN-1.2 | ISO/IEC 42001 A.2 | Both require documented, periodically reviewed AI policies carrying management direction and trustworthiness commitments. |
| NIST AI RMF MAP-5.1 | ISO/IEC 42001 A.5 | Both establish documented impact assessments of AI systems on individuals, groups, and society across the life cycle. |
What only partly carries over?
Partial mappings: work on one contributes to the other, but more is needed. Shieldra deliberately does not count these as coverage — the "why" column is what's still missing.
| NIST AI RMF | ISO/IEC 42001 | Why (and what’s missing) |
|---|---|---|
| NIST AI RMF GOVERN-1.1 | ISO/IEC 42001 4.2 | A maintained register of applicable AI legal and regulatory requirements is the regulatory half of 4.2; identifying interested parties and their non-legal requirements remains. |
| NIST AI RMF GOVERN-1.6 | ISO/IEC 42001 4.3 | A current AI system inventory is the factual basis for scoping the AIMS, but the documented scope statement itself is ISO-specific. |
| NIST AI RMF GOVERN-1.4 | ISO/IEC 42001 4.4 | A documented, operating AI risk program is a major component of an AIMS but not the full management system with its interacting processes. |
| NIST AI RMF GOVERN-2.3 | ISO/IEC 42001 5.1 | Recorded executive accountability for AI deployment decisions evidences leadership commitment; ISO also requires resourcing and strategic alignment of the AIMS. |
| NIST AI RMF MAP-1.5 | ISO/IEC 42001 6.1.2 | Documented risk tolerances supply the risk-criteria input of the assessment process, not the process itself. |
| NIST AI RMF MAP-5.1 | ISO/IEC 42001 6.1.2 | Likelihood-and-magnitude analysis is the analysis step of the ISO process, which also requires criteria and consistent application. |
| NIST AI RMF MANAGE-1.3 | ISO/IEC 42001 6.1.3 | Both produce documented risk responses with owners and dates, but 6.1.3 also requires the Annex A control comparison and a Statement of Applicability. |
| NIST AI RMF MANAGE-1.2 | ISO/IEC 42001 6.1.3 | Written risk prioritization feeds treatment-option selection but is not the treatment plan or Statement of Applicability. |
| NIST AI RMF MAP-1.3 | ISO/IEC 42001 6.2 | Written AI goals tied to the mission feed ISO objectives, which must additionally be measurable with plans, owners, and completion dates. |
| NIST AI RMF MANAGE-2.1 | ISO/IEC 42001 7.1 | Accounting for the resources each system's risk management needs evidences part of resourcing the AIMS. |
| NIST AI RMF MAP-3.4 | ISO/IEC 42001 7.2 | Operator proficiency definitions and qualification records satisfy the competence requirement for operator roles specifically. |
| NIST AI RMF GOVERN-2.2 | ISO/IEC 42001 7.3 | Policy-and-responsibility training builds the required awareness, though ISO awareness extends to everyone working under the organization's control. |
| NIST AI RMF GOVERN-4.2 | ISO/IEC 42001 7.4 | Sharing AI risk documentation beyond the owning team is one strand of the communication plan ISO requires to be determined systematically. |
| NIST AI RMF GOVERN-1.4 | ISO/IEC 42001 8.1 | Written risk procedures and controls contribute to operational planning and control, which also covers change control of AIMS processes. |
| NIST AI RMF MEASURE-3.1 | ISO/IEC 42001 8.2 | A living risk register with owners and review dates evidences recurring assessment, but ISO requires full reassessments at planned intervals with retained results. |
| NIST AI RMF MANAGE-1.3 | ISO/IEC 42001 8.3 | Planned responses with owners and dates are the input 8.3 executes; ISO requires documented evidence that the treatment plan was implemented. |
| NIST AI RMF MAP-5.1 | ISO/IEC 42001 8.4 | Re-running the documented impact assessment covers the operational duty only when performed at planned intervals or on significant change, with retained results. |
| NIST AI RMF MEASURE-1.1 | ISO/IEC 42001 9.1 | Selected, documented metrics for significant AI risks supply part of the ISO determination of what to monitor, how, and by whom. |
| NIST AI RMF MEASURE-2.4 | ISO/IEC 42001 9.1 | Production monitoring of AI behavior is monitoring evidence, though 9.1 also covers measuring the management system itself. |
| NIST AI RMF MEASURE-1.3 | ISO/IEC 42001 9.2 | Independent assessors provide the objectivity internal audit needs, but a conformance audit against the standard's requirements is a distinct exercise. |
| NIST AI RMF GOVERN-1.5 | ISO/IEC 42001 9.3 | A scheduled, minuted review of the AI risk program covers much of the management-review agenda, but ISO requires top-management participation and prescribed inputs. |
| NIST AI RMF MANAGE-4.2 | ISO/IEC 42001 10.1 | Measurable improvement built into system updates evidences continual improvement of AI practice; ISO targets the management system itself. |
| NIST AI RMF MANAGE-2.3 | ISO/IEC 42001 10.2 | A defined respond-recover-and-learn procedure parallels corrective action, but ISO requires root-cause evaluation of management-system nonconformities with retained evidence. |
| NIST AI RMF GOVERN-2.1 | ISO/IEC 42001 A.3 | Both document AI roles and reporting lines, but A.3 additionally requires a concern-reporting mechanism that GOVERN-2.1 does not produce. |
| NIST AI RMF GOVERN-4.1 | ISO/IEC 42001 A.3 | A culture that rewards raising concerns supports the A.3 concern-reporting process but does not formalize it. |
| NIST AI RMF GOVERN-1.6 | ISO/IEC 42001 A.4 | An inventory recording each system's owner, purpose, and data touched starts the A.4 resource documentation, which also covers tooling, compute, and human competence. |
| NIST AI RMF MAP-1.1 | ISO/IEC 42001 A.6 | Documented purpose, context, assumptions, and limitations covers the requirements-definition and documentation slice of the life-cycle controls. |
| NIST AI RMF MAP-1.6 | ISO/IEC 42001 A.6 | Requirements elicited with socio-technical input feed the life-cycle objectives-and-requirements stage. |
| NIST AI RMF MEASURE-2.1 | ISO/IEC 42001 A.6 | Documented test sets, metrics, and TEVV tooling evidence the verification-and-validation stage of the life cycle. |
| NIST AI RMF MEASURE-2.4 | ISO/IEC 42001 A.6 | Production monitoring of system behavior evidences the operation-and-monitoring stage of the life cycle. |
| NIST AI RMF MAP-2.3 | ISO/IEC 42001 A.7 | Recorded data-collection, representativeness, and suitability considerations cover part of documented data-life-cycle management. |
| NIST AI RMF MAP-4.1 | ISO/IEC 42001 A.7 | A documented provenance and rights review of third-party data contributes to managed data acquisition. |
| NIST AI RMF MAP-2.2 | ISO/IEC 42001 A.8 | Documentation of knowledge limits and proper output use is core user information for interested parties. |
| NIST AI RMF MANAGE-4.3 | ISO/IEC 42001 A.8 | Documented incident communication to affected parties implements the A.8 incident-reporting expectation. |
| NIST AI RMF MEASURE-3.3 | ISO/IEC 42001 A.8 | User feedback and appeal channels are the communication channels for affected parties that A.8 expects. |
| NIST AI RMF MAP-3.3 | ISO/IEC 42001 A.9 | A documented application scope defining where the system must not be used underpins responsible-use-per-intended-purpose processes. |
| NIST AI RMF GOVERN-6.1 | ISO/IEC 42001 A.10 | Both cover supplier-side third-party policy and due diligence, but A.10 also requires customer-side responsibility allocation that GOVERN-6.1 does not produce. |
| NIST AI RMF MANAGE-3.1 | ISO/IEC 42001 A.10 | Ongoing monitoring and documented controls over third-party AI implement the supplier side of A.10; customer-side responsibility allocation remains. |
Frequently asked questions
Does NIST AI RMF cover ISO/IEC 42001?
Not by itself. Of the 45 requirement-level mappings between them, only 7 are strong; the other 38 are partial, meaning work on one contributes evidence toward the other but does not satisfy it. Shieldra deliberately does not count partial mappings as coverage.
What is the difference between a strong and a partial mapping?
Requirement-level crosswalk among the AI frameworks. strength=strong means completing one substantially satisfies the other; partial means it contributes but more is needed.
Should you do NIST AI RMF or ISO/IEC 42001 first?
They answer different demands: a regulation binds by law, a management-system standard or risk framework is what enterprise buyers ask for. The overlap table on this page shows which requirements you only have to build once — start from whichever one a customer or regulator is actually asking you for.