A pre-release security checklist for a small team should fit on one page and cover review, dependencies, configuration, access, data handling and rollback. Attach it to the release ticket, tick items as they are checked, and keep only the questions that have caught problems.
Why a checklist
Releases are rushed, and people forget the same things. A short checklist turns memory into routine. It also leaves a dated record that you reviewed each release, which helps with buyer questions. Keep it short, or it becomes a form people click through without reading.
The checklist
| Area | Check |
|---|---|
| Review | Every change in the release went through a reviewed pull request with passing checks |
| Dependencies | The dependency scan ran on the release build, and no known exploited items remain open |
| Code checks | Static analysis ran, and open high impact findings are fixed or recorded |
| Configuration | Debug modes are off, default accounts removed, and environment settings reviewed |
| Secrets | No keys in code or build logs, and new credentials stored in the secrets store |
| Access | New endpoints require authentication and authorization, and tested per role |
| Data | New fields holding personal data are noted, and logging does not capture them |
| Third parties | New services reviewed and added to the vendor list |
| Monitoring | Alerts cover the new feature, and a person owns them |
| Rollback | We know how to undo this release and have tried it |
How to use it
Assign the checklist to the release owner. They tick each item with a link to evidence, such as the scan run or the pull request. Items that do not apply get a short note, not a blank. If an item fails, the owner either fixes it, or records a risk acceptance with a person who can approve it.
Automate what you can
Whatever a machine can check, make a required status check. Dependency and static scans belong in the pipeline, as described in minimum branch protection settings. The human checklist then covers judgment items: access design, data handling and rollback.
Keep the list alive
Review the checklist each quarter. Remove items that never fail and add one after every incident that a check would have caught. Ten to twelve items is a healthy size.
Special cases
For releases that change authentication, payments, or personal data handling, add a short threat modeling session before building, not at the end. A checklist cannot rescue a weak design.
Common mistakes
Making it so long that nobody reads it. Ticking boxes with no evidence. Skipping it for hotfixes, which are often the riskiest changes. Having no rollback plan.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Open a finding and see how the code check reports location and fix guidance, which is the evidence for the code checks row.
Quick check
Should hotfixes follow the checklist?
Yes, a shorter version. Review, dependency scan and rollback matter most when you are moving fast.
Who signs off?
The release owner ticks items, and a second engineer confirms. Name a backup so releases do not stall.
Last reviewed: 19 October 2026.
