DORA's guide says its delivery metrics are meant for one application or service at a time, and that blending them across teams can be problematic. The same logic applies to security numbers. A company-wide average of vulnerabilities or fix times hides the one service that is actually in trouble.
What DORA says about scope
The DORA guide states the metrics "are meant to be applied at the application or service level" and are best suited to measuring one application or service at a time. It warns that comparing very different applications can mislead, and that blending metrics across teams or organizations is problematic.
An engineering director often wants one number for the whole company. The research behind DORA argues against that, because a payments service and an internal wiki have different change rates and different consequences when they fail.
The averaging problem in security
Suppose you have 20 services. Nineteen fix critical findings in four days. One legacy service takes 90 days. The company average looks acceptable, around 8 days, and nobody looks at the slow one.
Per-service numbers show it immediately. The same trap appears with scan coverage: 95 percent overall can mean one customer-facing service is not scanned at all.
How to set up per-service measures
- Keep a service inventory with an owner for each service. Without ownership, a number has nobody to act on it.
- Tag every finding, deployment and incident with a service name.
- Compute each metric per service: the five DORA measures plus time to remediate and scan coverage.
- Roll up with distributions, not averages. Show how many services are within target and name the ones outside it.
- Compare each service with its own history, not with an unrelated service.
What a roll-up can honestly show
| Roll-up | Honest? | Why |
|---|---|---|
| Count of services outside their remediation target | Yes | Names the problem |
| Median of per-service medians | Careful | Hides outliers, so show the worst few too |
| Company-wide average fix time | Rarely | Mixes unlike services |
| Ranking teams against each other | No | DORA warns against competition between teams |
Be careful with ownership
DORA also warns that giving isolated teams specific metrics can create friction and finger-pointing. Per-service does not mean blame. Use the numbers to decide where to put help, such as pairing a slow service with someone who has fixed similar issues.
Quick check
Should the board see per-service numbers?
Usually a short list is enough: services outside target, and the trend. Keep full per-service tables for the engineering review.
What if services are too small to measure?
Group closely related components under one service. Tiny counts are noisy, so look at trends over months rather than weeks.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how dependencies are listed per project. That is the grain you need before any per-service security number makes sense.
How Safeguard fits
Safeguard offers asset discovery, SBOM and dependency scanning, so findings can be tied to the service that owns them. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics (application-level use and misuse guidance): https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
