Article 32: what "appropriate technical measures" actually means

Article 32 names four measures and then hands the decision back to you via risk. Here's how to read it, and what the ICO looks for when it asks what you did.

Article 32 is the security obligation, and it frustrates people because it refuses to give a list. It requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk, which reads like a circular definition until you notice what it does next.

It names four things, then tells you how to decide how much of each you need.

The four named measures

Article 32(1) lists these as appropriate where relevant:

• Pseudonymisation and encryption of personal data.
• The ability to ensure 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 after a physical or technical incident.
• A process for regularly testing, assessing and evaluating the effectiveness of the measures.

The fourth is the one most often skipped. It is not enough to have measures. You have to have a process that checks they still work, and the check has to happen more than once.

How "appropriate" gets decided

The same paragraph tells you what to weigh: the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, against the risk to the rights and freedoms of natural persons.

Two things follow from that. First, appropriate is relative to your processing, so a ten-person company holding customer email addresses is not held to the standard of a hospital. Second, cost is explicitly a permitted consideration, which is unusual in the regulation and worth knowing.

Article 32(2) narrows the risk assessment to what matters: the risks presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

Encryption is named, not mandated. The obligation is to consider it and to be able to explain your decision. "We considered it and here is why we did something else" is an answer that holds up. Silence is not.

Where this comes apart in practice

Most organisations can describe their security measures accurately for the systems they designed. The database is encrypted at rest, access is role-based, backups are tested. All true, all evidenced.

The difficulty is that Article 32 attaches to personal data, not to systems. If a copy of that data is sitting in a spreadsheet on a laptop, in a mailbox attachment, or in a folder someone made during a migration three years ago, the measures protecting the database do not reach it. The risk assessment was done against an architecture, and the data escaped the architecture.

This is the gap that turns a contained incident into a reportable one. The breach is not in the system you hardened.

What to hold as evidence

The ICO's security guidance is organised around being able to show what you did and why. In practice that means holding:

1. 1A written risk assessment covering the four harms named in Article 32(2), for each significant category of processing.
2. 2The measures chosen, with a note on the ones considered and rejected, including cost reasoning where that drove the decision.
3. 3Dated results from the regular testing that Article 32(1)(d) requires.
4. 4An accurate picture of where the personal data actually sits, because every measure above is scoped to that.

How EmberHound fits

EmberHound scans enrolled company devices and reports where personal data is held, by category and location. That gives the risk assessment a real scope rather than an assumed one, and gives the periodic testing obligation something to measure: has personal data appeared anywhere new since the last review.

Scanning runs on the endpoint. Only masked previews and salted fingerprints are uploaded, never raw file content. Mailbox, OCR and external drive scanning are add-ons.

This article is general information, not legal advice. Confirm the obligations that apply to your organisation before acting on it.