A key compromise plan should name who to call, how to re-key, which keys exist and what each protects, how revocation is enforced, and how you will watch the re-keying. OWASP's key management guidance lists those items. Write it before you need it.
Why it needs writing down
When a private key leaks, hours matter. People argue about scope, who owns the key and whether anything depends on it. A written plan turns that debate into a checklist. OWASP says to maintain a documented, accessible compromise recovery plan. Accessible matters: if the plan lives in a system that depends on the compromised key, it is useless.
The five parts
OWASP lists what the plan should cover.
- Notification and recovery contacts: who is told, inside the company and outside it, and how to reach them out of hours.
- The re-key method: the exact steps to generate a replacement and roll it out.
- An inventory of all keys and their uses: you cannot assess impact without it.
- Revocation checking enforcement: how clients learn a key is no longer trusted, and whether they actually check.
- Monitoring of re-keying operations: confirmation that the rollout happened and that the old key stops working.
Making each part concrete
Contacts: names, roles and a backup for each, reviewed on a schedule.
Re-key method: separate runbooks per key type. Rotating a TLS certificate, a code signing key, a database key encryption key and a JWT signing key are different jobs with different blast radius.
Inventory: key name, purpose, owner, where it lives, what is wrapped under it, and which services use it. The inventory is the part most teams lack.
Revocation: for certificates, know whether your clients check revocation. For tokens, know how a signing key is removed from your key set and how long cached copies live.
Monitoring: dashboards or logs that show the old key failing and the new key succeeding.
First hour steps
- Revoke the key promptly and stop using it for new data, which OWASP calls out.
- Generate the replacement in a protected module.
- Identify what the old key protected and decide whether data needs re-encryption.
- Preserve evidence: access logs for the key and the systems that could read it.
- Start the notification path.
Data protected by the old key
OWASP says that after a trigger a new key should be generated, and re-encrypting existing data with it is the preferred approach. With a key hierarchy, replacing a key encryption key means re-wrapping data keys. Replacing a data key means re-encrypting the data it protected.
Practice it
Run a tabletop with a scenario: a signing key is found in a public repository. Time how long it takes to find the owner, the dependents and the rollout steps. Fix what was slow.
Quick check
Should we rotate keys immediately on suspicion?
OWASP lists suspected compromise as a trigger for rotation. Balance speed with a working rollout plan so rotation does not cause an outage.
Do we need a separate plan for each key?
One plan with a runbook per key type is usually enough. The inventory ties them together.
Safeguard's compliance and evidence automation can keep the plan, tabletop results and rotation records as audit evidence, and the free scan at gold.safeguard.sh/scan is a place to start on dependencies.
Sources
Last reviewed: 19 October 2026.
