Tell a security leader that DORA metrics describe how quickly and how stably a team ships changes, per service, and that security touches each of them. Then show the five metrics beside two security measures and ask which questions the combination answers that either set alone cannot.
The one-page explanation
DORA is a research program on software delivery. Its guide groups five metrics. Three describe throughput: change lead time, deployment frequency, and failed deployment recovery time. Two describe instability: change fail rate and deployment rework rate. They are meant for one application or service at a time.
For a security leader, translate each into a security question.
| Metric | Security question it prompts |
|---|---|
| Change lead time | How long does a fix take to reach production once written? |
| Deployment frequency | How often can we ship a patch if we must? |
| Failed deployment recovery time | If a change goes wrong, how fast can we undo it? |
| Change fail rate | How often do changes need urgent intervention? |
| Deployment rework rate | How many unplanned deployments come from incidents, including security ones? |
Why a CISO should care
Patch speed is bounded by delivery speed. A team that deploys once a quarter cannot respond to a critical advisory in a week without heroics. A team that deploys daily with fast rollback can. The metrics show whether the machinery for fixing things exists.
What the metrics do not show
They say nothing about the number of known vulnerabilities, their severity, whether they are reachable, or how long they stay open. Ask for those separately, as time to remediate by severity, open exploitable findings, and scan coverage.
Questions to ask in the first meeting
- For our five most important services, what are the five metrics today?
- How long is the path from a merged fix to production for each?
- How do we tag security-driven unplanned deployments?
- Where in lead time do security checks sit, and how long do they take?
- Which services are not scanned at all?
Cautions to share up front
DORA warns against setting the metrics as goals, relying on one metric, comparing unlike applications, siloing ownership, and competing between teams. Agree early that these numbers start conversations. They are not a scorecard for individuals. See six ways to misuse DORA metrics.
A good outcome for the meeting
The security lead and the engineering lead leave with a shared two-row view for one pilot service, a named owner for each row, and a date for the next review. That is enough for a start.
Quick check
Is DORA the framework a CISO already knows?
Often not, and the name collides with the EU Digital Operational Resilience Act. State early that you mean the delivery research program.
Should the CISO own these metrics?
Engineering owns the delivery metrics. The CISO owns the security measures. Review them together.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how severity and status are shown, which are the security rows to place beside the delivery metrics.
How Safeguard fits
Safeguard offers dependency scanning, reachability analysis and continuous monitoring, which supply the security rows for such a view. 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.
