API Key and Credential Rotation Runbook (JSON)

1You are a senior platform security engineer. Using the schema below, produce a complete credential rotation runbook as one valid JSON object for the secret I describe (an API key, database password, OAuth client secret, signing key, webhook secret, cloud access key, SSH key or TLS certificate). Ask me up to 5 short questions first if the inputs are missing, then output ONLY the JSON, with no comments and no trailing commas.
2
3My inputs:
4- Secret type and provider:
5- Where it is stored (vault, cloud secret manager, CI variables, .env files, Kubernetes secrets):
6- Every service, job, device or partner that uses it:
7- Reason for rotation (scheduled, employee offboarding, suspected leak, confirmed leak, compliance):
8- Can the provider keep two valid credentials at once (yes / no / unknown):
9- Allowed downtime and team size:
10
11Schema:
12
13```json
14{
15  "rotation_runbook": {
16    "summary": {
17      "secret_name": "",
18      "secret_type": "",
19      "provider": "",
20      "reason": "",
21      "severity": "routine | elevated | incident",
22      "owner": "",
23      "approver": "",
24      "target_completion": "",
25      "rotation_strategy": "dual_credential_overlap | blue_green_secret | hard_cutover"
26    },
27    "blast_radius": {
28      "consumers": [
29        { "name": "", "type": "service | job | ci | device | partner | human", "how_it_loads_secret": "", "reload_method": "restart | hot_reload | redeploy | manual", "owner": "", "risk_if_broken": "" }
30      ],
31      "unknown_consumers_check": ["provider access logs for the old key", "secret scanning in repos and CI logs", "search config and IaC for the secret name"]
32    },
33    "preparation": [
34      { "step": "", "command_or_location": "", "verify": "" }
35    ],
36    "rotation_steps": [
37      { "order": 1, "action": "", "who": "", "command_or_location": "", "expected_result": "", "verify": "", "rollback": "" }
38    ],
39    "verification": {
40      "health_checks": [],
41      "old_credential_usage_must_be_zero_for": "",
42      "metrics_and_logs_to_watch": []
43    },
44    "revocation": {
45      "revoke_old_after": "",
46      "steps": [],
47      "confirm_revoked_by": ""
48    },
49    "rollback_plan": {
50      "trigger_conditions": [],
51      "steps": [],
52      "point_of_no_return": ""
53    },
54    "incident_extras": {
55      "applies": false,
56      "scope_review": "",
57      "audit_log_queries": [],
58      "notify": [],
59      "evidence_to_keep": []
60    },
61    "communication": [
62      { "audience": "", "when": "", "channel": "", "message": "" }
63    ],
64    "prevention": {
65      "next_rotation_date": "",
66      "automation_opportunities": [],
67      "secret_hygiene_fixes": []
68    },
69    "open_questions": []
70  }
71}
72```
73
74Rules:
751. Prefer a dual-credential overlap: create the new secret, roll it out to every consumer, verify, and only then revoke the old one. If the provider allows only one valid credential, use hard_cutover and plan a short maintenance window.
762. Order rotation_steps so nothing breaks: store the new secret, update consumers from least to most critical, reload each one, verify, then revoke.
773. Every step must have a concrete verify and, before the point of no return, a rollback.
784. Never print, invent or echo real secret values; use placeholders like <NEW_SECRET_REF>.
795. For a suspected or confirmed leak, set severity to incident, fill incident_extras, revoke as fast as safely possible, and review audit logs for misuse since the exposure window began.
806. Include CI/CD variables, local .env files, cached build artifacts, mobile or desktop apps and partner integrations in the consumer search, because they are the usual misses.
817. In prevention, suggest moving to short-lived or workload identity credentials where the provider supports them, and a realistic rotation interval.
828. Put anything you had to assume into open_questions instead of guessing silently.