Who Should Control the Encryption Keys for an Enterprise Document Platform?

“Encrypted at rest” describes a property of stored data. It does not explain who can authorize decryption, change the key policy, disable a workload, or recover an old backup. For a document platform, those decisions extend beyond the original files to metadata, extracted text, search indexes, renditions, queues, logs, and recovery copies.

FormKiQ uses one KMS key per instance. That shared key makes its policy and availability important across the instance’s dependent services. The dependency can outlive the application deployment: retained documents and backups may still need the instance key years after the last new write.

FormKiQ’s point of view: key control needs an operating model

Control should mean more than a key appearing in the customer’s account. Define who approves its use, who can change permissions, who responds to failures, and how the organization proves that both current and historical records remain usable. Treat the key as part of the document lifecycle and recovery design.

FormKiQ’s Customer-Managed AWS deployment model puts the infrastructure in the customer’s account. The Full Encryption module, included in Essentials, Advanced, and Enterprise, uses the instance’s shared KMS key across integrated services including S3, DynamoDB, SQS, and SNS. Inventory the resources and service roles that depend on that key, then verify its permissions, monitoring configuration, and recovery procedures. A change to the instance key can affect several document operations at once.

Define the ownership outcome precisely

Distinguish AWS-owned keys, AWS-managed KMS keys, and customer-managed KMS keys when gathering requirements. Also separate control of a KMS key from the origin of its key material. A customer-managed key can use AWS-generated material; imported material, often discussed as BYOK, introduces additional custody and recovery responsibilities.

Key control does not by itself prevent an authorized workload from producing plaintext, establish data residency, or block every support path. Review application permissions, service roles, exports, processing locations, and vendor access alongside the encryption design. Write down the outcome being purchased: administrative control, usage restrictions, audit visibility, independent custody, or a defined exit process.

Inventory the resources that depend on the instance key

Record the instance key’s ARN, owning account, Region, alias, and responsible team once. Then map the resources, service roles, and retained data that rely on it. The purpose is to understand the shared key’s operational impact and recovery dependencies.

Keep the actual instance-key ARN in the operational record; an alias alone is insufficient for tracing historical dependencies. Rotation of that key’s material preserves its logical identity. Replacing the instance key is a separate migration that must account for every dependent resource and retained copy.

Separate administration from use, and protect the separation

Give workloads only the cryptographic operations and service integrations they require. Review the instance key policy, IAM permissions, grants, and service resource policies together. For cross-account access, validate both sides of the permission model rather than assuming access to a bucket also permits decryption.

An administrator who lacks decrypt permission today may still be able to grant it tomorrow. AWS’s default key-policy guidance notes that key administrators can grant additional permissions through policy changes and grants. Use independent review, constrained administration, and monitored emergency access to support the intended separation of duties.

Inventory KMS grants by principal, operation, purpose, and retirement owner. Remove obsolete grants deliberately; do not break a live service by treating all service-created grants as unnecessary. Scope encryption-context and service conditions to the actual integration, and test both permitted and denied callers.

Distinguish rotation from migration and revocation

AWS’s KMS rotation documentation explains that rotating supported key material preserves the logical key and its ability to decrypt older ciphertext. It does not rotate existing data keys or re-encrypt the data they protect. Eligibility and procedure depend on the key type and material origin; imported material has its own supported rotation and custody process.

Replacing the shared instance key is a separate migration. Plan new-write configuration, historical objects and versions, service snapshots, backups, continued access to the previous instance key, and verification. Changing an alias is not evidence that old data no longer depends on the previous key.

Do not promise instantaneous withdrawal of all plaintext by disabling a key. Service caching, existing processing state, and previously exported data affect the result. For example, S3 Bucket Keys reduce KMS requests, and subsequent requests using the bucket-level key do not revalidate the KMS key policy. They also change the relevant encryption context from object to bucket. Test the required withdrawal behavior and use application, identity, and storage controls where needed.

Monitor changes independently of the workload

Define alerts for policy changes, grant creation, key disablement, deletion scheduling, denied operations, unusual principals, and imported-material expiry. Combine CloudTrail API activity with the appropriate KMS events delivered through EventBridge. These event sources serve different purposes; a lifecycle event feed alone is not a complete access audit.

Verify event collection, filtering, retention, alert delivery, and the on-call owner. Keep incident access and critical alerts from depending solely on the same key as the failing application. KMS activity is also not a one-to-one record of document reads: service caching and encryption design affect which operations reach KMS. Correlate key events with service and document audit evidence.

Treat deletion as a data-retention decision

AWS KMS requires a waiting period of 7–30 days for scheduled key deletion. A key pending deletion is unavailable for cryptographic operations. After deletion, the KMS key cannot be recovered. Intact encrypted backups do not compensate for losing the only key needed to read them.

Require an approved dependency review before retirement, covering historical versions, recovery copies, retention obligations, and holds. Treat disabling a key as a controlled availability change with its own recovery plan. It is not proof that every copy was erased or that disposition was authorized.

Cancellation is a separate step from restoration of service: canceling scheduled deletion leaves the key disabled. The runbook must include authorized re-enablement and validation of affected services, including work that failed while the key was unavailable.

Prove recovery in the target environment

Test restoration using the instance key, actual recovery environment, service roles, permissions, and retained data. A successful key lookup or decrypt test on one object does not establish that a database, search index, queue, or backup can be restored. Include older retained records and the metadata needed to locate and authorize them.

If the recovery architecture extends to another account or Region, design that separately from the instance’s shared-key configuration. AWS’s Multi-Region KMS keys do not replicate application data or automatically unify regional permissions. Confirm the supported deployment and service-specific restore procedure before choosing that recovery design.

If requirements involve imported material or external custody, first confirm support in the selected deployment, then document the custody and recovery procedures. For an exit, verify readable exports, metadata, approvals, and downstream dependencies before removing vendor access or retiring keys. Keep ongoing access to retained encrypted records under an assigned owner.

Worked example: a key scheduled for deletion

1. 1. Detect and assess the change

   An independent alert reports deletion scheduled for the FormKiQ instance’s shared key. The incident owner checks the change authority and uses the dependency inventory to assess the impact across document storage, metadata, processing, and retained copies.

2. 2. Recover before the waiting period ends

   Authorized responders cancel deletion and separately re-enable the key under the recovery procedure. They confirm the intended policy and investigate how the change was permitted.

3. 3. Validate the document workflow

   Test new writes, old reads, search, rendition processing, and representative backup restoration. Reconcile failed jobs and replay safely rather than assuming re-enablement completed every interrupted transaction.

4. 4. Correct the retirement process

   Update the dependency inventory and approval controls. Record recovery evidence and keep the key until each retained dependency is migrated, expires lawfully, or is otherwise resolved through the approved process.

Ask for evidence of control and recovery

• Show the instance key’s ARN and ownership, then map the resources, service roles, and retained copies that depend on it.
• Demonstrate permitted and denied workloads, constrained key administration, and review of grants and policy changes.
• Exercise a reversible key-outage scenario in an isolated test environment, with independent alerts and a documented service-recovery outcome.
• Restore retained records in the intended recovery environment and show the verification required before retiring a previous instance key.