Before a product launch, confirm twelve things: who can reach production, where secrets live, what dependencies ship, what is logged, how abuse is limited, and how you roll back. Each check below has a pass or fail test, so the list can be finished in an afternoon and signed by one person.
Access and secrets
- Production access list is current. Pass: every person with production access is named, and each has a reason to keep it. Remove anyone who was added for the build phase only.
- No shared admin accounts. Pass: every administrative action maps to one human or one service identity.
- Secrets are out of code and images. Pass: a scan of the repository history and the built images finds none. Rotate anything that was ever committed, even if it was deleted later.
- Test credentials and debug routes are gone. Pass: no default passwords, no seeded admin user, no debug endpoint reachable from the internet.
What you are shipping
- Dependency inventory exists. Pass: you can list every direct and transitive package in the release and the version of each. A software bill of materials generated at build time is the easy way.
- Known critical issues are triaged. Pass: each critical or high finding is fixed, shown not reachable, or has a written exception with an owner and a date.
- Build is reproducible from a clean checkout. Pass: a second person can build the same release without your laptop.
Running it
- Logging covers sign in, permission changes and data export. Pass: you can answer "who did what, when" for those three events, and logs go somewhere an attacker with app access cannot edit.
- Rate limits and abuse controls exist. Pass: sign up, password reset, search and any expensive endpoint have limits. Launch day brings both real users and scripted ones.
- Backups restore. Pass: someone has restored a backup to a scratch environment this month, and timed it.
People and process
- Someone owns the first week. Pass: a named on call person, a way for outsiders to report a vulnerability, and a status channel.
- Rollback is rehearsed. Pass: you know the command, the time it takes, and who can authorise it. Data migrations that cannot be reversed are flagged before launch, not during it.
How to use the page
Print it or paste it into the launch ticket. Mark each line pass, fail or accepted risk. An accepted risk needs a name next to it. If more than two lines fail on the day, the honest answer is often to delay by a few days, because the cost of fixing items 1 to 4 after launch is much higher than before.
Teams that want help with items 5 and 6 can run a free scan at gold.safeguard.sh/scan, or use the SBOM and dependency scanning in Safeguard to produce the inventory and reachability view automatically.
Quick check
Is this enough for a regulated product?
No. It is a floor for launch week. Regulated products also need the evidence and control mapping your framework asks for.
Who should sign off?
One accountable person, usually the engineering lead or security owner, with the product owner acknowledging any accepted risks.
Last reviewed: 19 October 2026.
