Crosswalk pair
AI Governance Essentials and ISO/IEC 42001, control by control
13 canonical controls in Keel’s library satisfy clauses of both AI Governance Essentials and ISO/IEC 42001. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
AI Governance Essentials is free on every plan. ISO/IEC 42001 counts as one of your plan’s paid frameworks, or from $39/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.
13
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
24
In Keel’s library for AI Governance Essentials
54% of them also map to ISO/IEC 42001.
38
In Keel’s library for ISO/IEC 42001
34% of them also map to AI Governance Essentials.
31
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
13 controls of 24 in Keel’s library for AI Governance Essentials also map to ISO/IEC 42001.
-
ISO/IEC 42001 34%
13 controls of 38 in Keel’s library for ISO/IEC 42001 also map to AI Governance Essentials.
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 | AI Governance Essentials clauses | ISO/IEC 42001 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. | GV.1, GV.4 | 5.2, A.2.2, A.2.3, A.2.4 |
| AI risk treatment & sign-off Every AI risk the assessment surfaced leaves it with a decision attached: mitigate it, avoid it by not building or not deploying, share or transfer it, or accept it as it stands - and the decision names the treatment, the control that delivers it, the person who owns that work, and the date it is due. The treatment is chosen against the criteria the organization set in advance for what it will accept, rather than against what is convenient to implement, and where a treatment leaves risk behind, that residual risk is written down and accepted in writing by the risk owner rather than left as the remainder nobody looked at. Sign-off comes before go-live: a system whose risks have not been treated and approved does not go into service, and the approval is recorded against the version of the system it was given for, so a later change is visibly a new question rather than covered by an old answer. The plan is then carried out and its results retained - what was actually implemented, what it changed about the risk it was raised against, and what is still open - so treatment can be shown to have happened rather than to have been planned. | RM.4 | 6.1.3, 8.3 |
| 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. | GV.2 | A.3.2, A.3.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. | RM.1, RM.2 | 6.1.4, 8.4, A.5.2, A.5.4, A.5.5 |
| 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. | TR.2 | A.5.3, A.6.2.7 |
| 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. | TR.1, TR.3 | A.8.2, A.8.3, A.8.5 |
| 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. | HO.1, HO.2 | A.6.2.6, A.9.2 |
| Management review Leadership reviews how the management system is performing at planned intervals and decides what to do about it: what will be improved, and what about the system itself has to change. Each decision leaves the review with a named owner and a date rather than as a sentiment in the minutes, the previous review’s decisions are picked back up at the next one so nothing is decided twice and never done, and the record of the review and its outputs is retained. The risk management strategy is one of the review’s standing subjects: what the strategy actually produced is reviewed for what it says about the direction being taken, and the strategy itself is then reviewed and adjusted for whether it still covers the requirements the organization is under and the risks on its register - so a strategy the year has overtaken is changed at the review rather than reaffirmed by it. The review is planned rather than convened, and what it has to consider is fixed in advance: the status of actions from previous reviews; changes in the external and internal issues that bear on the system; the satisfaction of customers and the feedback of other interested parties; how far the objectives set for the system have been met; how the processes are performing and whether what the organization delivers conforms; the nonconformities raised and the corrective actions taken; the results of monitoring and measurement; audit results; how external providers are performing; whether the resources the system has are adequate; the effectiveness of the actions taken on risks and opportunities; and the opportunities for improvement on the table. An input that is missing on the day is recorded as missing rather than passed over, so the review is answerable for what it did not see as well as for what it decided. Where the organization develops or uses AI, the AI governance program is a standing subject of the same review rather than a separate forum: what the AI systems in scope did, what the risks and impacts recorded against them showed, and what should change - taken with the rest of the agenda by the same leadership, so an AI decision is weighed against the organization’s other commitments instead of beside them. | GV.5 | 9.3 |
| Data Protection & Privacy | ||
| Data governance for AI Governance of the data used to develop and operate AI systems: sourcing, quality, provenance, and preparation of training and operational data. Where each training and tuning dataset came from is recorded, and the organization confirms it is permitted to use it for that purpose before the data is used rather than after somebody raises the question. Data is checked for whether it is accurate and appropriate for the people and the cases the system will actually affect - representative of that population rather than of whoever was easiest to collect from - and a shortfall found is recorded and acted on instead of noted. Only the data the AI purpose needs is used: a field nobody can tie to the purpose does not enter the pipeline, and what is used is kept no longer than the purpose justifies, with the retention period stated per dataset and enforced when it ends. | DA.1, DA.2, DA.4 | A.4.3, A.7.2, A.7.3, A.7.4, A.7.5, A.7.6 |
| 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. | SR.2, LC.1 | A.6.2.4 |
| 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. | LC.3, LC.4 | A.6.2.6, A.8.4 |
| 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. | TP.1, TP.2 | A.10.2, A.10.3 |
| 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. | HO.3 | A.4.6 |
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 13 controls
- 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 also reached
- EU AI Act also reached
- FedRAMP 20x not 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 AI Risk Management Framework 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 also reached
- SOX (Sarbanes-Oxley) Section 404 also 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 NIST AI Risk Management Framework 14 shared controls
- AI Governance Essentials and NIST AI Risk Management Framework 13 shared controls
- ISO/IEC 42001 and NIST Cybersecurity Framework 10 shared controls
- AI Governance Essentials and EU AI Act 9 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, ISO/IEC 42001 mostly lights up controls you already built for AI Governance Essentials. 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 ISO/IEC 42001 to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.