🚦 Release Governance — Security Sign-Off, Quality Gates, Acceptance Criteria, and Escalation
Intro: Release governance is the control system that decides whether security evidence is sufficient for deployment. The goal is not to create theatrical approval steps. The goal is to make release decisions explicit, auditable, and proportionate to risk.
What this page includes
- a practical model for security sign-off and quality gates
- acceptance criteria and escalation patterns
- examples of release evidence and emergency-release handling
Figure: releases should move through explicit evidence, gate, decision, and record steps.
What release governance is actually for
Release governance answers five questions:
- What evidence is required before release?
- What findings or conditions are blocking?
- Who can approve a release, and under what conditions?
- What happens when the release does not meet the rule?
- How is the final decision recorded for later audit or incident review?
Security sign-off: recommended model
Security sign-off should be treated as an evidence-backed decision rather than a personal blessing from “the security person.”
Good sign-off characteristics
- based on documented inputs
- tied to release criticality and environment
- uses blocking criteria that engineering can understand in advance
- supports time-bounded exceptions and escalation
- produces a durable release record
Bad sign-off characteristics
- based on chat messages only
- unclear whether security approved, was informed, or merely present
- no criteria for when a finding blocks versus when it is accepted temporarily
- no way to explain the decision later to leadership, auditors, or customers
Minimum release evidence pack
| Evidence type | Example |
|---|---|
| Source and change record | commit / MR / PR reference, approvers, ticket links |
| Build integrity | provenance, signed artifact, pipeline record |
| Test and scan results | SAST, secrets, dependency, image, IaC, DAST, policy checks as applicable |
| Design exceptions | open risk acceptances, threat-model exceptions, compensating controls |
| Deployment approval record | who approved, when, scope, target environment |
| Release notes / rollback record | version, rollback path, known risks |
Example acceptance criteria by release class
| Release class | Minimum security acceptance criteria |
|---|---|
| Standard non-prod | required scans completed, no known pipeline compromise, change approved by owning team |
| Standard prod | protected branch / workflow rules met, required scans pass, no open blocking criticals, exceptions documented |
| High-risk prod (auth, payments, admin plane, internet edge) | threat model or design review current, protected environment approval, explicit owner sign-off, documented rollback, no unresolved blocking criticals or unapproved highs |
| Emergency prod | incident or business emergency declared, minimum evidence captured, designated approver used, retrospective review required |
Example blocking policy
A practical blocking policy might say:
- block on unresolved critical findings in release scope unless an approved exception exists;
- block if secret scanning or provenance controls fail;
- block if required approvers are missing;
- warn / escalate on high findings depending on exploitability, reachability, and compensating controls;
- record but do not block medium and low findings unless they indicate systemic failure.
The exact threshold is local policy. The important part is that the rule is pre-declared and consistent.
Escalation path
| Situation | Suggested path |
|---|---|
| Blocking critical found before release | release owner + security owner decide fix or postpone |
| Business insists on release despite control failure | escalate to engineering leadership + product owner + security leadership |
| Emergency release required | use named emergency approver and create immediate post-release review task |
| Persistent disagreement on severity | use predefined adjudication route, not endless ad hoc debate |
Emergency release pattern
Emergency releases should not remove governance. They should switch to a different, pre-approved governance mode.
Minimum emergency-release record
- reason for emergency
- what evidence was available at decision time
- who approved
- what controls were bypassed
- what follow-up and review are mandatory after deploy
Practical RACI
| Activity | Release owner | Engineering lead | Security | Platform / DevOps |
|---|---|---|---|---|
| define release scope | A/R | C | C | C |
| collect evidence | R | R | C | R |
| evaluate blockers | C | C | A/R | C |
| final production approval | A | A | C or A depending on policy | C |
| record exception / waiver | C | C | A/R | C |
| post-release retrospective | A/R | R | C | C |
Example sign-off checklist
- Are source changes fully reviewed and merged through protected controls?
- Did all required security jobs execute successfully for this release class?
- Is artifact provenance or signing available and verified where required?
- Are open exceptions explicit, approved, and time-bounded?
- Does the deployment target require an additional protected-environment approval?
- Is the rollback path documented?
Standards and best-practice anchors
| Theme | Useful external anchors |
|---|---|
| secure release process | NIST SSDF |
| CI/CD control weaknesses | OWASP Top 10 CI/CD Security Risks |
| provenance and integrity | SLSA, in-toto, Sigstore |
| review and SoD | OpenSSF branch protection and code review best practices |