When security work will not fit, cut in this order: narrow the scope to the exposed path, split the work into slices, move low-risk items later, add a compensating control, and only then accept a dated risk. Cutting the fix entirely should be the last lever, not the first.
Start with the question behind the work
A ticket that does not fit is usually too large, not too important. Before trading it against a feature, ask what outcome it must deliver. Often the outcome is "remove exposure on the internet facing path," and the ticket describes a bigger clean-up. The Scrum Guide notes that scope may be clarified and renegotiated with the Product Owner as more is learned. Use that room before you ask for more capacity.
Five levers, in order
Lever 1: narrow the scope
Fix the instance that is reachable and exposed first. A vulnerable library used in one public service and three internal batch jobs can be patched in the public service this sprint. The rest follows later. Reachability evidence tells you which uses matter. Do not narrow by dropping verification, only by dropping coverage of lower risk areas.
Lever 2: slice it
Split a large change into pieces that each reduce exposure alone. A migration can ship the new library behind a flag, then move one service at a time. Each slice should be deployable and leave the system safer than before. If a slice leaves things in a worse state, it is the wrong slice.
Lever 3: reorder the rest
Use a cost of delay view. Items that are cheap and urgent go first, and items that are costly but slow-burning wait. The method is in how to rank security fixes with cost of delay and effort. Be honest about what is slow-burning. A new entry on the CISA Known Exploited Vulnerabilities catalog changes the answer.
Lever 4: add a compensating control
If the real fix cannot ship this sprint, reduce exposure another way: a network restriction, a feature flag that disables the risky path, or a rule at the edge. Be sure the control is live and tested before you count it. See how to prove a compensating control works.
Lever 5: accept the risk, formally
If nothing else works, record an exception with an owner, a reason, an expiry and a review date. Pick the owner according to who should own and accept a security risk. An unrecorded deferral is not acceptance. It is a hidden debt.
What not to cut
| Do not cut | Why |
|---|---|
| The test that proves the fix works | A fix without a test may not hold |
| Code review | Security changes get the same review as any other |
| The record of what was deferred | Without it, the item vanishes |
| The communication to the owner | They must know what remains open |
After the sprint
If the same work does not fit twice, the problem is capacity, not scope. Use the history to argue for a reserved slice, as in how much sprint capacity to reserve for security work, and bring a decision memo using this template.
Safeguard's reachability analysis shows which findings sit in code that runs, which supports narrowing scope on evidence. Its policies and gates help keep new problems out while the old ones are sliced.
Quick check
What should I cut first when time runs short?
Narrow the scope to the exposed, reachable path. It keeps most of the risk reduction at a fraction of the cost.
Can I skip the test to save time?
No. The test is how you know the fix works and keeps working. Cut coverage of low risk areas instead.
Sources
Last reviewed: 19 October 2026.
