Document encryption and key custody: what customer-controlled keys protect
Map encryption layers, key authority, rotation, recovery, and the components that still handle readable content.
Evaluate document encryption by naming the protected layer, key authorities, and remaining plaintext paths. Customer-controlled keys can improve custody without excluding every application or operator access route. Test rotation, outage, historical readback, and recovery before stating what the design protects and who can still unlock content.
Separate the protection layers
Record encryption for browser traffic, internal service traffic, stored objects, databases, backups, and exports. Identify the actual mechanism and configuration evidence for each layer. Encryption at rest can protect stolen media while an authorized application still reads plaintext to render or transform a document. Transport encryption protects a connection but not the content after either endpoint receives it. Verify where editing, conversion, indexing, and support tools handle readable data. These distinctions help the organization state a precise assurance rather than using encrypted as an undifferentiated answer to every confidentiality question.
Ask what a stolen credential can decrypt
Compare the authority of a storage credential, an application service identity, a key policy administrator, and a recovery custodian. The risks are different. Storage access may reveal only ciphertext in one design and readable content in another; application authority may permit decryption even when storage and keys are operated separately. Verify the actual mechanisms.
| Authority | Question for the design |
|---|---|
| Storage reader | Can this identity obtain plaintext, or only encrypted objects? |
| Application identity | Which documents can it decrypt for rendering or conversion? |
| Key policy administrator | Can it grant new decryption rights or impersonate a workload? |
| Recovery custodian | What approval and evidence are required for an exceptional unlock? |
These questions establish the trust boundary without assuming a particular implementation. Keep the answer tied to the reviewed deployment and approved configuration.
Next, test the consequence of disabling a key using disposable content. Check new requests, already open documents, temporary conversions, and retained backups according to supported behavior. Explain caching and delivered copies explicitly. Key revocation can be valuable even when it cannot recall plaintext already obtained; the assurance should describe that limit accurately rather than promising universal erasure.
Map key ownership and use
Identify who creates keys, who can authorize decryption, where keys are stored, and which service identities use them. If customer supplied keys are proposed, obtain documentation for the exact product and storage arrangement. Determine whether the application can access those keys directly or requests decryption from another service. Include administrators capable of changing key policy or impersonating an authorized workload. Key ownership can improve control without eliminating every provider or operator access path. Keep key operations logged with safe identifiers and approval context, avoiding key material or sensitive document details in routine records.
Exercise a rotation scenario
A security team rotates the key protecting a test document collection. Follow the supported procedure, then open current and historical documents, restore a protected backup, and export an approved file. Verify whether earlier keys must remain available and who can retire them. Simulate a temporary key service outage and observe how the document application reports it. The scenario can reveal that a healthy storage service is unusable without key access or that old backups depend on keys scheduled for deletion. Use disposable content and a test key hierarchy to avoid disrupting business records during evaluation.
Design revocation and recovery
Define the intended effect of disabling a key and verify the actual caching and session behavior. Key revocation may stop future retrieval while leaving already decrypted sessions, temporary files, or delivered copies unaffected. Establish recovery authority and separation of duties for lost credentials or damaged key configuration. Test restoration through the approved procedure without relying on a single custodian. Retention obligations can require old keys to remain recoverable for as long as encrypted records exist. Coordinate key destruction with document and backup disposal rather than treating it as an independent maintenance action.
Custody review
- Document encryption layers and all known plaintext processing paths.
- Identify key creators, users, policy administrators, and recovery authorities.
- Test rotation against current documents, older versions, and backups.
- Measure key outage and revocation behavior in active workflows.
- Coordinate key retirement with approved record and backup disposal.
Document deletion: remove previews, search data, versions, and temporary copies
Turn document deletion into a tracked lifecycle with clear user visibility, retention rules, and cleanup of derived copies.
Read story
GDPR for collaborative documents: copies, retention, and rights
Locate personal data in drafts, comments, exports, indexes, and backups before implementing retention or rights decisions.
Read story
How long should a signed document URL remain valid?
Choose link expiry from queueing, download, and retry behavior while limiting the exposure of temporary document access.
Read story