Release day security checklist for engineering teams

On release day, verify that the artifact came from the expected commit, that gates passed without overrides, that no new secrets or high risk packages slipped in, and that monitoring and rollback are ready. Then watch the first hour. Most release incidents are visible within minutes if someone is looking.

The morning before you ship

• Confirm the commit. The release tag points to a commit that went through review. No direct pushes to the release branch.
• Check the build ran in your normal pipeline. Not on a developer machine, and not with a skipped job.
• Read the dependency diff. Compare the package list against the last release. Look at every new package and every version jump. A new transitive dependency that nobody chose is worth a question.
• Look at gate overrides. If someone bypassed a policy gate to get here, record who and why in the release ticket.
• Freeze unrelated changes. Configuration changes, certificate renewals and infrastructure updates should not share the window with the release.

Pressing the button

Decide in advance who may deploy. Two people is a good number: one to run it, one to watch. Check these at the moment of deploy:

• Deploy credentials are short lived or scoped to this service only.
• The artifact digest in production matches the digest your pipeline recorded.
• Feature flags for risky new paths are off by default.
• Database migrations are separate from the code deploy, or reversible.

The first hour after

Watch four things and write down what normal looked like before:

1. Error rate and latency.
2. Authentication failures and unusual sign in locations.
3. Outbound network connections from the new version, especially to hosts you do not recognise.
4. Resource use. A sudden jump in CPU can mean something unexpected is running.

If any of them moves, roll back first and investigate second. A rollback you did not need costs minutes. A compromised release you left running costs far more.

After the dust settles

Save the evidence: the build log, the dependency list, the gate results and the approver names. Auditors ask for these later, and engineers ask for them during incidents. Store them where they cannot be edited by the pipeline that produced them.

Safeguard policies and gates can block a release on rules you set, and its evidence automation can collect the results for you. The point of the checklist stands without any tool: a person looked, and wrote it down.

Keep the list short enough that people use it. Ten lines that are always done beat forty that are skimmed. Review the list after any release that went wrong, and add the one check that would have caught it. Remove lines that have never failed in a year and are covered by automation. A checklist that grows without pruning turns into ritual, and ritual stops catching things.

Quick check

Last reviewed: 19 October 2026.