GDPR Technical Controls for Data

Encryption: What Actually Earns the Article 34 Exemption

Article 32(1)(a) lists encryption first among its two named examples, and Article 34 gives it real legal weight, not just a security best practice: if personal data involved in a breach was rendered 'unintelligible to any person who is not authorised to access it, such as encryption,' the controller does not have to notify the affected individuals at all. That's a concrete legal outcome tied to a technical state, which makes it worth getting the technical state right instead of treating encryption as a single checkbox on a managed database's settings page. The gap that actually shows up in enforcement is rarely 'no encryption anywhere.' It's encryption that doesn't cover the scenario that actually happens: full-disk encryption on the primary instance while a manual snapshot sits unencrypted in object storage, or a database encrypted at rest while the application server holding a live, decrypted connection is the thing that actually gets compromised.

Cleartext or weakly hashed password storage, unpatched known vulnerabilities, and unencrypted transmission channels are the specific, recurring patterns cited across recent Article 32 enforcement actions, not exotic attacks, ordinary gaps. The other half of the picture is key custody. Encryption that sits next to its own decryption key, in the same database or the same backup, satisfies the word 'encrypted' without satisfying any real threat model.

Keys need to live in a separately access-controlled store, a KMS, not a config table, so that whoever can read the encrypted data cannot, by that access alone, also decrypt it.

Pseudonymisation Is Not Anonymisation, and GDPR Still Applies

GDPR defines pseudonymisation precisely: processing personal data so it 'can no longer be attributed to a specific data subject without the use of additional information,' with that additional information 'kept separately' and itself protected under Article 4(5). That data is still personal data. Pseudonymising a dataset does not take it out of GDPR's scope, it reduces risk and satisfies part of Article 25's by-design requirement, but every obligation around data subject rights, breach notification, and lawful basis still applies to it in full.

The practical design question the Regulation doesn't answer directly is 'pseudonymised for whom.' The European Data Protection Board's own dedicated guidance on this, Guidelines 01/2025, was published for consultation in January 2025 and, as of this writing, is still not finalized: it's listed as forthcoming in the EDPB's own 2026-2027 Work Programme. Until it lands, the operative framing is what the draft calls the pseudonymisation domain: the population of people who could plausibly access both the pseudonymised data and the separately-held re-identification key, or who could plausibly combine the pseudonymised data with something else, a public dataset, an internal report, to re-identify someone anyway. ENISA's own technical guidance is the concrete counterpart: hashing, hashing with a key or salt, encryption-based approaches, tokenization, and for harder cases, secure multi-party computation, each evaluated against specific attacks, brute force, dictionary search, guesswork.

ENISA's own conclusion is worth taking at face value: there's no single technique that works for every case. Pseudonymising the obvious identifier, a name or an email, while leaving a combination of quasi-identifiers intact, a postcode, a birth date, a rare job title, is the single most common way pseudonymisation looks complete on paper and fails in practice.

Database-Level Access Control, Not Just the Application

Article 32(1)(b) requires 'ongoing confidentiality,' and the most common way that requirement quietly fails is relying entirely on application code to enforce it: a WHERE tenant_id = ? clause that every service, every ad-hoc analytics query, and every new engineer has to remember to include, forever, with zero structural backstop if one of them doesn't. Row-level security, built into PostgreSQL and most major database engines, moves that enforcement into the database itself.

A policy restricts which rows a given role can select, update, or delete, independent of which application code issues the query. A misconfigured microservice or an analyst's raw SQL client can't expose another data subject's rows even if it tries, because the restriction isn't optional at the query layer, it's structural. The verification step matters as much as the policy itself: connect as the restricted role and confirm a query that should return zero rows for another tenant or subject actually does, at the database layer, independent of any application code written around it.

-- Enable row-level security on a table holding personal data
ALTER TABLE customer_records ENABLE ROW LEVEL SECURITY;

-- Restrict each role to its own tenant's rows, enforced at the database
CREATE POLICY tenant_isolation ON customer_records
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

-- Confirm it actually blocks cross-tenant access
SET app.tenant_id = 'tenant-b-uuid';
SELECT * FROM customer_records WHERE tenant_id = 'tenant-a-uuid';
-- Returns zero rows regardless of the WHERE clause, because RLS enforces it

Right to Erasure Across Backups and Replicas

Article 17 requires erasure 'without undue delay,' but the article says nothing about how to reach every place a data subject's record actually lives: the primary database, read replicas, search indexes, caches, and however many backup generations a disaster-recovery policy retains. Deleting from the system of record and calling the request closed is the single most common technical gap in erasure handling, and it's a compliance risk in its own right, the inability to delete data from backups can itself be treated as a violation, independent of whether the primary deletion worked. Crypto-shredding is the pattern that makes backup erasure tractable without rewriting every historical backup file: encrypt each data subject's records, or a partitioned subset of backups, with its own key, and destroy that key on erasure.

The data becomes permanently unrecoverable without ever touching the backup archive itself. Process failure is just as common as the architecture gap, and a real 2026 enforcement action shows exactly what it looks like: France's CNIL fined a company €300,000 in July 2026 after finding that of 265 erasure requests received in a single year, twelve were never processed at all and 166 people were never told what action had been taken. The technical deletion path can work perfectly and the organization can still get fined, if nobody's tracking whether every request that comes in actually gets acted on inside the statutory window.

-- Erasure fan-out, triggered by a single subject-level request
BEGIN;
DELETE FROM customer_records WHERE subject_id = $1;
DELETE FROM support_tickets WHERE subject_id = $1;
-- Backups: destroy the per-subject key instead of rewriting archives (crypto-shredding)
DELETE FROM key_vault.subject_keys WHERE subject_id = $1;
COMMIT;

-- Verify: a DR restore from a pre-erasure backup must not reintroduce the row

Data Portability: What 'Machine-Readable' Actually Means

Article 20 requires that data provided by the subject be handed back in a 'structured, commonly used and machine-readable format,' and, where technically feasible, transmitted directly to another controller. Two details get missed often enough to matter. First, machine-readable rules out a rendered PDF or a formatted report, it means JSON or CSV a receiving system could actually parse without a human retyping it.

Second, the right is scoped to data the subject provided, not to everything a controller has since derived or inferred about them, an export that quietly includes internal scoring, segmentation, or behavioral inference goes beyond what Article 20 asks for and beyond what most engineering teams intend to hand over. Building this as a dedicated, tested export path, not an engineer running an ad hoc query under the pressure of a live request, is what keeps the format and the scope both correct under deadline.

Cross-Border Transfers Need a Technical Measure, Not Just a Signed Contract

Standard Contractual Clauses get treated as a self-sufficient box to check for any transfer of EU personal data outside the EEA. Since the Court of Justice's 2020 Schrems II ruling, they aren't. The European Data Protection Board's own recommendations, finalized in November 2020, require a six-step transfer-risk assessment and, where risk is identified, technical supplementary measures layered on top of the contract, named explicitly as forms of encryption with encryption keys kept beyond the reach of relevant public authorities, and pseudonymisation that does not permit re-identification.

The failure mode that defeats this in practice is subtle: encrypting data in transit to a processor in a third country while that processor, or its own cloud provider, still holds the decryption key and remains subject to that country's legal process. The encryption is real, the protection it was supposed to add isn't, because the key never left the reach it was meant to escape. For any transfer outside the EEA, the concrete check is not 'do we have SCCs signed,' it's whether a documented transfer-risk assessment exists, and, wherever it flags risk, whether the entity holding the encryption or pseudonymisation key genuinely sits outside the destination jurisdiction's compelled-access reach.

Data Minimization by Default, Not by Cleanup

Article 25(2) is specific about the mechanism: 'by default, only personal data which are necessary for each specific purpose of the processing are processed.' By default, not as an opt-in a user has to configure, and not as a filter applied after the fact. A broad internal data model that captures more than any given consumer needs, relying on application code to trim the response later, satisfies neither the letter nor the intent, the next engineer who adds a new internal tool against that same data model inherits the same over-collection, one more time, with no structural reason not to. The useful design question for any new schema, API response, or pipeline output touching personal data is not 'can we filter this down' but 'does this field need to exist in this output by default.' A gap between what's structurally necessary and what's actually collected or exposed is a minimisation finding regardless of whether anything has gone wrong with it yet, which is exactly why it's cheap to fix early and expensive to unwind after a system has been built around the wider shape.

Audit Logging That Would Survive an Article 32(1)(d) Test

Article 32(1)(d) requires 'a process for regularly testing, assessing and evaluating the effectiveness' of technical measures, which is unrunnable without a log of who actually accessed what. The gap here tends to be less about whether logging exists and more about what it actually covers: application-level logging that captures every API call but misses the case where someone with direct database credentials bypasses the application layer entirely, which is exactly the access Article 32(4) is aimed at, personnel must not process data 'except on instructions from the controller.' A log that's actually useful captures authentication events, schema changes, and access to tables holding personal data, at the database layer, shipped somewhere separate from the database itself, so a compromised database credential can't also be used to erase the record of its own use. The test worth running periodically isn't 'is logging on,' it's picking a sampled personal-data record and confirming every read and write against it, and the authenticated identity behind each one, can actually be reconstructed.

Related: Data Governance and Security Engineering