Tag every unplanned production deployment with a cause, including security, at the moment it is created. Deployment rework rate then tells you how many unplanned deployments you made, and the tag tells you how many came from security incidents, without anyone reconstructing the story later.
What rework rate measures
DORA's guide defines deployment rework rate as the ratio of deployments that are unplanned but happen as a result of an incident in production. It sits in the instability group beside change fail rate. An emergency patch for an exploited vulnerability is a clear example. A planned upgrade done to stay current is not, because nothing forced it.
Why tagging beats memory
Months later, nobody remembers why a Tuesday night deployment happened. Teams then argue about whether it counts. A cause tag recorded at creation removes the argument and lets you count by category.
A minimal tag set
| Tag | When to use |
|---|---|
| security | Fix for a vulnerability, exposed credential or exploited weakness |
| bug | Functional defect affecting users |
| performance | Slowness or capacity incident |
| config | Misconfiguration or bad environment change |
| dependency | Third party failure not caused by your code |
| other | Everything else, reviewed monthly |
Keep it short. Ten tags will not be used consistently.
How to apply it
- Add a required cause field to your incident or hotfix ticket template.
- Link the deployment to the ticket, so each unplanned deployment has a cause.
- Define unplanned in one sentence, such as "not on the release schedule and prompted by a production incident".
- Review untagged and other items weekly, so the data stays clean.
- Report rework rate overall and the security share separately.
Reading the result
If security is a large share of rework, ask where the problems entered. Were they in new code, in a dependency, or in configuration? The answer points to a different control each time: code review, dependency gates, or configuration checks.
If the share is small, that does not mean security is fine. Many vulnerabilities are fixed in planned releases and never counted as rework. Pair this view with time to remediate, which covers the planned fixes too.
A caution on fear of the number
If teams are judged on rework rate, they may stop calling things incidents, or fold urgent fixes into scheduled releases. DORA warns against setting metrics as goals for that reason. Make the number a conversation starter, and sample incidents now and then to check the tagging.
Quick check
Does a fix for a vulnerability found by our scanner count as rework?
Only if it was an unplanned deployment prompted by a production incident. A scheduled fix found by routine scanning usually is not.
Who should apply the tag?
The engineer closing the incident, with a reviewer checking weekly. Security should not have to tag everything for others.
How Safeguard fits
Safeguard offers autonomous remediation with fix PRs (off by default, every category on Manual) and continuous monitoring, which can move fixes into planned work before they become incidents. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
