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.

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 2016/679 2%

    1 control of 50 in Keel’s library for GDPR also maps to NIST AI Risk Management Framework.

  • NIST AI Risk Management Framework 1.0 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.

GDPR and NIST AI Risk Management Framework controls that satisfy both, with the clauses each maps to
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 offences; 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 — an absence, not a judgment about that standard.

Also reached by this control

  • AI Governance Essentials
  • Amazon Appstore Child-Directed Apps
  • Apple App Store Kids Category
  • CIS Critical Security Controls
  • COPPA
  • ESG Essentials
  • EU AI Act
  • Google Play Families
  • HIPAA
  • ISO 9001
  • ISO/IEC 27001
  • ISO/IEC 42001
  • NIST Cybersecurity Framework
  • NIST SP 800-171
  • NIST SP 800-53
  • PCI DSS
  • SOC 2
  • SOX (Sarbanes-Oxley) Section 404
  • US Employment Law - Federal Baseline

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.