Who holds the keys? A key custody checklist for EU personal data

If you rely on encryption to protect personal data held by a vendor in a third country, key custody decides whether the argument holds. The EDPB's backup use case requires keys retained solely under the exporter's control, or an entity it trusts in the EEA or an equivalent jurisdiction. This checklist turns that into engineering questions.

The checklist

1. Encrypt before upload. The data leaves your system already encrypted, using a client side library you control, not a vendor setting you cannot inspect.
2. Keys generated on your side. Create them in a key management service or hardware module in a region you chose.
3. No vendor copy of the key. The vendor stores ciphertext only. If their service can decrypt, it is not the measure the EDPB describes.
4. Key location and operators. Know which country the key store is in and which staff, including your cloud provider's, can use it.
5. Strength and lifetime. The EDPB asks for state of the art algorithms and key lengths that take into account how long the data must stay confidential. Record the algorithm, parameters and review date.
6. Verified importer identity. Authenticate the endpoint before sending, for example with certificate pinning or mutual TLS.
7. Maintained, correct implementation. Use well reviewed libraries, keep them patched and watch them for vulnerabilities.
8. Key lifecycle. Rotation, revocation, backup and destruction are written down and tested. Rotating without downtime is worth practising.
9. Access logs. Every key use is logged and reviewed.

Where this breaks

• The vendor offers search, analytics or AI features over your data. That needs readable data, which moves you to the EDPB's cloud processing case, where it says no effective technical measure can be envisioned if problematic access laws apply.
• Keys are held in an account that the vendor or its parent can administer.
• Support staff can request a key export "to help debug".

Customer managed keys are not automatically this

Many cloud services offer customer managed keys. They help with control and revocation, but the service still decrypts data to process it, so the question stays whether the provider needs access in the clear. Check the provider's documentation for what they do and do not protect against.

Document it

Write a one page record per vendor: data covered, encryption design, key location, key operators and last review. It becomes part of your transfer file and a ready answer for security questionnaire encryption questions.

A worked example

Say you back up customer exports to object storage run by a vendor in another country. The safe design encrypts each file on your servers with a data key, wraps that key with a master key in your own key store in the EU, and uploads only ciphertext. The vendor never receives the master key. If a legal demand reaches the vendor, it can hand over encrypted blobs and nothing more.

Now change one thing: the vendor adds a feature that indexes file contents for search. To do that it must decrypt, so the keys have to be shared, and the design no longer matches the backup use case. The question to ask before enabling any new feature on an encrypted store is simply whether it needs readable data.

Review cadence

Revisit custody when a vendor changes ownership, adds features, or changes sub-processors. Put the review date in your transfer map so it does not depend on memory.

Quick check

Sources

• EDPB Recommendations 01/2020, Use Case 1

This is educational content, not legal advice.

Last reviewed: 19 October 2026.