Skip to content
← Back to the toolkit
PossessUseDisposeDataSoftwareHardwareOrganisational

Encryption key custody

Who controls key material, key policy, decryption requests and revocation, and which technical or operational paths can still reach plaintext.

Key custody can reduce provider access and strengthen revocation, but only a review of every path to plaintext shows what the design actually protects.

Encryption claims need a threat model. Disk encryption, application-layer encryption and an external key service protect different boundaries. A product label is not evidence of exclusive control.

Review every path to plaintext:

  • where key material is generated, stored, backed up and recovered;
  • who controls policy and can request, approve or revoke decryption;
  • which applications, managed services, operators and support processes receive plaintext;
  • whether plaintext or usable keys can remain in memory, logs, caches, snapshots or downstream copies;
  • what happens when the customer key service, provider or network is unavailable.

Provider-managed, bring-your-own-key and hold-your-own-key are useful descriptions only after the implementation is known. An external key store can give the customer a strong revocation point, while a managed workload may still process plaintext during normal operation. Lawful-access exposure also depends on the entities, jurisdictions, contracts and technical access paths in scope and needs qualified legal review.

Key revocation can support cryptographic erasure when every relevant copy is encrypted only under key material that is destroyed or made permanently unavailable, and when recovery copies, derived data and downstream paths are addressed. That result needs evidence; revoking one key label does not by itself prove deletion.

Stronger customer custody adds operational responsibility. Availability, backup, recovery, separation of duties and exercised failure procedures must be designed together with the cryptography.

Common misconceptions

The data is encrypted at rest, so the provider cannot read it.

At-rest encryption may protect media while the running service, administrators, recovery paths or retained copies can still reach plaintext. The threat model and implementation decide what is protected.

BYOK or HYOK proves that we alone control decryption.

Product labels cover different designs. Verify where key material exists, which service can request decryption, whether a provider can bypass or cache the path, and what happens during support and recovery.

Put this to work

Apply this checklist

Can you leave? The exit-readiness checklist

Twelve checks that tell you whether you could actually move off a critical supplier, before you need to. Print it, take it into a stand-up, and mark honestly.

Ask your AI

Review who can access unencrypted data

Maps the stated technical, operational and legal paths to plaintext, distinguishes key policy from custody and identifies the evidence still missing.

Questions for your vendor

Questions to ask a vendor before you sign

The questions that make a supplier prove data sovereignty, and what a real answer versus an evasive one sounds like. Copy them into an RFP, or read them down a vendor call.

Related concept

Data portability

The ability to extract the data and context required within the stated scope in a documented, usable form and transfer or load them into an independently chosen system.

Related concept

The four layers

The three rights apply across Data, Software, Hardware and an Organisational layer described through data compliance and data ethics.

Copyright 2026HOIST IT. All Rights Reserved