Encryption is only as strong as the control over its keys. A database encrypted with a key that every engineer can use is protected against stolen disks and very little else.
Questionnaires ask "do you rotate encryption keys", and many teams answer yes because automatic rotation is switched on in their key management service. That setting is worth having. It also does less than most people assume, and an auditor who knows how it works will ask what else you do.
This article explains the key hierarchy behind cloud encryption, the choice between provider-managed and customer-managed keys, what rotation does and does not achieve, how to separate duties over keys, and what evidence holds up. The layers of encryption themselves are covered in encryption at rest and in transit.
The key hierarchy behind cloud encryption
Cloud services use envelope encryption. A data encryption key encrypts the data itself, often one key per object, volume or table. A key encryption key, held inside the key management service, encrypts the data key. The encrypted data key is stored alongside the data. The key encryption key never leaves the service in plaintext.
To read the data, a service sends the encrypted data key to the key management service, which decrypts it only if the caller has permission to use the key encryption key.
This has a consequence that is easy to miss. With customer-managed keys, permission to use the key becomes a second access control on the data. A principal needs both access to the storage and permission to use the key. That is the main security benefit of managing your own keys, and it only exists if the key policy is tighter than the storage policy.
Provider-managed or customer-managed keys
The choice is about control and evidence, not about the strength of the encryption. The algorithms are typically the same.
Provider-managed keys are the default for most services. The provider creates, rotates and protects them. You usually have little or no control over their policy or rotation schedule. They satisfy "encrypted at rest" and not much more.
Customer-managed keys live in your key management service account. You write the key policy, choose the rotation setting, and can disable or delete the key. Its use can be recorded in your own cloud audit logs. Most teams that handle regulated data use these for in-scope stores.
Imported or externally held keys let you generate the key material yourself or keep it in a hardware security module outside the provider. They give the most control and the most responsibility. If you lose imported key material and have no backup, the data it protects is gone. Use these when a regulator, contract or threat model requires them, not by default.
What rotation does and does not do
In most cloud key management services, rotating a key creates new key material, a new version, under the same key identifier. New encryption operations use the new version. Older versions are kept so they can decrypt what they already protect.
Data already encrypted is not re-encrypted by rotation itself. Some services re-wrap their data keys when the key encryption key changes, and some do not. Check the behavior for each service you rely on.
So rotation achieves two things. It limits how much data any single key version protects, and it limits how long a version is used for new encryption. It does not remediate a compromised key. If a key version may have been exposed, rotation alone leaves everything it already encrypted readable to whoever holds it. The response to compromise is to re-encrypt the affected data under new material and then disable or destroy the old version.
Setting a cryptoperiod
A cryptoperiod is how long a key is authorized for use. NIST SP 800-57 Part 1 gives guidance on cryptoperiods by key type, based on factors such as the volume of data protected and the sensitivity of the data. It does not set one interval for every key.
Annual rotation of key encryption keys is a common policy choice, and most cloud key management services can rotate on a schedule you set. Whatever you choose, write it in your key management standard, configure it, and make the configuration your evidence.
ISO 27001:2022 Annex A 8.24 (use of cryptography) asks you to define rules for cryptography, including key management, and ISO/IEC 27002 gives guidance across the key lifecycle from generation to destruction. PCI DSS v4.0 is more prescriptive. Requirement 3.7 asks for documented key management procedures, including key changes at the end of the defined cryptoperiod and retiring or replacing keys when their integrity is weakened or compromise is suspected.
Separating duties over keys
Two roles matter, and the same person should not hold both alongside access to the data:
Key administrators create keys, write key policies, change rotation settings, and can schedule deletion. They do not need to encrypt or decrypt anything.
Key users are the services and roles that encrypt and decrypt. They cannot change the policy that grants them that right.
Cloud key management services support this split through separate permissions. On a small team the split will not be perfect. Write down who holds which role, keep administrative access behind the same controls as other privileged access, and alert on every administrative action so that overlap is at least visible.
For PCI DSS environments, Requirements 3.6 and 3.7 add specifics: restricting access to keys to the fewest custodians necessary, split knowledge and dual control for any manual cleartext key operations, and a formal acknowledgment by key custodians of their responsibilities. The PCI DSS framework page gives the context.
Deletion is the most dangerous operation
Deleting a key makes every piece of data it protects unrecoverable. That is useful on purpose: destroying the key is one way to dispose of data you can no longer reach to delete. By accident, it is an outage you cannot reverse.
Cloud key management services build in a waiting period before deletion takes effect, and some offer purge protection that blocks permanent deletion during a retention window. Use these protections:
Restrict scheduling deletion to key administrators, and preferably require a second approver.
Alert immediately on any key scheduled for deletion or disabled.
Enable purge protection or the longest waiting period your provider offers for keys protecting production data.
When you delete a key deliberately, record why, what data it protected, and who approved it.
Logging key use
Cloud key management services can record every call made to them: decrypt requests, policy changes, rotation, disabling and scheduled deletion. Check what is on by default. Administrative actions are usually logged automatically, but on some providers the cryptographic operations are not. On Google Cloud, encrypt and decrypt calls fall under Data Access audit logs, which are off by default for most services. On Azure, Key Vault operations are resource logs that need a diagnostic setting. Once enabled, key logs are some of the most useful security telemetry you have.
Alert on key policy changes, keys disabled or scheduled for deletion, and decrypt requests from principals that do not normally use a key. Decrypt activity from an unfamiliar role is often the first visible sign that someone has reached data they should not have.
Evidence auditors test
When the auditor reaches key management, these artifacts answer most requests:
A key management standard: key types, algorithms, cryptoperiods, roles, and the procedure for suspected compromise.
A key inventory: each key, its purpose, the data stores it protects, its owner, creation date and rotation setting. PCI DSS v4.0 Requirement 4.2.1.1 separately asks for an inventory of trusted keys and certificates used to protect cardholder data in transmission.
Exported key policies showing who can administer and who can use each key.
Rotation configuration and version history, showing new versions created on schedule over the period.
Logs of administrative key actions for the period, with any deletions tied to an approval.
Custodian acknowledgments, where PCI DSS applies.
Keys and application secrets are often confused in audits. Secrets such as API tokens and database passwords need their own handling, covered in secrets management for engineering teams.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the cloud accounts you connect and routes failures to their owners. Evidence collection pulls configuration on a schedule, timestamped, so key settings and their history are on file for the whole audit period.