Crosswalk pair
GDPR and NIST AI Risk Management Framework, control by control
1 canonical control in Keel’s library satisfies clauses of both GDPR 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.
GDPR 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.
1
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
50
In Keel’s library for GDPR
2% of them also map to NIST AI Risk Management Framework.
27
In Keel’s library for NIST AI Risk Management Framework
4% of them also map to GDPR.
4
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
GDPR 2%
1 control of 50 in Keel’s library for GDPR also maps to NIST AI Risk Management Framework.
-
NIST AI Risk Management Framework 4%
1 control of 27 in Keel’s library for NIST AI Risk Management Framework also maps to GDPR.
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 | GDPR clauses | NIST AI Risk Management Framework clauses |
|---|---|---|
| Data protection impact assessment (DPIA) process Before a new processing activity begins — and before an existing one changes in a way that alters the risk it poses — it is screened for whether it is likely to result in a high risk to people, and where it is, an impact assessment of that specific processing is completed before the processing starts: describing the processing and its purposes, testing its necessity and proportionality against them, assessing the risks to the people affected, and setting out the measures, safeguards and security mechanisms that address those risks. The screen always returns a requirement, whatever else it weighs, in three cases: a systematic and extensive evaluation of personal aspects carried out by automated processing, profiling included, on which decisions are based that produce legal effects for the people concerned or similarly significantly affect them; processing on a large scale of the categories of data that carry extra protection, or of data about criminal convictions and offenses; and systematic monitoring of a publicly accessible area on a large scale. Where a data protection officer has been designated, their advice is sought while the assessment is being carried out, and what they advised is recorded alongside it rather than absorbed into the conclusion. Where it is appropriate to do so, the views of the people the processing affects, or of their representatives, are sought on what is intended - and where they are not sought, the reason is recorded, so “not appropriate” is a decision rather than a default; commercial and public interests and the security of the processing itself are protected in how that is done. The assessment does not end when it is signed: where necessary, and at least whenever the risk the processing presents changes, a review checks that the processing is actually being carried out in the way the assessment said it would be, which is a different question from whether the activity needs re-screening, and the outcome of that check is recorded. Where the processing is carried out by an AI system, the privacy risk the system itself creates is examined and documented as part of the same work, not only the privacy risk of the data going into it: what a trained model can memorize and later reveal, what can be re-identified or inferred about a person from its outputs even where no record of them is stored, and what the people whose data was used to build it are exposed to by its continuing to run. | Art.35(1), Art.35(2), Art.35(3), Art.35(7), Art.35(9), Art.35(11) | MEASURE-2.10 |
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 this control
- 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 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
- Google Play Families not reached
- HIPAA not reached
- ISO 9001 not reached
- ISO/IEC 27001 not reached
- ISO/IEC 42001 not reached
- NIST Cybersecurity Framework not 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
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 GDPR. 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.