The regime prescribes almost no specific controls, which organisations read as latitude. It is the opposite: it means you have to justify what you chose.
What “appropriate” is measured against
Appropriateness is assessed against the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risk to individuals — its likelihood and severity.
Two consequences:
- It moves. A control that was appropriate five years ago may not be now, because the state of the art changed. Nothing formally expires, but the standard rises.
- It scales with risk to people, not with the size of the organisation. A small organisation processing health data is held to a higher standard than a large one processing mailing-list addresses. “We are a small team” is not a defence for the sensitivity of what you hold.
The measures named in the text are indicative, not a checklist: pseudonymisationPseudonymisationReplacing identifiers so data cannot be attributed to a person without a separately held key. Still personal data — unlike anonymisation. and encryption; ongoing confidentiality, integrity, availability and resilience; the ability to restore availability after an incident; and a process for regularly testing and evaluating effectiveness.
That last one is the one most often absent. Controls that were implemented and never tested are, evidentially, controls you cannot show work.
Design and default are two obligations
By design means data protection is built into how processing is determined, from the point you decide to do it — not bolted on before launch. In practice it means the impact assessment happens while the design can still change.
By default is narrower, more concrete, and far more frequently breached: by default, only personal dataPersonal dataAny information relating to an identified or identifiable person: names, IDs, location, online identifiers, and combinations that single someone out. necessary for each specific purpose is processed. That applies to the amount collected, the extent of processing, the retention period, and accessibility. In particular, personal data must not by default be made accessible to an indefinite number of people without the individual’s intervention.
Translated: the out-of-the-box settings must be the privacy-protective ones. A product that is compliant only after a user changes six settings does not meet this, and “users can opt out” is not a defence — the default is the obligation.
Where security failures become principle failures
A regulator assessing an incident rarely stops at Art 32. The same facts usually engage:
- Art 5(1)(f) — integrity and confidentiality, the principle behind the article
- Art 5(1)(e) — because the data exposed had frequently been retained past its purpose
- Art 5(1)(c) — because more was held than was needed
- Art 5(2) — because the assessment justifying the controls could not be produced
This is why security work and data governance work are not separable. The most effective security measure is usually not holding the data: what was deleted on schedule cannot be breached, and what was never collected cannot be exposed.
Organisational measures are half of it
The phrase is “technical and organisational”, and the organisational half is where most real incidents originate. It covers access management and leavers, training, clear instructions to staff and processorsProcessorProcesses on the controller’s instructions — cloud hosts, payroll bureaus — with its own security and breach duties., incident response that people have actually rehearsed, supplier assurance, and a route for raising concerns.
Access control deserves particular attention because it is the control most often nominally in place and practically absent — permissions granted for a project and never revoked, shared accounts, and administrative access far wider than anyone would defend if asked.
Evidencing it
Under accountability you must be able to demonstrate appropriateness. What that means in practice:
- a written record of what you implemented and why it was proportionate to the risk
- the date, and the trigger for the next review
- results of testing, including what failed and what changed as a result
- for suppliers, what you checked before onboarding and what you check periodically
The organisation that survives an incident well is not the one that was never breached. It is the one that can show, from records written beforehand, that it assessed the risk and made defensible choices.