Yes. If a security fix is a sized story that the team completes, it consumes real capacity and belongs in velocity. The trick is to tag it so you can also report security throughput on its own. Without the tag, leaders see a slower team and cannot tell why.
Why velocity should include it
Velocity is a planning tool. It answers one question: how much of the next sprint can we fill with similar work? A team that does fixes but leaves them out of the number will over-commit every sprint, because the fixes still take time.
The Scrum Guide says the more a team knows about its past performance, its upcoming capacity and its Definition of Done, the more confident its sprint forecasts will be. Past performance has to cover all the work the team really does, or the forecast is wrong from the start.
The case against counting it
Some managers fear that counting security work lets it hide inside the feature total. They worry that "we did 40 points" will hide that none of it reduced risk. That is a reporting problem, not a velocity problem, and tags solve it.
Another objection: security work is often reactive and lumpy, so it makes velocity noisy. True. Handle that by budgeting for it, not by excluding it. See how much sprint capacity to reserve for security work for one way to set the slice.
A simple tagging scheme
Add one label to every ticket that mainly reduces risk. Keep it narrow so the label stays meaningful.
| Label | Use it for |
|---|---|
| security-fix | Closing a known vulnerability or weakness |
| security-control | Adding a preventive control, such as a gate or a check |
| security-spike | Time-boxed investigation of a risk question |
Then report two numbers each sprint: total velocity, and the share that went to labelled security work. A sudden jump in the second number is a signal, not a failure. It usually means a dependency advisory or an audit request landed.
What to do with points
Give the fix the same points you would give a feature of equal effort. Do not discount it because it feels small, and do not inflate it to make the security share look bigger. If you need to calibrate, keep a few reference tickets of known size. A longer treatment is in how to estimate security work in story points.
Two cases need care:
- Carry-over. If a fix keeps slipping, do not split it into tiny tickets just to bank points. Finish it or re-plan it.
- Bot-opened fixes. If a tool opens a pull request and your team only reviews it, the effort is the review. Size that, not the whole fix.
How to present it to leadership
Show velocity as a stable baseline and the security share as a trend line. The message is: "Our capacity did not drop, we spent part of it reducing exposure, and here is the backlog that remains." That is easier to defend than a lower number with no explanation.
If leadership wants to ban security from velocity so the feature number looks higher, say that the forecast will then miss, and offer the two-number report as a compromise.
Safeguard's autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual, so a human approves each change. That review time is still team capacity and belongs in the sprint plan.
Quick check
Should a security spike get points?
Many teams time-box spikes in hours or days instead of points, then count the time against capacity. Pick one method and use it consistently.
Does counting security work lower velocity?
It does not lower real throughput. It makes the number match what the team actually delivers, which improves forecasting.
Sources
Last reviewed: 19 October 2026.
