There is no correct percentage, and anyone quoting one is guessing. A workable method is to reserve a small slice of each sprint for security, split it into planned and reactive parts, and review the split every quarter against what the work actually took. Start modest and let your own data adjust it.
Why a reserved slice helps
When security tasks compete with feature tickets one by one, features win. They have a named requester and a date. Security work has a diffuse beneficiary and no deadline until something breaks.
A reserved slice changes the question. Instead of asking whether this fix deserves a place over a feature, the team asks which security items fit in the capacity already set aside. That is a much easier conversation to repeat every sprint.
Split the slice by purpose
Treat the reserved capacity as three buckets.
- Planned: items from the security roadmap, such as removing a deprecated library or adding rate limits.
- Reactive: urgent fixes, customer questions, vulnerability reports. This is unpredictable per sprint and fairly steady over a quarter.
- Maintenance: routine upgrades, key rotation, access cleanups.
Keeping them separate stops reactive work from silently eating the planned work. If the reactive bucket overflows every sprint, you have learned something real about your system and can raise it with evidence.
Pick a starting number from your own history
Look back over the last two or three quarters. Roughly how much engineering time went to security fixes, dependency upgrades and urgent patches, even when nobody labeled it? Most teams are surprised that the figure is not zero. Use that as the baseline, then decide whether it needs to go up.
If you have no history, begin with a small, deliberate amount, run it for a quarter, and tag the tickets so you can measure. A guess you track beats a policy you never test.
Make the work countable
Add a label to security tickets so they can be summed. Record the points or hours, whichever your team uses. For help sizing the tickets themselves, see how to estimate security work in story points.
Review three numbers each quarter: capacity used, work completed, and work waiting. If waiting work keeps growing while the slice is fully used, the slice is too small or the backlog is mis-prioritized. Both are fixable once you can see them.
Handle the sprint that goes wrong
Sometimes a major issue consumes everything. Decide beforehand what happens: the reserved slice expands, and the team agrees which feature work slips. Make the trade explicit in the sprint review so the product owner is not surprised. Do not borrow quietly from the following sprint's slice, or it will always be empty.
Try it yourself
The demo below shows a vulnerability queue with severity and fix status. Click through to see how work sorts, and notice which items could realistically fit inside a small reserved slice.
Click through it at your own pace, or open it full screen.
Quick check
What percentage of a sprint should security get?
There is no universal figure. Measure what security related work already costs your team, reserve a deliberate slice near that, and adjust quarterly.
Why split reactive from planned security work?
Reactive work is unpredictable per sprint. Without a separate bucket it consumes the planned work and the roadmap never moves.
Last reviewed: 19 October 2026.
