Key Rotation

​

Scope

​

Triggers

​

Process — routine rotation

1. Schedule. The owner files a Linear issue at least 30 days before the next rotation date for every key class with a target date. The Compliance Calendar carries the canonical schedule.
2. Plan. Owner attaches to the issue: key identifier, current version, new-version method (auto-rotate, manual rotate, key roll), affected consumers, expected downtime (target: zero), backout plan.
3. Approve. CISO approves before execution. For Vault root-token and Vault Transit keys, the CTO also approves. At current scale, CTO and CISO are the same individual (per Roles & Personnel); the dual-approval requirement is satisfied by the same approver signing in both capacities and by the CEO independently attesting within 5 business days that the rotation occurred per the role-concentration compensating controls. CEO attestation is recorded on the evidence file at /registers/key-rotations/<YYYY-MM>-<class>.mdx.
4. Execute. Owner performs the rotation:
   • AWS KMS CMKs — confirm automatic key-material rotation is enabled and that the most-recent rotation completed; manual rotation only if the table mandates or if compromise is suspected.
   • Vault Transit keys — issue vault write -f transit/keys/<name>/rotate; consumers are unaffected because Vault tracks key versions and decrypts with the historical version.
   • TLS server certificates — issued via ACM / Cloudflare; rotation is automatic where supported and tracked via the SSL Labs scan results.
   • Long-lived third-party API keys — create new key in the provider’s console, write to Vault, update consumers, verify, revoke old key.
   • Release-pipeline tokens — see the release.yml header for per-token re-issue steps; CI must be green on the new value before the old value is revoked.
   • Service-account / static-DB credentials — prefer migration to dynamic credentials via Vault; if migration is not yet possible, rotate per the 90-day cadence using Vault’s versioned KV.
   • Application password peppers — rotate per Cryptography Policy → Application password peppers; old pepper retained as verify-only until cutover completes.
   • Vault root token — rotate via the documented unseal-quorum procedure with both CISO and CTO present; new token is re-sealed into both CISO and CTO Dashlane vaults.
5. Verify. Consumers continue to function. For application-layer keys, a sample decrypt test is performed against both the new and the prior version. For TLS, the SSL Labs scan is re-run.
6. Revoke. Old credential is revoked / disabled / scheduled for destruction per the key class — KMS CMKs are scheduled for deletion only after a 30-day waiting period to avoid loss of access to historical ciphertext; Vault key versions are kept long enough to decrypt any historical ciphertext that may need to be re-wrapped, then archived.
7. Record. Owner writes an evidence note (template below) to the Linear issue and uploads to the SharePoint SOC 2 / ISO 27001 evidence library.

​

Process — emergency rotation

1. Declare. CISO opens an incident; IR commander assigned.
2. Rotate. Same mechanical steps as routine, but executed immediately — rotation completion is targeted within the P0 (customer-data-bearing key) or P1 (operational credential) containment timeline in the Incident Response Policy, and the actual completion time is recorded in the incident timeline. Where the key class supports versioned co-existence (Vault Transit, application password peppers), the new version is added in parallel and consumers cut over. Where it does not (long-lived API keys), there is a brief window of consumer impact that is tracked in the incident timeline.
3. Revoke aggressively. Old credential is revoked the moment the new credential is in use, not on the usual cooldown.
4. Investigate. IR commander runs root-cause analysis per the Incident Response Policy post-incident-review, including a search for unauthorized use of the prior key in the relevant log retention window per the Log Review procedure.
5. Report. Incident outcome and any control change is reported at the next ISMS Management Review. External notice obligations (regulator, customer, partner) are evaluated by the General Counsel as part of the IR runbook.

​

Evidence note — template

# Key rotation — <key class> — <YYYY-MM-DD>

**Type:** Routine | Emergency
**Owner:** <name>
**Approved by:** <CISO> [, <CTO> for Vault root / Transit]
**Trigger:** Routine cadence | Suspected compromise | Personnel departure | 401/403 in CI | Vendor disclosure
**Linked incident:** <id, if emergency>

## Plan
- Key identifier: <id>
- Prior version: <vN>
- New version: <vN+1>
- Method: <auto-rotate | manual rotate | key roll>
- Affected consumers: <list>
- Expected downtime: <e.g. zero>
- Backout plan: <…>

## Execution
- Rotation timestamp: <YYYY-MM-DDTHH:MM:SSZ>
- Verification: <decrypt test, consumer health check, SSL Labs grade, …>
- Revocation timestamp: <YYYY-MM-DDTHH:MM:SSZ>

## Sign-off
| Name | Role | Date |
|---|---|---|

​

Records

​

Reporting

• The quarterly access reviews per the Access Reviews procedure.
• The annual SOC 2 / ISO 27001 audit.
• The ISMS Management Review when the Logging & Monitoring / Access Control rotation falls in the deep-dive quarter.

​

Version history