Usually not. When a fix pull request exists and passes your tests, the cost side of the decision has mostly gone, so an exception needs a specific reason: a breaking change, a freeze, or a failing test. Otherwise merge the fix and skip the paperwork.
What changed when the fix appeared
Risk acceptance exists because fixing is hard, slow or risky. A ready, reviewed pull request undoes most of that. Approvers should ask a blunt question: what is stopping the merge?
If the answer is "nothing, we are busy," that is a scheduling problem, not an acceptable risk.
Questions that decide it
- Do the tests pass? A green build is the main signal that the change is safe.
- How big is the version change? A patch bump rarely breaks anything. A major bump may. Read semver patch, minor, major: how risky is this fix PR.
- Is there a real constraint? A code freeze, a certified build, or a dependency that blocks the upgrade counts. A long review queue does not.
- Is the finding exposed? Internet-facing and exploited issues should merge first.
- What is the rollback plan? If reverting is easy, risk of merging falls.
A simple rule
| Fix PR status | Default |
|---|---|
| Exists, tests pass, low-risk change | Merge, no exception |
| Exists, tests fail | Fix tests or request a short exception with a plan |
| Exists, breaking change | Schedule with a dated exception |
| Does not exist | Normal triage, exception if no fix is possible |
Short exceptions still work
If you need a few days for a window or a review, a short, approved exception is fine. Set the end date to the planned merge date. That keeps the decision honest and creates a visible deadline.
Keep humans in control
Automated fix pull requests are proposals. Teams usually want to decide, per change type, what merges automatically and what needs review. The approach in approval tiers for automated fix PRs by change type is a practical way to do that.
Where Safeguard fits
Safeguard can open autonomous remediation fix pull requests, which are off by default with every category set to Manual, so your team chooses what gets proposed and merged.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a ready fix changes which findings need a decision at all.
Quick check
Is a busy sprint a valid reason for an exception?
Not by itself. Capacity is a planning issue. A short, dated exception is fine, but it should end on the planned merge date.
What if the fix PR changes behavior?
Then there is a real cost. Test it, plan the change, and use a time-boxed exception with compensating controls until it merges.
Last reviewed: 19 October 2026.
