A release go/no-go meeting should take about 20 minutes and decide one thing: ship or hold. It works only if the security criteria were agreed before the meeting, the evidence is on one page, and one named person decides. Without that, it turns into a debate about severity.
What the meeting is for
The Scrum Guide says the sprint review should never be considered a gate to releasing value, and that an item below the definition of done cannot be released. A go/no-go meeting is separate from the sprint review and is common in teams that release less often or with more coordination. The meeting checks that agreed criteria are met. It is not the place to invent new ones.
Agree the criteria first
NIST's Secure Software Development Framework asks organizations to define criteria for software security checks, track them through the lifecycle, and record approvals, rejections and exception requests in the workflow system. Apply that here by writing the release criteria down ahead of time.
| Criterion | Example threshold |
|---|---|
| Blocking findings | No unresolved critical findings in code or dependencies |
| Known issues | Every accepted risk has an owner and review date |
| Tests | Security regression tests pass |
| Secrets | No secrets in the build or config |
| Rollback | A tested way back exists |
| Evidence | Scan results and approvals are saved for this build |
Pick thresholds that fit your product, and write them where the team can find them.
The 20 minute agenda
- Minutes 0 to 3. State the release, the version and the criteria.
- Minutes 3 to 10. Walk the one-page evidence summary against each criterion.
- Minutes 10 to 15. Discuss only items that fail or are borderline.
- Minutes 15 to 18. Review any risk acceptances proposed, with owner and review date.
- Minutes 18 to 20. The decider says go or no-go, and the note-taker records it.
Who attends
- The release manager or tech lead, who presents the evidence.
- The product owner, who decides on accepting risk.
- A security representative, who answers questions on findings.
- Operations, who confirm the rollback plan.
Keep the group small. Everyone else can read the notes.
What counts as a blocker
Decide this before the day. A useful split is three levels. A blocker stops the release. A condition allows release with a dated follow-up. A note is recorded but does not change the decision. If the room argues about which level a finding belongs to, adjust the written criteria afterward so the next meeting is quicker.
Record the outcome
Write down the decision, the evidence version, the accepted risks and who decided. Attach it to the release record. This is useful for audits and also for the next release, when someone asks why a known issue shipped.
After the meeting
If a no-go happens, list exactly what must change and who owns each item. Avoid vague notes like "fix security issues". A tight list lets the team re-run the criteria quickly instead of holding another long meeting.
Safeguard can run dependency scans and policy gates on every build and keep the results as release evidence. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by severity and status, which is the view a go/no-go meeting needs on one page.
Quick check
Who makes the final go/no-go call?
One named person, often the product owner or release manager, decided in advance. Others advise but do not vote.
Can the meeting change the criteria?
It should not. Change criteria afterward, in a retrospective, so the next decision is faster and fair.
Sources
Last reviewed: 19 October 2026.
