Crosswalk pair
NIST AI Risk Management Framework and NIST Cybersecurity Framework, control by control
2 canonical controls in Keel’s library satisfy clauses of both NIST AI Risk Management Framework and NIST Cybersecurity Framework. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
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.
27
In Keel’s library for NIST AI Risk Management Framework
7% of them also map to NIST Cybersecurity Framework.
50
In Keel’s library for NIST Cybersecurity Framework
4% of them also map to NIST AI Risk Management Framework.
7
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
NIST AI Risk Management Framework 7%
2 controls of 27 in Keel’s library for NIST AI Risk Management Framework also map to NIST Cybersecurity Framework.
-
NIST Cybersecurity Framework 4%
2 controls of 50 in Keel’s library for NIST Cybersecurity Framework also map to NIST AI Risk Management Framework.
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 | NIST AI Risk Management Framework clauses | NIST Cybersecurity 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. | MANAGE-4.2 | ID.IM-03 |
| 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. | GOVERN-1.1 | GV.OC-03 |
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 — an absence, not a judgment about that standard.
Also reached by these 2 controls
- AI Governance Essentials
- Amazon Appstore Child-Directed Apps
- Apple App Store Kids Category
- CIS Critical Security Controls
- COPPA
- ESG Essentials
- EU AI Act
- GDPR
- Google Play Families
- HIPAA
- ISO 9001
- ISO/IEC 27001
- ISO/IEC 42001
- NIST SP 800-171
- NIST SP 800-53
- PCI DSS
- SOC 2
- SOX (Sarbanes-Oxley) Section 404
- US Employment Law - Federal Baseline
Nearby pairs
- NIST Cybersecurity Framework and ISO/IEC 27001 45 shared controls
- NIST Cybersecurity Framework and NIST SP 800-53 33 shared controls
- NIST Cybersecurity Framework and SOC 2 26 shared controls
- NIST Cybersecurity Framework and NIST SP 800-171 22 shared controls
- NIST Cybersecurity Framework and PCI DSS 20 shared controls
- NIST Cybersecurity Framework and SOX (Sarbanes-Oxley) Section 404 20 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, NIST Cybersecurity Framework mostly lights up controls you already built for NIST AI Risk Management Framework. 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 Cybersecurity Framework to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.