Crosswalk pair
ISO/IEC 27001 and NIST AI Risk Management Framework, control by control
2 canonical controls in Keel’s library satisfy clauses of both ISO/IEC 27001 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 27001 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.
2
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
84
In Keel’s library for ISO/IEC 27001
2% of them also map to NIST AI Risk Management Framework.
27
In Keel’s library for NIST AI Risk Management Framework
7% of them also map to ISO/IEC 27001.
7
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
2 controls of 84 in Keel’s library for ISO/IEC 27001 also map to NIST AI Risk Management Framework.
-
NIST AI Risk Management Framework 7%
2 controls of 27 in Keel’s library for NIST AI Risk Management Framework also map to ISO/IEC 27001.
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 27001 clauses | NIST AI Risk Management Framework clauses |
|---|---|---|
| Governance & Risk | ||
| 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 |
| Legal, regulatory & contractual obligations register The organization maintains a register of the legal, statutory, regulatory and contractual requirements that bear on information security and on the information it holds, and records for each one how it is met and who is accountable for meeting it. Entries are specific enough to act on: the obligation, the jurisdiction and entity it applies to, what it actually requires the organization to do, the control or process that discharges it, the evidence that would demonstrate that, and the review date. The register covers the contractual side as well as the statutory - security commitments made to customers, obligations flowed down from them, and terms accepted from suppliers - because a promise in a signed contract binds the organization as firmly as a statute and is more easily forgotten. It records the requirements attached to cryptography specifically, since the use, import, export and disclosure of cryptographic material is restricted differently in different countries and a global service can breach one while complying with another. It is reviewed on a stated cadence and out of cycle when the organization enters a new market, launches a service, signs a significant contract, or a law it is subject to changes; and where an obligation is not currently met, that is recorded as a gap with an owner and a date rather than left as an absence. The register reaches the privacy and civil liberties obligations attaching to the same information as well as the security ones, because a single system usually sits under both and a register carrying only one of them understates what the organization is bound by. It reaches the requirements that attach to the organization’s use of AI on the same terms - the laws, regulations and contractual terms bearing on how an AI system may be built, bought, deployed or used, each recorded with the jurisdiction and entity it applies to, what it actually requires, the control or process that discharges it, who is accountable and when the entry is next reviewed - so an obligation created by a system rather than by a dataset is understood, managed and documented rather than left to whoever built it. | A.5.31 | GOVERN-1.1 |
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 2 controls
- AI Governance Essentials not 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 not 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 42001 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 27001 and FedRAMP Rev5 Class D 55 shared controls
- ISO/IEC 27001 and FedRAMP Rev5 Class C 53 shared controls
- ISO/IEC 27001 and NIST SP 800-53 52 shared controls
- ISO/IEC 27001 and NIST Cybersecurity Framework 45 shared controls
- ISO/IEC 27001 and FedRAMP Rev5 Class B 41 shared controls
- ISO/IEC 27001 and NIST SP 800-171 35 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 27001. 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.