The GDPR security baseline: what Article 32 requires, and what it deliberately does not say

The short answer

GDPR Article 32 requires controllers and processors to implement technical and organisational measures ensuring a level of security **appropriate to the risk**. It deliberately prescribes no checklist — the standard is contextual, judged against the state of the art, the cost of implementation, the nature and scope of processing, and the likelihood and severity of risk **to the rights and freedoms of natural persons**.

That last phrase is the one that changes everything. **GDPR does not measure risk to your organisation. It measures risk to the people whose data you hold.** A control set built around business impact will systematically mis-prioritise, because the two risk models diverge precisely where personal data is concerned.

Who this applies to

Every controller and every processor handling personal data of individuals in the EU, regardless of where the organisation is established, where the processing falls within the material and territorial scope of Regulation (EU) 2016/679.

Unlike NIS2 or DORA, there are no sector thresholds and no size exemptions for Article 32. The obligation scales with risk, not with headcount.

What Article 32 actually names

Article 32(1) names four measures **as appropriate**, not as mandatory:

Two points on how to read this.

**"As appropriate" is not "optional".** It means the measure applies where it fits the risk. A supervisory authority examining a breach of unencrypted special-category data will ask why encryption was not appropriate, and the burden of answering sits with the controller under Article 5(2) accountability.

**The fourth item is the one most often absent.** Having controls is not the obligation; being able to demonstrate that you regularly test and evaluate their effectiveness is. This is where most Article 32 findings originate — not from missing controls, but from no evidence that anyone verified they work.

Article 32(2) directs the assessment specifically at the risks of **accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to** personal data. Article 32(4) requires controllers and processors to ensure that anyone acting under their authority processes data only on instructions.

• **pseudonymisation and encryption** of personal data;
• the ability to ensure the ongoing **confidentiality, integrity, availability and resilience** of processing systems and services;
• the ability to **restore availability and access** to personal data in a timely manner in the event of a physical or technical incident;
• a process for **regularly testing, assessing and evaluating** the effectiveness of the measures.

The articles Article 32 does not work without

**Article 5(1)(f)** — integrity and confidentiality as a processing principle. Article 32 is the operational expression of it, and Article 5(2) makes the controller responsible for demonstrating compliance.

**Article 24** — the controller must implement appropriate measures and be able to demonstrate that processing complies. This is the accountability hook that turns "we have security" into "we can prove it."

**Article 25** — data protection **by design and by default**. Measures at the time of determining the means of processing, and by default only data necessary for each specific purpose is processed. This is an architecture obligation, not a security-tooling one, and it cannot be retrofitted convincingly.

**Article 28** — processors. The contract must impose the Article 32 measures on the processor, restrict sub-processors, and require assistance to the controller. A processor's own security posture does not discharge the controller's obligation.

**Article 35** — a data protection impact assessment where processing is likely to result in high risk. The DPIA is where the Article 32 risk analysis is actually documented for high-risk processing.

Breach notification — and why it is not the same 72 hours as NIS2

**Article 33** — the controller notifies the competent supervisory authority **without undue delay and, where feasible, not later than 72 hours after having become aware** of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where notification is later than 72 hours, it must be accompanied by reasons for the delay.

**Article 34** — where the breach is likely to result in a **high risk** to rights and freedoms, the controller communicates it to the affected data subjects without undue delay, in clear and plain language.

**Article 33(2)** — a processor notifies the controller without undue delay after becoming aware. No 72-hour figure applies to the processor; the standard is stricter in effect, because the controller's clock is already running.

**The comparison that matters operationally**

| | GDPR Article 33 | NIS2 Article 23 | |---|---|---| | Trigger | personal data breach with risk to rights and freedoms | significant incident | | First deadline | **72 hours** to the supervisory authority | **24 hours** early warning to the CSIRT | | Recipient | data protection supervisory authority | CSIRT or competent authority | | Second stage | — (supplementary information in phases if needed) | 72-hour incident notification | | Final stage | — | one-month final report | | Individuals | Article 34, where **high** risk | Article 23(1), recipients of the service, where appropriate |

**One event can trigger both, with different recipients, different content and different clocks.** A ransomware incident affecting a NIS2 essential entity that encrypts customer records is a significant incident *and* a personal data breach. Filing one does not discharge the other, and the 24-hour NIS2 warning falls due long before the GDPR notification.

Any incident runbook that does not begin with a determination of **which regimes this event triggers** will file late under at least one of them.

What transfers to and from the other regimes

**Transfers well.** The asset and data inventory, access control, logging, encryption, backup and restoration capability, and supplier due diligence all serve GDPR Article 32, NIS2 Article 21 and DORA Articles 9 to 12 simultaneously. Build once.

**Does not transfer.** The **risk model**. NIS2 and DORA assess risk to service continuity and to the entity; GDPR assesses risk to the rights and freedoms of individuals. The same control can be adequate under one and inadequate under the other — a resilient system that quietly over-collects personal data passes an availability test and fails Article 25.

**Also does not transfer.** The DPIA. Nothing in NIS2 or DORA produces it, and no security risk assessment substitutes for it.

Detail on evidence reuse: one evidence set across five EU regulations.

Exposure

Article 83(4) provides administrative fines of up to **€10 000 000, or 2% of total worldwide annual turnover** of the preceding financial year, whichever is higher, for infringements of obligations including Articles 25, 28, 32, 33 and 35.

Article 83(5) provides the higher tier — up to **€20 000 000, or 4%** — for infringements of the basic principles including Article 5, the lawfulness of processing, and data subjects' rights.

A security failure therefore commonly attracts the 2% tier under Article 32, and can reach the 4% tier where it also constitutes a breach of the Article 5(1)(f) principle.

What to have in place

1. A **risk assessment framed around individuals**, not only around the business — with the reasoning written down. 2. **Evidence of regular testing** of the measures' effectiveness. Article 32(1)(d) is an obligation, not a maturity aspiration. 3. **A breach runbook with a regime-determination step first**, covering the GDPR 72-hour clock, the NIS2 24-hour clock where applicable, and the CRA Article 14 clock for product manufacturers. 4. **Processor contracts carrying the Article 28 provisions**, including sub-processor control and audit assistance. 5. **DPIAs for high-risk processing**, maintained rather than filed once. 6. **Article 30 records of processing**, kept current — they are the first thing a supervisory authority asks for, and the fastest way to demonstrate or destroy credibility.

Tools available on NexCyber

• Free applicability assessment — establish scope across EU regulations
• Compliance responsibility mapper — RACI by role
• Penalty calculator — maximum exposure by regulation

Further reading

→ One evidence set across five EU regulations → NIS2 incident reporting timelines → NIS2 × CRA overlap — the six shared obligation areas → The EU regulatory reference set

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Article 32 sets a contextual standard: what is appropriate depends on your processing, and supervisory authorities in different Member States publish their own guidance. Consult your supervisory authority, your DPO, or a qualified adviser.*