🛡️ Production Readiness Security Checklist
Intro: This checklist asks whether a service is safe to operate in production, not only whether the code compiles and tests pass.
Best time to use this checklist
Use it before first production launch, before moving from pilot to broad availability, and before handing service ownership to another team.
Stop-the-line conditions
- the service has no clear owner or on-call path;
- high-value actions are not logged;
- no tested recovery or rollback path exists;
- sensitive data handling is undefined or contradictory.
Text-first review prompts
- Who owns the service, the secrets, the identities, and the deployment path?
- Which security events must be visible on day one?
- How does the service recover from bad config, bad deploy, or abuse?
- What minimum hardening baseline is expected for this runtime?
- How are dependencies, images, or packages trusted and updated?
- What unresolved risk is being accepted at launch?
Evidence table
| Control area | What to verify | Typical evidence |
|---|---|---|
| Ownership | Service, runtime, and escalation ownership is documented | service catalog, runbook |
| Security events | High-value auth, admin, and data events are visible | logging schema, dashboard |
| Recovery | Rollback, fail-safe, or break-glass procedures exist | runbook, incident drill notes |
| Baseline | Runtime and deployment meet agreed minimum controls | YAML, Dockerfile, baseline review |
| Residual risk | Known gaps are documented and owned | risk record, launch review |
Common misses
- assuming SAST/DAST alone means production-ready;
- ignoring emergency-access paths or support tooling;
- launching without denial logs or admin action logs;
- treating shared ownership as the same thing as actual ownership.
Related pages
---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.