A GDPR recital that explains how security should be interpreted in practice. It emphasises risk evaluation, mitigation measures such as encryption, and proportionality based on the state of the art, implementation cost, and sensitivity of the data being protected. Practitioners often use it to support a risk based security methodology.
How Recital 83 Frames Security in GDPR Practice
Recital 83 explains that security under GDPR is not a fixed checklist. It is interpreted through risk, proportionality, and the practical context of the processing activity, including the sensitivity of the data and the cost and state of available safeguards.
Its value is that it turns security into an outcome-based judgement rather than a purely prescriptive one. That makes it the recital practitioners often cite when deciding whether a measure is appropriate, sufficient, and defensible for the circumstances.
Risk-Based Security and Proportionality
Recital 83 links security to the risks posed to the rights and freedoms of natural persons, so the expected level of protection rises as sensitivity, scale, and exposure increase. It also recognises that the “appropriate” measure is contextual, not absolute.
That proportionality principle matters because it prevents overreading GDPR as demanding identical controls everywhere. A low-risk processing activity and a high-risk one can justify very different security baselines, even if both remain compliant.
GDPR places this logic alongside broader security obligations, while the NIST Privacy Framework provides a practical way to think about privacy risk and governance in operational terms.
Encryption, State of the Art, and Cost Considerations
Recital 83 explicitly points to encryption as an example of a security measure, but not as a universal requirement in every situation. The recital instead points practitioners toward the state of the art, implementation cost, and the nature of the data as factors in deciding what is reasonable.
That combination is important because it acknowledges trade-offs. A measure may be technically strong yet disproportionate for a low-sensitivity use case, while in other cases the same measure may be the expected baseline because the consequence of exposure is much higher.
NIST AI Risk Management Framework is a useful external model for structured risk evaluation, and NIST Privacy Framework helps translate those judgement calls into concrete privacy outcomes.
What Recital 83 Means for Compliance Judgement
Recital 83 is often used to justify why compliance cannot be assessed by technical control presence alone. Practitioners must show that the chosen safeguards are aligned to the actual risk, the sensitivity of the information, and the expected impact if protection fails.
That means the legal and security question are closely related: the organisation needs a defensible rationale for why a chosen control set is enough, not just evidence that controls exist. In practice, the recital supports documentation, review, and accountability around security decisions.
GDPR is the authoritative context for that judgement, and EU NIS2 Directive is a useful comparator for how European regulation treats risk-based security and governance in adjacent contexts.
Common Misreadings of Recital 83
One common mistake is treating Recital 83 as if it were a standalone technical standard. It is not a control catalogue, and it does not list mandatory measures in exhaustive form. Instead, it explains how to interpret security obligations in context.
Another mistake is assuming that “risk-based” means discretionary or weak. In reality, the recital sets a higher burden on organisations to justify their choices, especially where data is sensitive, exposure is material, or a control failure would have serious consequences.
For implementation teams, the key lesson is to treat the recital as a decision principle that shapes security design, not as a narrow compliance citation. That keeps security measures tied to real risk rather than to rote policy language.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 32 — Security of Processing | Recital 83 interprets GDPR security obligations through risk and proportionality. |
| Art. 25 — Data Protection by Design and by Default | Recital 83 supports risk-based selection of protective measures during design and operation. | |
| Recommendation — Assess processing risk and choose security measures proportionate to the data and exposure. Build security choices into processing design using risk-based defaults and safeguards. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Recital 83 explicitly cites encryption as a representative security measure. |
| RA-3 — Risk Assessment | Recital 83 requires evaluating threats, sensitivity, and control cost before selecting safeguards. | |
| PL-8 — Information Security Architecture | Recital 83 depends on proportionate, context-aware security architecture choices. | |
| Recommendation — Use cryptographic protection where risk justifies it and manage it as part of the control set. Perform a risk assessment before deciding which security measures are appropriate. Align security architecture to the sensitivity and exposure of the processing activity. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org