Secrets rotation policy documented with evidence

Credentials that are never rotated accumulate exposure surface: every developer who ever handled a secret, every system it transited, and every breach that went undetected leaves a window open indefinitely. NIST IA-5 (Authenticator Management) requires organizations to manage credential lifetimes. PCI-DSS v4.0 Req-8.6.3 requires passwords/passphrases for application and system accounts to be changed periodically per a targeted risk analysis — the correct control for service-credential rotation. CWE-522 (Insufficiently Protected Credentials) encompasses stale credentials as a protection failure. Without documented intervals, there is no way to verify compliance, respond to a suspected breach with targeted rotation, or demonstrate due diligence during an audit.

Document rotation intervals for every credential type and create calendar reminders or automated rotation where the secrets manager supports it. Evidence of rotation — version history, rotation logs, or a dated entry in a runbook — is required to pass.

# ROTATION_POLICY.md
| Credential type        | Interval   | Last rotated | Next due   |
|------------------------|------------|--------------|------------|
| Database credentials   | Quarterly  | 2026-01-15   | 2026-04-15 |
| Stripe API key         | Every 6mo  | 2026-01-01   | 2026-07-01 |
| OpenAI API key         | Annually   | 2026-01-01   | 2027-01-01 |
| AWS IAM access keys    | Annually   | 2026-01-01   | 2027-01-01 |

For AWS Secrets Manager, enable automatic rotation:

aws secretsmanager rotate-secret --secret-id prod/db-credentials \
  --rotation-rules AutomaticallyAfterDays=90