Encryption Key & Secrets Rotation Checklist Template

Owned by the security or platform engineering lead. The trigger answer decides whether Phase 3 appears.

• Record what started this run — scheduled cycle, suspected leak, security incident, or a leaver who had access to shared secrets
• Export the secrets inventory — each secret with its owner, type, the systems that use it, where it is stored and the date it was created or last rotated
• Record where each secret lives — secrets vault, KMS, CI/CD variable, configuration file or hard-coded in source; anything outside the vault is flagged
• Set or confirm a cryptoperiod for each secret and key type — flag everything past its period or with no owner, and add both to the rotation list
• Update the certificate and trusted key inventory — issuing CA, expiry date, where each certificate is used and how it renews

A Yes on the live exposure task switches on Phase 3 even when the run was scheduled.

• Scan code repositories for secrets, including history — a key deleted in a later commit is still in every clone; record the tool and scope used
• Check CI/CD logs, build artefacts and container images — secrets printed by a debug step or baked into an image layer are a common source
• Check tickets, chat and wiki pages for pasted credentials — search for known key prefixes and connection strings
• Triage every finding — is the secret still valid, what does it grant, and was it ever in a public location
• Record whether any live secret was exposed — yes or no; a yes moves it straight to emergency rotation

Appears only when Phase 1 records a leak, incident or leaver, or Phase 2 finds a live exposed secret. The decision to accept an outage needs approval from the system owner.

• Link or open the incident record — the security incident response checklist holds the timeline and any notification decisions
• Revoke or disable the exposed secret now — if revoking will cause an outage, the system owner approves the trade-off and it is recorded
• Review the provider’s access logs for use of the secret since the exposure — unknown IP addresses, new resources or data reads go to the incident lead
• Rotate everything the exposed secret could reach — other credentials stored on the same host, in the same vault path or readable with the same role
• For a leaver, rotate the shared secrets they could read — use vault access logs and group membership, not memory, to build the list
• Clean the secret out of repository history only after it is revoked — rewriting history does not undo copies already made

The method answer in task 1 shows the matching tasks: dual-key tasks appear only for secrets that cannot be swapped in one step. Rotation of a production secret is raised as a standard change.

• Record the rotation method for each secret on the list — automatic in the vault or KMS, dual-key, or a single cut-over in a maintenance window
• Create the new secret or key version in the vault or KMS — never in a ticket, chat message or email; use the approved algorithm and length
• Dual-key: add the new credential alongside the old one — most cloud access keys, API platforms and database users allow two to be valid at once
• Dual-key: move consumers to the new credential one at a time — confirm each service authenticates with it before moving the next
• Deactivate the old credential, then delete it after the observation period — deactivating first gives you a fast way back if something breaks
• Watch for authentication failures for the agreed period — any consumer still using the old credential is a gap in the inventory

Assigned to the key custodians named in the key management procedure.

• Confirm automatic rotation is on for KMS keys that support it — and that the period matches the cryptoperiod; AWS KMS, for example, allows 90 to 2,560 days for customer managed keys
• Keep old key versions available for decryption — rotation changes the key used for new data; destroying an old version makes everything it encrypted unreadable
• Rotate manually managed keys by the documented procedure — HSM keys, imported key material and signing keys, with split knowledge where a person handles cleartext key components
• Review who can use, disable, export or schedule deletion of each key — key administrators and key users should be different people or roles
• Check certificate renewal automation and use a new key pair on each renewal — list certificates due within the next 30 days and any renewal that failed
• Review SSH authorised keys and repository deploy keys — remove keys with no current owner and replace any older than your SSH key cryptoperiod

• Move hard-coded secrets into the vault — every secret flagged in Phase 1 or found in Phase 2 gets an owner and a date
• Replace long-lived secrets with short-lived credentials where the platform supports it — workload identity, federated CI/CD tokens or dynamic database credentials
• Narrow the scope of each remaining secret — one secret per service and environment, with only the permissions that service needs
• Review who can read each vault path — people and pipelines with read access to production secrets need a current reason

Sign-off is an approval task for the head of security or platform engineering. The checklist halts until it is approved.

• Update the inventory with new rotation dates and the next due date — the next cycle starts from this list
• Attach evidence of rotation and revocation — vault version history, KMS rotation history and revocation confirmations; never attach a secret value
• Log exceptions with an owner, a compensating control and an expiry date — for example, a vendor appliance whose key cannot be changed without a site visit
• Confirm key custodians have acknowledged their responsibilities — new custodians since the last cycle sign the acknowledgement
• Approve the cycle and confirm the next scheduled run — quarterly for most estates, with emergency runs started as needed