Remediation throughput is the number of vulnerability fixes that reach production in a period, such as a week. Count deployed fixes, not opened tickets or merged pull requests, and split the count by fix type. It tells you how much your team can clear, which is the number every capacity plan needs.
What counts as one unit of throughput
Pick a unit and hold it steady. The cleanest choice is one finding fixed and deployed, meaning the vulnerable version is no longer running anywhere you track. A pull request that bundles five dependency bumps closes five findings, so count five, but also record that it took one review.
Do not count closed tickets. Tickets can be closed as accepted risk, as duplicate, or as won't fix. Those are decisions, not fixes. Track them as a separate line so they never inflate your fix numbers.
Borrow the delivery metrics you already have
Engineering teams often already track delivery speed. DORA describes software delivery throughput through three factors: change lead time, deployment frequency, and failed deployment recovery time. Security fixes are changes, so the same ideas apply.
| Delivery idea | Remediation version |
|---|---|
| Change lead time | Time from a finding being triaged to the fix running in production |
| Deployment frequency | How often fix batches actually ship |
| Failed deployment recovery time | How quickly a bad fix is rolled back or repaired |
If your fixes sit in a pull request for a week and then deploy in minutes, the bottleneck is review, not engineering. Lead time split into stages shows that. For the stage view, see remediation pipeline stage times from find to deploy.
Split throughput by fix class
One blended number hides the story. A team that clears forty patch bumps and zero major upgrades has a very different capacity from one that clears ten of each. Use at least three classes:
- Patch or minor bump with no code change.
- Major upgrade or code change needed.
- No fix available, so mitigation, replacement or an exception.
Report each class separately each week. Class one is where automation helps most. Class two is where engineer hours go. Class three is a decision queue, and its throughput is measured in decisions made.
Pair it with inflow
Throughput alone means little. A team clearing thirty fixes a week is falling behind if forty new findings arrive. Chart both, as described in the inflow and outflow chart for vulnerabilities. The gap between the two lines is your real trend.
Common measurement mistakes
- Counting fixes merged rather than deployed, which flatters teams with slow release trains.
- Mixing noise with real risk. A fix for an unreachable finding and a fix for an exploited one are not equal units, so keep a priority tag on each.
- Measuring individuals. Throughput is a property of the system: review queues, CI time and release cadence. Using it to rank engineers invites gaming.
- Changing the unit mid-year, which breaks every trend line.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the findings view and look at how a finding moves between states. Each state change is a place to timestamp for your stage metrics.
Where Safeguard fits
Safeguard keeps findings, ownership and fix state in one place, so inflow, closed fixes and time to fix can be read from the same record. You can start with the free scan to see your current inventory.
Quick check
Is a merged pull request the same as a completed fix?
No. A fix is complete when the corrected version is deployed and the old one is gone. Merged but undeployed work still leaves the exposure open.
How many weeks of data do I need before planning with it?
Enough to cover a normal release cycle plus a slow period. A few weeks is a start, but treat early numbers as rough and recheck them as the sample grows.
Sources
Last reviewed: 19 October 2026.
