The approver should be the person who owns the business risk, and never the author of the change. Security advises, engineering proposes, and an accountable owner signs. Write the roles into policy, then enforce them in the pipeline so the rule does not depend on good intentions.
Three roles, three jobs
| Role | Job | Should not |
|---|---|---|
| Author or release engineer | Proposes the waiver with analysis | Approve their own request |
| Security reviewer | Checks the analysis is sound | Own the business trade-off |
| Risk owner | Accepts the risk and sets the expiry | Delegate without a record |
The risk owner might be a product lead, engineering director or the person who owns the system's risk register. What matters is that it is someone with the authority to accept that risk on behalf of the organization.
Enforce it in tooling
A policy that lives only in a document gets bypassed under pressure. Pipelines can enforce it. GitHub's documentation on deployment environments, for example, describes required reviewers: you can list up to 6 people or teams, and only one needs to approve a job. It also describes a prevent self-review setting that stops users from approving workflow runs they triggered, and deployment branch restrictions that control which branches and tags can deploy.
Those settings map neatly onto the roles above. Require a reviewer from the risk owner group, switch on prevent self-review, and restrict production deploys to the release branch.
One caution: a click on an approval button proves that someone clicked. Pair it with a record of what they were shown, namely the findings and the analysis, or the approval proves little.
What the approver should see
- The failing findings, with severity, exploitability signals and reachability.
- The proposed waiver reason and compensating controls.
- The expiry date and the owner of the follow-up fix.
- Previous waivers for the same component.
Steps to set this up
- List who may accept risk at each severity level.
- Create a reviewer group in your pipeline for each level.
- Turn on self-review prevention.
- Log every approval to the release record.
- Review the approver list each quarter and after reorganizations.
Small teams
If you have only a handful of people, you may not have a separate risk owner. Use a second engineer for lower risk waivers and name an executive for anything known exploited. Write down who covers when someone is away.
Quick check
Can security approve the waiver alone?
Security should review the analysis, but accepting business risk belongs to the risk owner.
Is a chat message enough as approval?
Weak. Use a recorded approval linked to the release ID, with the findings attached.
Sources
Safeguard provides policies, gates and guardrails, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
