Encryption Key Compromise Playbook: Scope, Revoke and Re-encrypt Without Losing Data

When a data encryption key or the master key that wraps it is exposed, the encryption it provided is gone for every copy of the data that key protects, including backups and exports the attacker already holds. NIST SP 800-57 Part 1 defines compromise as "the unauthorized disclosure, modification, substitution or use of sensitive key information", and the response is unusual in one respect: deleting the key too early can destroy your own data permanently, while leaving it active keeps the attacker's access open. This playbook template gives [Organisation] a response for a suspected or confirmed compromise of a key held in a cloud key management service (KMS), a hardware security module (HSM) or an application key store. It covers scoping the key hierarchy, disabling versus deleting, re-encryption planning, evidence and notification. It is for incident responders, cryptography and platform engineers, data owners and privacy teams. Replace every [placeholder] before use. Signing keys and certificates have their own playbook: see the Compromised Code Signing Certificate Playbook.

How to use this template

• Adopt it as a sub-playbook of the Incident Response Plan Template, alongside the Leaked Credential Response Playbook for the credentials that usually lead to key misuse.
• Align it to your policy: key types, owners and cryptoperiods should come from your Cryptographic Key Management Policy Template, which this playbook does not repeat.
• Pick the track: Track A covers keys held in a managed cloud KMS. Track B covers keys in an on-premises or dedicated HSM. Track C covers keys stored in application configuration, files or secrets managers. Most incidents touch more than one.
• Prepare now, not during the incident: a key inventory that maps each key to the data, services and backups it protects, the deletion waiting periods configured on each platform, and tested re-encryption tooling.
• Record decisions: each "Decision" line names who decides and on what evidence. The most important is the destroy decision, which is irreversible.

1. Scope and triggers

1.1 This playbook applies to symmetric data encryption keys (DEKs), key encryption keys (KEKs) and master or root keys, and to asymmetric keys used for encryption or key transport, whether customer-managed in [cloud KMS], held in [HSM platform] or stored by applications.

1.2 Invoke it when any of the following occurs:

• Exposure of key material: plaintext key material found in a repository, log, ticket, container image, backup or paste site.
• Misuse of a managed key: decrypt or re-encrypt calls on a KMS key from an unexpected principal, network location or volume, or changes to key policies or grants that were not approved.
• Compromise of an identity with key permissions: a role, service account or administrator that can call decrypt, export or import, or change key policy.
• HSM events: tamper alerts, unexpected key export or wrap operations, loss of a backup token or smart card, or a quorum card holder leaving without handover.
• Theft of encrypted data together with keys: evidence that encrypted backups or databases left the environment and that the key, or access to it, may have gone with them.

1.3 Severity. Treat any compromise of a KEK, master key or HSM administrative credential as Severity [1], because every key it wraps is in scope. A single DEK protecting non-sensitive data may be Severity [3].

2. Roles and contacts

3. Detection and triage

3.1 Identify the key precisely: key ID or ARN, version, alias, region, HSM partition, and whether the key material was generated in the service or imported.

3.2 Map the hierarchy. Determine whether the compromised item is a DEK, a KEK that wraps DEKs, or a root key. A compromised KEK exposes every DEK it has wrapped, including DEKs stored alongside encrypted backups. See the Envelope Encryption and KMS Integration Patterns Guide.

3.3 Answer the triage questions:

• Was raw key material exposed (attacker can decrypt offline, forever), or only the ability to call the KMS (access ends when the identity or policy is fixed)?
• Which data stores, volumes, objects, databases and backups are encrypted under this key or its wrapped DEKs?
• Does the attacker hold ciphertext? Check for bulk reads, snapshot sharing, backup export and unusual egress.
• For asymmetric encryption keys, was the public key downloaded and used outside the KMS? The AWS KMS documentation notes that such external use cannot be seen by KMS alarms or logs.
• What personal or regulated data is in scope?

3.4 Pull the audit evidence for the look-back window [90 days or since key creation]:

Decision: [Incident commander] confirms compromise (suspected or confirmed) and severity, based on 3.3 and 3.4.

4. Containment

4.1 Stop the access path first. Revoke sessions and disable or rotate credentials for compromised identities, remove unapproved key policy statements and grants, and restrict key use to expected principals and networks.

4.2 Disable, do not destroy. Disabling a key blocks all cryptographic use and is reversible. Destruction is not. Use the platform's disable function and the longest deletion safety window available:

• AWS KMS: a disabled key can be re-enabled. Scheduled deletion has a waiting period of 7 to 30 days (default 30) during which the key is in Pending deletion state, cannot be used and can be cancelled. AWS recommends disabling a key instead if you are unsure whether you will need it, and a CloudWatch alarm can warn when anyone tries to use a key pending deletion.
• Google Cloud KMS: a disabled key version cannot be used, and Google recommends disabling before scheduling destruction. The default scheduled for destruction duration is 30 days, a version can be restored only while scheduled for destruction, and it returns in the disabled state. An organisation policy can enforce a minimum destroy scheduled duration.
• Microsoft Azure Key Vault: soft delete is on by default for new vaults and cannot be disabled; deleted keys are retained for 7 to 90 days (default 90), set when the vault is created. Purge protection is optional, is recommended by Microsoft for encryption keys, and prevents purging before the retention period ends.

Platforms are listed alphabetically. For on-premises HSMs, disable the key object or the partition user, and confirm backups of the key exist in a protected form before any destructive step. See the HSM Deployment and Operations Guide.

4.3 Understand what disabling breaks. Disabling a KEK stops services from unwrapping DEKs, which usually means outages. Where the attacker holds only API access (not key material), fixing the identity and policy may contain the incident without disabling the key. Where raw key material is exposed, disabling stops further misuse in the service but does nothing to ciphertext the attacker already holds.

4.4 Preserve evidence before changing anything you can avoid changing: export key metadata, key policies, grants and audit logs to write-once storage, with hashes and timestamps.

Decision: [Incident commander with data owners] approves disabling keys that support production services, accepting the outage, or records why the key stays enabled under compensating controls.

5. Eradication

5.1 Create new keys, not new versions only. If raw key material was exposed, generate a new key (new material) under a new key policy. Automatic rotation that keeps old versions available for decryption does not remove the attacker's ability to decrypt data protected by the old version.

5.2 Re-wrap before re-encrypt. In envelope encryption, a KEK compromise where the DEKs themselves were not exposed can often be handled by unwrapping DEKs with the old KEK and re-wrapping them with the new KEK. If DEKs, or the data they protect, may have left the environment, the data must be re-encrypted under new DEKs.

5.3 Plan re-encryption by priority:

1. Live stores holding personal, payment or regulated data.
2. Backups and snapshots, which are the copies most often stolen together with keys.
3. Archives and exports.
4. Caches, replicas and derived data stores.

5.4 Remove the root cause: purge exposed key material from repositories and images (and rotate anything else exposed with it), narrow key policies so that decrypt and key administration are held by different identities, and move application-held keys into a KMS or HSM.

6. Recovery

6.1 Verify before you destroy. Confirm that every data set protected by the old key has been re-encrypted or re-wrapped, that services read correctly under the new key, and that backups taken after the change restore successfully.

6.2 Watch the old key while it is disabled. Any attempt to use the disabled or pending-deletion key reveals a missed dependency or continued attacker activity.

6.3 Destroy only on approval. On AWS KMS, data encrypted under a deleted key is unrecoverable (with narrow exceptions for multi-Region replicas and some imported asymmetric or HMAC keys). On Google Cloud KMS, destroyed key versions leave data "crypto-shredded", and key material can remain in Google systems for up to 45 days after the scheduled destruction time. Record the destruction evidence.

Decision: [Data owners and key custodian] sign off that no required data remains under the old key before destruction is scheduled.

6.4 Rollback. If a service fails after the switch, re-enable the old key (still disabled, not destroyed) for that service only, fix the dependency and switch again. Never extend the old key's validity for new encryption.

7. Communication and notification

• Personal data: under GDPR Article 33, a personal data breach must be notified to the supervisory authority without undue delay and where feasible within 72 hours. Article 34(3)(a) relieves the duty to tell individuals where data was rendered unintelligible, for example by encryption, which no longer applies if the key was also compromised. Use the Data Breach Notification Checklist for other regimes.
• Sector and contractual duties: check payment, health and financial sector rules and customer contracts that require notice of key compromise. [List the regimes that apply.]
• Providers: open a case with the cloud provider or HSM vendor where provider-side compromise is possible.
• Internal: use the Incident Communication Plan Template; brief service owners before disabling keys that will cause outages.

8. Post-incident review

8.1 Within [10] working days, review: how the key was exposed, why detection took as long as it did, whether the key inventory mapped the affected data correctly, how long re-encryption took, and whether deletion safety windows were long enough.

8.2 Record the lesson from the GoTo breach, where encrypted backups were stolen together with a key for part of the encryption: keys and the ciphertext they protect must not be reachable from the same identity or location.

8.3 Update the key management policy, the inventory and this playbook, and track actions to closure.

Implementation guidance

Prepare the inventory. The playbook fails without a map from each key to the data, services and backups it protects. See the Cryptographic Inventory and CBOM Guide.

Choose response options per scenario:

Configure safety windows in advance: set the longest practical deletion waiting period, enable purge protection where available, and alert on any schedule deletion, disable or key policy change. Treat the identities that hold key permissions as high-value non-human identities. See the Cryptographic Key Management Guide.

Framework mapping:

Test it. Run a tabletop at least yearly, and a technical drill in a non-production account: disable a KEK, measure what breaks, re-wrap DEKs and restore a backup under the new key. Measure time to identify affected data, time to disable, and time to complete re-encryption.

Related NHI Mgmt Group resources: Cryptographic Key Management Policy Template · AWS KMS Security Guide · Azure Key Vault Security Guide · Cloud KMS and Cloud HSM Guide