Crosswalk pair
ISO/IEC 42001 and NIST AI Risk Management Framework, control by control
14 canonical controls in Keel’s library satisfy clauses of both ISO/IEC 42001 and NIST AI Risk Management Framework. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
ISO/IEC 42001 counts as one of your plan’s paid frameworks, or from $39/mo as an add-on. NIST AI Risk Management Framework counts as one of your plan’s paid frameworks, or from $19/mo as an add-on. See plans and pricing.
The overlap
What the two libraries have in common
Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.
14
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
38
In Keel’s library for ISO/IEC 42001
37% of them also map to NIST AI Risk Management Framework.
27
In Keel’s library for NIST AI Risk Management Framework
52% of them also map to ISO/IEC 42001.
32
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
ISO/IEC 42001 37%
14 controls of 38 in Keel’s library for ISO/IEC 42001 also map to NIST AI Risk Management Framework.
-
NIST AI Risk Management Framework 52%
14 controls of 27 in Keel’s library for NIST AI Risk Management Framework also map to ISO/IEC 42001.
The mapping
Controls that satisfy both
Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.
| Canonical control | ISO/IEC 42001 clauses | NIST AI Risk Management Framework clauses |
|---|---|---|
| Governance & Risk | ||
| AI policy A documented, leadership-approved policy for the responsible development and use of AI, aligned with the organization’s other policies and reviewed at planned intervals. The policy is where the AI risk management process is established, rather than the process being whatever practice has grown up: it states how AI risk is assessed, who decides what, which of the organization’s risk priorities make an activity mandatory and which leave it to judgment, and what has to be recorded when a decision is taken. It is written to be read by the people it binds and published to them, so the process and the outcomes it produces rest on transparent policy, procedure and control rather than on the standing of whoever happens to be running it. Top management establishes the policy itself rather than ratifying one drafted beneath it: the policy is appropriate to the organization’s purpose, it provides the frame within which AI objectives are set, and it carries a commitment to meet the requirements that apply and to keep improving the management system. It is kept as documented information, communicated inside the organization, and made available to interested parties where that is appropriate. The policy states boundaries as well as principles - where AI may be used, where it may not, and which uses the organization has decided to prohibit outright - written as a rule somebody can be held to rather than as an aspiration, so that a proposed use can be tested against it before any work starts. | 5.2, A.2.2, A.2.3, A.2.4 | GOVERN-1.2, GOVERN-1.4 |
| AI risk management process A process to identify, analyze, prioritize, and treat the risks an AI system can pose, tracked over its lifecycle. The organization’s risk tolerances for AI are determined and written down first, and the level of risk management activity a given system attracts is set against them, so a low-stakes internal tool and a system that decides something about a person are not put through the same process by default. Tracking is continuous rather than a single pass: existing, unanticipated and emergent risks are identified regularly by named people working from documented approaches, and are read against both how the system was expected to perform and how it actually performs in the context it was deployed into. Where a risk cannot be assessed with the measurement techniques available, or no metric for it exists yet, that is not treated as an absence - a tracking approach is chosen for it deliberately and recorded, so the risk stays visible while it is unmeasurable. The resources needed to manage AI risk are accounted for as part of the treatment decision, and a viable non-AI alternative system, approach or method is weighed on the same terms as any other mitigation, because not building the system is sometimes what reduces the magnitude or likelihood of the impact most. The process itself is monitored and periodically reviewed on a plan: who reviews it and how often is decided in advance and written down, and both the process and the outcomes it produced are examined, so a process that has quietly stopped surfacing anything is noticed rather than trusted. The assessment is a defined process rather than an exercise: the criteria for accepting AI risk, and the criteria for deciding when an assessment is performed at all, are set in advance and applied the same way each time, so repeated assessments produce consistent and comparable results rather than a different answer depending on who ran them. It is performed at planned intervals and again when a significant change is proposed or has happened - a new intended use, a new model, a new data source, a new population it is used on - and the results of each run are retained as documented information. | 6.1.2, 8.2 | GOVERN-1.3, GOVERN-1.5, MAP-1.5, MEASURE-1.1, MEASURE-3.1, MEASURE-3.2, MANAGE-1.2, MANAGE-1.3, MANAGE-2.1 |
| AI roles & accountability Defined and allocated responsibilities for AI across the organization, plus a way for staff to raise concerns about the organization’s AI. Executive leadership holds the decisions about AI risk rather than delegating them out of sight: the decision to develop or deploy an AI system, and the acceptance of the risk that comes with it, is taken by a named executive who answers for it, and the name is recorded with the decision rather than reconstructed afterwards. One owner is named for AI governance as a whole - a single accountable role rather than a committee that shares the answer - and the responsibilities of the teams that build, buy, operate and rely on AI are defined against that ownership, so nothing lands in the gap between two functions. | A.3.2, A.3.3 | GOVERN-2.1, GOVERN-2.3 |
| AI system impact assessment A process to assess the potential impacts of AI systems on individuals, groups, and society, and to document and act on the results. The assessment weighs both sides of the ledger. The benefits expected from the system’s intended functionality and performance are examined and written down, rather than assumed from the fact that somebody wanted to build it. So are the potential costs that follow from an expected or realized error, or from functionality and trustworthiness falling short - including the costs that are not monetary, such as time taken from the people it is used on, harm to those wrongly classified, and the erosion of trust that is expensive to rebuild - and both are read against the organization’s stated risk tolerance rather than against nothing. The team that designs, develops, deploys, evaluates or uses the technology is the team that documents its risks and potential impacts, and it does not stop at documenting them: what it found is communicated more broadly, to the people who take the deployment decision and to those who will live with it. The process is defined before it is used and then run to plan: when an impact assessment is required, who performs it, and against what criteria are settled in advance; it is performed at planned intervals and again when circumstances change; and the results of each are retained as documented information. Impacts on wider society are assessed in their own right alongside impacts on individuals and groups - effects on the environment the system operates in, on economies and livelihoods, on public discourse, and on the institutions people rely on - because a system can leave every individual user unharmed and still move something at that scale. | 6.1.4, 8.4, A.5.2, A.5.4, A.5.5 | MAP-3.1, MAP-3.2, MAP-5.1, GOVERN-4.2 |
| AI technical documentation Maintained technical documentation of an AI system’s design, development, and impact assessments, sufficient to demonstrate how it works and was built. It states the system’s knowledge limits - what it was built to handle, what it was not, and the conditions under which its output should not be relied on - together with how that output may be used and how a person oversees it, in enough detail that someone deciding whether to act on an output can decide well rather than guess. It also identifies, component by component, the internal risk controls the organization relies on for that component, third-party AI technologies and pre-trained models included, so the controls standing behind a system are documented in one place instead of being inferred from whichever team implemented each part. The documentation is written for the teams that rely on the system as much as for an assessor: its purpose, the data behind it, its limits and the use it is intended for are stated in one place they can find, and are kept current as the system changes rather than fixed at the version that was first written. | A.5.3, A.6.2.7 | MAP-2.2, MAP-4.2 |
| AI transparency & disclosure Clear information for users and interested parties, including disclosing when people are interacting with an AI system and how to use it appropriately. The risks to transparency and accountability that mapping identified are examined and documented in their own right - a decision the system contributed to that could not be explained afterwards, an outcome whose ownership would be unclear if it were challenged, a disclosure that is technically present but not usable by the person it is for - rather than being treated as discharged by the fact that a disclosure exists. The model is explained, the explanation is validated rather than asserted, and both are documented; the system’s output is interpreted within the context it is used in, so that what an output means, and what it does not mean, informs responsible use and the governance decisions taken on top of it. Negative residual risk - what is left unmitigated after treatment - is written down and passed to the people who will actually carry it: downstream acquirers who will build on the system, and end users who will act on what it produces. People are told when they are interacting with an AI system, and when AI materially shapes a decision about them, at the point it happens rather than in a policy they would have to go looking for. The basis of a consequential AI-assisted decision can be given to the person it was about in plain terms - what mattered, and what would have had to be different - rather than only as a technical account that satisfies an engineer. Information owed to parties outside the organization is provided rather than waited for: what external interested parties need to know about the organization’s AI systems - regulators, customers, the people a system is used on, and those who represent them - is determined, and there is a route by which they receive it and can come back with a question. | A.8.2, A.8.3, A.8.5 | MEASURE-2.8, MEASURE-2.9, MANAGE-1.4 |
| Continual improvement Improvement of the management system is run as an activity with a record, not held as an intention. Opportunities are captured from everywhere they arise - audit findings, the results of measurement and evaluation, decisions out of management reviews, incidents and near misses, and suggestions from the people actually doing the work - and held in one place instead of in the meeting each came out of. Each is evaluated and either taken forward with an owner and a date or closed with the reason it was not, so a rejected idea is a decision rather than a silence. Once an improvement is made, its effect on the suitability, adequacy and effectiveness of the system is checked, so improvement is something that can be shown to have happened rather than asserted at the next audit. The routine execution of the work counts as a source in its own right: what the operational processes, procedures and activities themselves show while they are being run - the step that is always skipped, the check that never fires, the manual workaround everybody has quietly adopted - is captured on the same terms as a finding from an audit, because the people running a process daily see more of it than any evaluation does. Where the thing being improved is an AI system, the improvement activity is built into the system’s own update cycle and is measurable: an update carries the improvement it is meant to deliver and the measure that will show whether it did, checked afterwards rather than asserted, and interested parties - the people who operate the system, the people it is used on, and those who represent them - are engaged regularly as part of that cycle rather than consulted once at launch. The opportunities are not confined to the system: what the organization delivers is in scope too. Improving products and services to meet known requirements and to address needs and expectations that are coming rather than current, correcting, preventing or reducing undesired effects, and improving how the system itself performs are all determined and selected against as improvement opportunities, rather than run as three unrelated programs. And the standing question - what in the system’s suitability, adequacy and effectiveness should be improved next - is answered from evidence rather than appetite: the results of analysis and evaluation and the outputs of management review are considered together to decide whether there is a need or an opportunity that has to be addressed. | 10.1 | MANAGE-4.2 |
| Human oversight of AI Appropriate human oversight of AI systems, so people can understand, monitor, and intervene in how an AI system operates - the named people who hold that oversight have the competence, the authority and the access to the system to exercise it, and the system is operated in the way the instructions supplied with it specify, inside the purpose it was assessed and approved for rather than whatever use it turns out to support. Policy defines and differentiates the roles in each human-AI configuration instead of letting "a human is involved" stand for all of them: where a person decides and the system only advises, where the system decides and a person reviews before the outcome takes effect, and where the system acts alone with a person monitoring after the fact - each configuration naming who holds the oversight role, what they are expected to check, and what they are empowered to do about it. The oversight process for a given system is then defined in line with those policies, assessed against whether it actually works in practice rather than on paper, and documented. | A.6.2.6, A.9.2 | GOVERN-3.2, MAP-3.5 |
| Responsible use of AI Processes and objectives for using AI systems responsibly and within their intended purpose, so deployment stays inside approved boundaries. The value a deployed system was approved for is sustained rather than assumed to persist: mechanisms are in place and actually applied to keep it doing the job as its data, its users and its context drift - scheduled review of whether it still earns its place, retraining or tuning where performance has moved, upkeep of the documentation and the instructions that travel with it, and a recorded decision when the honest answer is that it no longer does. | A.9.2, A.9.3, A.9.4 | MANAGE-2.2 |
| Infrastructure & Operations | ||
| AI verification, validation & robustness Testing that an AI system meets its requirements and performs with appropriate accuracy, robustness, and security before and during use. Safety is evaluated on its own terms and on a regular cadence, against the safety risks identified when the system was mapped: the system is demonstrated to be safe before it is deployed, its residual negative risk is shown to sit inside the stated risk tolerance rather than merely to have been reduced by some amount, and it is shown to fail safely - particularly when it is driven beyond the limits of what it knows. The safety metrics used reach reliability and robustness, what is watched in real time, and how quickly a failure of the system is responded to. Validation before go-live is a gate rather than a report: what the system has to demonstrate about meeting its intended purpose and the risk criteria set for it is decided in advance, and a system that does not meet them does not go into service. Performance is tested for stability as well as for accuracy - across the range of inputs, populations and operating conditions the system will actually meet in production, not only on the data it was built on. | A.6.2.4 | MEASURE-2.3, MEASURE-2.4, MEASURE-2.5, MEASURE-2.6, MEASURE-2.7 |
| Responsible AI development lifecycle Objectives and processes for responsible design and development of AI systems, including requirements, design documentation, and controlled deployment. Requirements are elicited from the relevant AI actors rather than assumed by the build team - the people who will operate the system, the people it will be used on, the domain experts, and the functions accountable for it - and they are written so those people can confirm they understood them. "The system shall respect the privacy of its users" is a requirement rather than a sentiment only when it is stated as something a test could fail. Design decisions record the socio-technical implications they carry: what a choice does to the people and the process around the system, not only to its measured performance. | A.6.1.2, A.6.1.3, A.6.2.2, A.6.2.3, A.6.2.5 | MAP-1.6 |
| Resilience & Continuity | ||
| AI monitoring & malfunction reporting Ongoing monitoring of AI systems in operation, with a process to detect, communicate, and report malfunctions and serious incidents. The process covers the risk nobody anticipated as well as the failure modes that were designed for: when a previously unknown risk is identified, there are procedures to follow rather than a meeting to convene - contain it, decide whether the system keeps running while it is understood, recover the service and the people it affected, and feed what was learned back into the risk record - and those procedures are actually followed and the run of them recorded. Monitoring is aimed at what degrades quietly as well as at what breaks: drift in the data or in the population, degradation in accuracy, and outcomes nobody expected are watched against a baseline recorded at deployment, on a stated cadence, with a threshold that triggers action rather than a chart somebody may look at. Incidents and harms are detected, recorded and responded to on a defined route with named responders, and what was learned goes back into the risk record and into the program rather than closing with the ticket. | A.6.2.6, A.8.4 | MANAGE-2.3, MANAGE-4.1, MANAGE-4.3 |
| Third-party Risk | ||
| AI supplier & third-party management Allocation of responsibilities with, and oversight of, the suppliers and third parties involved in developing or providing AI systems and components. The technology and legal risks a third-party component carries are mapped before it is adopted and re-checked while it is in use: what the component actually does, what data it was built on, what the license does and does not permit for the organization’s use of it, and whether that use risks infringing a third party’s intellectual property or other rights - with the approach for doing this in place, followed, and the result documented rather than settled in a procurement thread. Pre-trained models taken from outside and built into a system are monitored on the same terms as the parts the organization wrote, as part of regular monitoring and maintenance, because a model nobody here retrains still changes underneath the system when the provider ships a new version, deprecates the old one, or alters the terms it is offered under. And where a third-party dataset or AI system is judged high-risk, a contingency process is written and kept ready for its failure or its compromise - what the organization falls back to, who is authorized to invoke it, how service is carried on or withdrawn, and what the people relying on the system are told - so a dependency the organization does not control has a planned response instead of an improvised one. Diligence comes before the dependency: the governance, security and risk posture of a supplier whose AI the organization will rely on is assessed and the result recorded before the relationship starts, and re-checked while it runs. What the organization requires of third-party AI is then written into the contract rather than left to expectation - what the supplier may do with data it is given, what it must disclose about the model and its limits, what it must tell the organization when something changes or goes wrong, and who answers for an outcome. | A.10.2, A.10.3 | GOVERN-6.1, GOVERN-6.2, MAP-4.1, MANAGE-3.1, MANAGE-3.2 |
| People & Culture | ||
| AI competence & training The people and the partners who work with the organization’s AI are trained in AI risk management, pitched at what their duties actually are, so they can carry those duties out consistently with the policies, procedures and agreements that bind them - the people who build, the people who approve, the people who operate, the people who answer for it, and the suppliers and contractors doing any of those on the organization’s behalf. Separately from that awareness, the proficiency of the operators and practitioners who work with a system day to day is treated as a defined process rather than an assumption: what a person must be able to do with this system, including how to read its performance and its trustworthiness characteristics, is set out; they are assessed against it before they are relied on and again periodically; and the assessment is documented. Where relevant technical standards or certifications exist for the work, they are identified and the organization’s position on holding them is recorded rather than left open. Training and proficiency are refreshed when the systems change, when the risks change, or when an assessment showed somebody could not do something the role requires. The human resources the organization’s AI work needs are documented as a resource in their own right: which roles are required, what competencies each must hold, and where the gap sits between that and the people actually available - so a shortfall in people is visible on the same page as a shortfall in compute. The people who operate an AI system or act on its output are trained specifically in what it can and cannot do: the conditions under which its output should not be relied on, the failure modes it is known to have, and the correct way to use it - so its limits are known by the person taking the decision and not only by the team that built it. | A.4.6 | GOVERN-2.2, MAP-3.4 |
Beyond the pair
Where else this work counts
A framework is lit when a shared control above also maps to it. Unlit means none of them do, which is an absence rather than a judgment about that standard.
Also reached by these 14 controls
- AI Governance Essentials also reached
- Amazon Appstore Child-Directed Apps not reached
- Apple App Store Kids Category not reached
- CIS Critical Security Controls not reached
- COPPA not reached
- ESG Essentials not reached
- EU AI Act also reached
- FedRAMP 20x also reached
- FedRAMP Consolidated Rules not reached
- FedRAMP Rev5 Class B not reached
- FedRAMP Rev5 Class C not reached
- FedRAMP Rev5 Class D not reached
- GDPR not reached
- Google Play Families not reached
- HIPAA not reached
- ISO 9001 also reached
- ISO/IEC 27001 also reached
- NIST Cybersecurity Framework also reached
- NIST SP 800-171 not reached
- NIST SP 800-53 not reached
- PCI DSS not reached
- PIPEDA not reached
- SOC 2 not reached
- SOX (Sarbanes-Oxley) Section 404 not reached
- US Employment Law - Federal Baseline not reached
Nearby pairs
- ISO/IEC 42001 and ISO 9001 17 shared controls
- ISO/IEC 42001 and ISO/IEC 27001 16 shared controls
- ISO/IEC 42001 and AI Governance Essentials 13 shared controls
- NIST AI Risk Management Framework and AI Governance Essentials 13 shared controls
- ISO/IEC 42001 and NIST Cybersecurity Framework 10 shared controls
- ISO/IEC 42001 and EU AI Act 8 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, NIST AI Risk Management Framework mostly lights up controls you already built for ISO/IEC 42001. You’re not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That’s the whole idea behind collect once, comply everywhere.
Next step
Add NIST AI Risk Management Framework to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.