What GDPR is mapped to,
and why those frameworks.
Every GDPR IT requirement is mapped to the controls that satisfy it, across 3 frameworks. The frameworks are not arbitrary — each one covers a layer the others cannot reach. This page explains the reasoning, not just the list.
GDPR maps to 3 frameworks, each covering a different layer.
A regulation written in legal prose has to land somewhere specific before an engineer can act on it. One framework is never enough: the cloud account, the security programme, and the application code are three different places where an obligation can be satisfied — or missed.
Cloud Security (AWS, Azure, GCP)
Where the data actually sitsMost GDPR obligations resolve to a storage, transit, or access decision in a cloud account. Article 32 asks for encryption; the answer is a KMS key policy and a TLS setting, in a named provider. Mapping to cloud controls is what turns "appropriate technical measures" into something an engineer can implement and an auditor can inspect.
NIST CSF
The security programme an auditor recognisesGDPR does not name a security framework, and supervisory authorities do not accept "we built our own" as evidence on its own. NIST CSF gives the obligations a shape reviewers already read — identify, protect, detect, respond, recover — so the same implementation defends itself in an audit without being re-explained.
OWASP Top 10
The application layer, where personal data is handledCloud and programme controls do not reach into application code. Broken access control and injection are how personal data actually leaks, and they are application defects. OWASP Top 10 is the vocabulary engineers already use for them, so the mapping lands in the review where it will be acted on.
Requirement, then control, then configuration, then evidence.
A mapping is not a keyword match between a regulation and a framework. Each GDPR IT requirement is interpreted against the frameworks above, mapped to the control that actually satisfies it, and carried through to the configuration that implements it and the evidence that proves it ran. Where an article is purely legal — a notification duty, a record-keeping obligation with no technical surface — it carries no control mapping, and is marked as such rather than padded with a loose association.
That last part matters more than it sounds. A mapping layer that claims full coverage of every article is either stretching definitions or counting things that do not implement anything. Ours states where the technical surface ends.
Where to go from here.
The EU AI Act mappings share this cloud and security-programme foundation, then diverge above it — the AI Act does not use the classic web OWASP Top 10 at all. A useful contrast if you are in scope for both. For the scope question itself, the GDPR checker returns your role and what applies before any implementation work starts.
See the mapping concept end to end.
The concept pages explain how a legal obligation becomes a provider-specific control, with GDPR as the worked example.