Give security work a fixed, protected slice of every sprint, sized from your recent alert and ticket load rather than a universal percentage. Start small, review it each quarter, and treat it as committed work with a named owner, not as whatever time is left over.
Why a fixed slice beats leftovers
Security work has no deadline until something goes wrong, so it loses every prioritization contest against features. Teams that rely on leftover time rarely have any. A standing allocation removes the argument. The work is already in the plan, and the question each sprint becomes which items fill the slice, not whether to do security at all.
No published figure fits every team, so avoid copying a percentage from a blog post, including this one. Size yours from your own data.
How to size it
- Count last quarter's security items. Pull dependency alerts you acted on, security tickets, access fixes and incident follow ups.
- Estimate their cost in the units you already use, story points or days.
- Set the slice to roughly cover the recurring load, then add a little room for one improvement item per sprint.
- Review after a quarter. If the slice is always empty, shrink it. If it overflows, grow it or cut the sources of noise.
What goes into the slice
| Kind | Examples |
|---|---|
| Routine | Merge safe dependency updates, review the exploited list |
| Reactive | A fix for a real exposed finding, a revoked credential |
| Improvement | Add a pull request check, tighten one role, write one runbook |
| Debt | Retire an end of life runtime, remove an unused service |
Keep the mix visible. If the slice is all reactive, you are treading water and should look at why alerts are so noisy. Triaging by exposure usually shrinks the reactive share.
Make it stick
Put the slice in the sprint plan as a labeled block. Give it an owner who rotates each sprint, so the knowledge spreads and nobody becomes the permanent security person by accident. Count it in velocity, so it is not seen as a tax.
When an urgent item arrives, such as an actively exploited vulnerability in something you run, it can borrow from feature time. Say so openly and record it. Borrowing is fine, silently skipping the slice is not.
Explain it to the business
Frame it as maintenance, the same way you would defend time for deploys or on call. A short line works: this time keeps customer data and uptime safe and keeps buyer questionnaires easy to answer. If a founder asks what the slice produced, answer with the quarterly review record, not with a metric you made up.
Common mistakes
Setting the slice once and never revisiting it. Letting one person absorb all of it. Filling it with low value scanning noise. Cancelling it in a crunch and not restoring it afterward.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Is ten percent a good number?
There is no universal answer. Use your own recent alert and ticket load, then adjust each quarter.
What if we have a crunch release?
Shrink the slice for that sprint on purpose, record it, and restore it the following sprint.
Last reviewed: 19 October 2026.
