GDPR encryption requirements: at rest, in transit and key control

Regulators look at where a key lives relative to the data it protects. An encrypted database whose decryption key sits in the same configuration file, the same virtual machine image or the same backup set offers little protection, because anyone who obtains the data can usually obtain the key too. Article 32 asks for measures appropriate to the risk, so the question is whether the key store is separated from the data and protected to a level that matches the sensitivity of that data. Hardware security modules, a dedicated key management service or a sealed secrets vault are common answers, and the choice depends on the threat model and the platform.

• Separation from data: Keys should not be stored beside the ciphertext they unlock, in the same repository, bucket or backup.
• Generation source: Keys should be generated by a cryptographically secure random source inside the key store or HSM, not typed by hand or derived from guessable values.
• Algorithm and key length: Document the approved algorithms and key lengths, and confirm them against current guidance from the relevant national authority.
• Protected key material: Confirm which keys can be exported in plaintext, and disable export where the platform allows it.
• Key inventory: Maintain a register of every key, its purpose, the data it protects and the system that holds it.

Ask for the key inventory, the storage architecture diagram and the configuration showing that key material is not present in application code or backup archives.

The second concern is who can use a key. Shared administrator credentials are a common finding: when several engineers log in with one account to rotate or export keys, no one can prove who did what, and the same account can often read data and manage keys at once. Separation of duties means that the people who administer the data platform are not automatically the people who can decrypt it, and that key administration is logged and approved. This ties directly to the access control expectations of Article 32 and to the logging measures in Annex II.

• Named accounts: Each administrator uses a personal identity, with multi-factor authentication for key management actions.
• Role split: Separate roles for key custodians, key users and auditors, with no single role able to both change key policy and read the protected data.
• Dual control: Require two-person approval for export, deletion or policy changes on high-sensitivity keys, where the platform supports it.
• Logging of key use: Record every encrypt, decrypt, export and policy change with the identity, time and source.
• Provider access: Where a cloud or managed key service is used, confirm whether the provider's staff can access key material and under what controls.

Ask for the role matrix, a sample of key-usage logs and the list of accounts with key administration rights, with the last access review date.

Keys are replaced for several reasons: a suspected compromise, an administrator leaving, a cryptographic weakness or a planned policy cycle. Regulators do not expect a single fixed period from the GDPR itself, so the organization must set a rotation policy it can justify against its risk assessment and the state of the art. The harder problem is retirement. Old keys often remain able to decrypt backups, archives and replicas long after the production system has moved on, which means a compromised old key can expose data the organization believed was protected. Retirement must cover the data encrypted under the old key, not only new writes.

• Written rotation policy: Define the triggers for rotation and the planned interval, and record the reasoning in the risk assessment.
• Re-encryption plan: State how data encrypted under a retired key is re-encrypted or deleted, and in what order for backups and replicas.
• Compromise procedure: Describe how a suspected key compromise triggers immediate rotation and a breach assessment.
• Destruction evidence: Keep records showing when retired keys were destroyed, with the method used.
• Test restores: Confirm that backups remain readable after rotation, so that retirement does not cause data loss.

Ask for the rotation policy, the most recent rotation record and the destruction log for one retired key.

Recovery is the tension that gets missed. If a key is lost, the data it protects may become permanently unreadable, which is an availability failure under Article 32(1)(b) and (c). Organizations therefore often keep a recovery copy, called escrow, held by a custodian or stored in a sealed vault. The regulator concern is that the escrow itself becomes a single point of compromise: if a copy is held by a provider outside the EEA, or by a person with no separate approval, the protection of the primary key is weakened. Where keys are held outside the EEA, the transfer analysis in EDPB Recommendations 01/2020 becomes relevant, because the supplementary measure depends on keys being retained solely by the exporter or a trusted entity in the EEA or an equivalent jurisdiction.

• Escrow location: Record where every recovery copy is held, including the jurisdiction of any provider.
• Split custody: Require more than one custodian to reconstitute a key, so no single person can recover data alone.
• Recovery approval: Log each recovery request, the reason and the approver.
• Recovery drills: Test recovery on a schedule the organization sets, and record the outcome.
• Break-glass access: Store emergency credentials under documented conditions and review every use.

Ask for the escrow register with holding jurisdictions, the split-custody design and the record of the most recent recovery test.

Under the GDPR, the controller and any processor remain responsible for security of processing under Article 32. Encryption is one of the measures named there, and the choice of whether to use it, how strong it must be and who holds the keys is a decision your organization makes in light of the risk to individuals. No outside party can accept that risk on your behalf.

• Risk-based decisions: Decide which datasets need encryption at rest and in transit, based on your documented risk assessment and the nature of the data.
• Key ownership: Retain control of key generation, storage, rotation and destruction, or keep keys with a trusted entity in the EEA or an equivalent jurisdiction, and record who holds them.
• Breach posture: Decide how encryption status feeds your breach assessment under Articles 33 and 34, and keep the evidence that the keys were not compromised.
• Policies and records: Maintain the written encryption policy, the record of processing and your technical and organizational measures description.
• Contracts: Set encryption and key custody terms in processor agreements and transfer documentation.

Confirm that a named owner in your organization signs off on key custody decisions before any implementation work starts.

An implementation partner such as DeployOpen plans, configures, hardens and documents self-hosted systems within a written scope. For encryption, this work produces the technical configuration and the records that show it. The partner does not decide your risk appetite, does not hold your keys unless the written scope and your own governance explicitly allow it, and does not issue any assessment result.

• Configuration: Set up TLS for data in transit, encryption for databases, object storage and backups, and key management integration in your infrastructure.
• Hardening and testing: Verify cipher suites, certificate handling and key access paths, and document the results.
• Evidence preparation: Produce configuration exports, architecture diagrams, key inventories and change records that your team and assessors can review.
• Operational handover: Document rotation procedures, runbooks and the steps for key revocation and restore.
• Fixed scope: Agree deliverables and timelines in writing before work starts, and list which evidence the partner prepares and which your team must approve.

Ask for a written list of every system in scope and which encryption controls apply to each, so you can see what the partner delivers and what remains with your team.

An independent auditor, assessor or certification body is the only party that tests controls and issues a report or certificate. The GDPR itself requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance.

• Independent testing: The assessor samples configurations, reviews keys and access logs, and tests whether the stated controls operate as described.
• Scope of opinion: The assessor reports only on what was tested and within the agreed boundaries, which may differ from your internal view.
• Certification choice: Decide whether Article 42 certification adds value for your customers or contracts, and confirm the accreditation of any body you consider.
• Supervisory authority contact: Regulators, not assessors, decide compliance in enforcement, so keep evidence ready for them in their own process.
• Independence: Do not let the partner that built the controls also serve as the assessor.

Before engaging anyone, confirm with the certification body whether it is accredited for the scheme you need and what evidence it expects.