Secret Rotation Schedule Template
A template for tracking and scheduling the rotation of API keys, passwords, certificates, and other secrets across systems.
Note: This guide follows English-language naming conventions and terminology standards common in international development teams. Examples use English identifiers and comments to maximize compatibility across codebases and tooling.
Overview
A Secret Rotation Schedule Template helps teams track every credential that must be rotated, when it was last rotated, when it is due next, and who owns the process. It supports operational reliability and compliance by preventing expired certificates, stale API keys, and forgotten service account passwords.
When to Use
- Setting up a secrets management program.
- After a security incident or suspected credential leak.
- Preparing for an audit or compliance review.
- Migrating to a secrets manager or vault.
- Managing certificates, API keys, database passwords, or OAuth tokens.
Prerequisites
- A complete inventory of secrets and their locations.
- A secrets manager or vault for safe storage and rotation.
- Defined rotation frequencies based on risk and compliance requirements.
- Owners for each secret or system.
- Automated or manual rotation procedures that have been tested.
Solution
Template
1. Secret Inventory
| Secret Name | Type | System | Owner | Last Rotated | Next Rotation | Frequency | Status |
|---|---|---|---|---|---|---|---|
| prod-db-password | Database password | payment-service | DB team | 2026-03-15 | 2026-09-15 | 6 months | On track |
| stripe-api-key | API key | billing-service | Payments team | 2026-05-01 | 2026-11-01 | 6 months | On track |
| tls-cert-api | TLS certificate | api-gateway | Platform team | 2025-08-01 | 2026-08-01 | 1 year | Due soon |
| s3-service-account | Service account key | file-processor | Data team | 2026-01-10 | 2026-07-10 | 6 months | Overdue |
| github-actions-token | CI token | deployment pipeline | DevOps | 2026-06-01 | 2026-12-01 | 6 months | On track |
2. Rotation Procedure
| Step | Action | Owner | Verification |
|---|---|---|---|
| 1 | Generate new secret in vault | Owner | New secret exists and is encrypted |
| 2 | Update dependent services with new secret | Engineering team | Configuration change reviewed and approved |
| 3 | Restart or redeploy affected services | DevOps | Health checks pass |
| 4 | Validate functionality end-to-end | QA / owner | Smoke tests pass |
| 5 | Revoke old secret | Owner | Old secret no longer authenticates |
| 6 | Log rotation in schedule and audit trail | Security | Timestamp and owner recorded |
3. Exception and Risk Acceptance
| Field | Value |
|---|---|
| Secret name | s3-service-account |
| Reason for exception | Legacy system cannot rotate automatically |
| Compensating control | Manual rotation with approval, access limited to VPC |
| Risk owner | Data team lead |
| Review date | 2026-09-10 |
| Approved by | CISO |
4. Escalation Matrix
| Condition | Action | Escalation Target | Timeline |
|---|---|---|---|
| Secret overdue by 7 days | Notify owner and manager | Engineering manager | Immediate |
| Secret overdue by 30 days | Escalate to security review | Security team | Within 48 hours |
| Suspected compromise | Rotate immediately and investigate | Incident response team | Within 4 hours |
| Certificate expiring in 30 days | Create renewal ticket | Platform team | Same day |
Explanation
The schedule makes secret lifecycle visible. Without it, credentials expire unexpectedly, rotated secrets are forgotten, and compliance evidence is missing. The inventory links each secret to an owner, a rotation frequency, and a verification step, which reduces the risk of service disruption during rotation.
Variants
- Certificate-only schedule: Focuses on TLS, code-signing, and intermediate certificates with renewal and revocation workflows.
- Cloud credential schedule: Tracks IAM keys, service principals, and managed identities across AWS, Azure, and GCP.
- CI/CD secret schedule: Manages pipeline tokens, signing keys, and deployment credentials.
- Database credential schedule: Tracks database passwords and connection strings with rolling rotation to avoid downtime.
Best Practices
- Store secrets in a dedicated vault, never in source code or plaintext files.
- Automate rotation where possible to reduce human error.
- Rotate immediately after a suspected leak, employee departure, or breach.
- Set calendar reminders at 30, 14, and 7 days before expiration.
- Keep an audit trail of every rotation with owner and timestamp.
- Test rotation procedures in a non-production environment first.
- Delete old secrets after confirming the new ones are active.
Common Mistakes
- Rotating a secret without updating all dependent services.
- Forgetting to restart services after a secret change.
- Keeping old secrets active “just in case” after rotation.
- Not assigning a clear owner for each secret.
- Skipping post-rotation validation.
FAQs
How often should API keys be rotated?
High-risk keys exposed to the internet should rotate every 90 days or less. Internal service keys typically rotate every 6 months, depending on compliance requirements.
Should rotation be automated or manual?
Automate whenever possible. Manual rotation should be limited to legacy systems and should still follow a documented schedule with compensating controls.
What happens if a service cannot rotate without downtime?
Use a rolling rotation strategy: create a new credential, update half of the instances, validate, then update the rest. For databases, support dual credentials temporarily.