GDPR technical requirements: what the regulation actually asks of a system, and what it leaves to you

Published , updated

GDPR technical requirements is a phrase that promises a checklist of controls and the regulation declines to provide one. It names no encryption standard, no password rule and no logging format. What it does set out is a small number of properties a system has to have, and for a small company those translate into a short list of things that are usually missing.

Appropriate measures, judged against risk

The text asks for technical and organizational measures appropriate to the risk, and gives examples rather than mandates: pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore availability after an incident, and a process for regularly testing and evaluating the measures. Appropriate is doing real work in that sentence: what is proportionate for a mailing list of a thousand people is not what is proportionate for health records.

By design and by default

Two related duties. By design means privacy considerations are built into a system when it is built, not added afterwards. By default means that, out of the box, only the personal data necessary for each purpose is processed: fields that are optional are actually optional, retention timers are on rather than off, and sharing is not enabled by default. The default half is the one that shows up in code review, and it is usually a settings decision rather than an architecture one.

The four things small systems usually lack

A way to find every record about one person across the systems, which is what an access or deletion request needs. A deletion that actually deletes, including in the search index, the exports and the analytics copy. A record of consent that stores what was shown and when rather than a flag. And logging good enough to notice a breach and to describe it within the notification window, which is seventy two hours from awareness for a notifiable personal data breach.

What to build first

The person-level search, because every other obligation leans on it. Give every system a stable key for a person, and write the query that finds their records in each. Then the deletion path that uses the same query. Then the consent record. None of that is exotic engineering, and all of it is far cheaper to add while the systems are small than after a request has arrived with a deadline attached.

Questions people ask about GDPR technical requirements

Is encryption required?

It is named as an example of an appropriate measure rather than a requirement in every case. In practice encryption in transit is universal and encryption at rest is expected for anything sensitive, and their absence would need explaining.

What is the breach notification deadline?

A notifiable personal data breach is reported to the supervisory authority without undue delay and where feasible within seventy two hours of becoming aware of it. Individuals are told where the risk to them is high.

Does the regulation require a specific password policy?

No. It requires measures appropriate to the risk, which leaves the specifics to you and to whatever standard your customers' security reviews expect.

Sources

Related answers

Keep the request record: $10 a monthStart the request record