Why does Article 32 require risk-based security rather than fixed controls for every processing activity?

Why Article 32 is a risk-based security standard, not a fixed checklist

Article 32 is written to match the actual risk created by a processing activity, not to impose one uniform control set on every controller or processor. The point is proportionality, because the same safeguard can be essential for one workload and unnecessary overhead for another. That is why the article ties security to context, impact, and likely harm rather than to a single mandatory recipe.

A fixed-controls model would miss the legal and operational reality that processing differs sharply by sensitivity, scale, and threat surface. A payroll system, a public marketing list, and a biometric database do not create the same exposure, so the security measures should not be identical. Risk-based security lets organisations direct stronger protections toward the processing that can actually cause material harm.

That logic also supports the specific measures Article 32 names. GDPR Article 32 expects encryption, pseudonymisation, resilience, and restoration measures to be selected because they reduce the relevant risk, not because they are always mandatory in the same form or at the same intensity. In practice, that makes security design evidence-led, instead of box-ticking.

How the risk-based model changes control selection in practice

The main decision is not whether a control is “good”, but whether it is proportionate to the processing risk. If the data is special category data, the environment is internet-exposed, or failure would materially affect individuals, then stronger technical and organisational measures are easier to justify. If the processing is low impact and tightly constrained, the same level of engineering burden may not be necessary.

This is why the article works as a control-selection standard rather than a universal technical specification. ISO/IEC 27001:2022 Information Security Management is a useful reference point here because it also relies on risk treatment and control choice, while CIS Controls v8 helps translate broad risk choices into concrete safeguard priorities. The practical lesson is that controls should be selected for the processing context, then implemented to a level that matches the threat.

Article 32 also implicitly recognises that “security” is not one control. NIST Cybersecurity Framework 2.0 is relevant because it organises security around govern, identify, protect, detect, respond, and recover, which mirrors how a risk-based Article 32 programme should be built. A controller does not just protect data, it also needs detection, continuity, and recovery measures that fit the likely impact of failure.

What practitioners should verify before calling Article 32 compliant

Article 32 compliance is strongest when the security choice is traceable to a documented risk assessment, not when a team can list familiar controls. The real question is whether the organisation can explain why one processing activity gets encryption at rest, stronger access restrictions, or recovery testing while another does not. That explanation should be defensible to auditors, privacy counsel, and operational owners.

It is also important to verify that risk decisions are revisited when the processing changes. A system can move from low to high risk because of a new dataset, a larger user base, a new third party, or a different attack path. ISO/IEC 27002:2022 Information Security Controls is useful as implementation guidance because it helps turn that review into specific control selection and operational practice.

What to verify: the risk assessment is current, the chosen measures match the actual exposure, and resilience and recovery are tested for the processing that would hurt people or the organisation most if it failed.

Practitioner takeaway: Article 32 is not asking for equal security everywhere, it is asking for defensible security where the risk is real, with enough evidence that the organisation can show why the chosen measures fit the processing.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• How should security teams choose between proxy-based SSE and data-layer controls for SaaS and AI risk?
• How should security teams measure whether browser-based security controls are reducing account takeover risk in SaaS environments?
• Why do static training and perimeter-based controls fail to reduce employee-driven security risk?