A useful scorecard fits on one page, covers one service, and shows the five DORA delivery metrics beside four security measures over the same weeks. Build it with the checklist below, and agree on definitions and owners before anyone looks at a number.
Before you start
- One service chosen, with a named owner
- A time window agreed, such as the last 12 weeks
- A person from engineering and a person from security assigned
- Agreement that the page is for conversation, not ranking
DORA's guide says the metrics are best used for one application or service at a time, and warns against competition between teams. Both points shape this checklist.
Delivery section: five rows
| Row | Definition to write down |
|---|---|
| Change lead time | Start: committed to version control. End: deployed in production |
| Deployment frequency | Count of production deployments per week |
| Failed deployment recovery time | Time to recover from a deployment needing immediate intervention |
| Change fail rate | Share of deployments needing immediate intervention |
| Deployment rework rate | Share of unplanned deployments caused by a production incident |
Checklist for this section:
- Each definition written in one sentence and shared
- "Immediate intervention" defined, for example rollback or hotfix
- "Unplanned" defined
- Median and worst case shown for time-based rows
Security section: four rows
| Row | Definition to write down |
|---|---|
| Time to remediate | Identified to fix deployed, by severity |
| Scan coverage | Share of the service's repos and images scanned in the window |
| Open exploitable findings | Findings with a known exploit or reachable path |
| Gate outcomes | Passed, blocked and overridden pull requests |
Checklist for this section:
- Severity scale stated, and the source of severity named
- Coverage denominator defined, such as repos on the service inventory
- Exploitable defined, and who decides
- Overrides include the approver and reason
Review rules
- Read rows in pairs: lead time with overrides, frequency with fail rate
- Look at trends over weeks, not a single week
- Note small samples. A week with two deployments says little
- Record one action per review, with an owner and date
- Revisit definitions each quarter
What to leave out
Leave out any ranking of people, any figure with no named owner, and any number you cannot explain in one sentence. DORA warns against having one metric to rule them all, so the page should never lead with a single headline score.
After the first month
Ask what the page changed. If no decision followed from any row in a month, remove the row. If a decision was made with a missing number, add it. Over time the page should shrink to the rows people act on.
Quick check
How many services should we start with?
One. Extend to others after the definitions have held for a quarter.
Can the scorecard be automated?
Yes, once definitions are stable. Automate the data pulls, not the review conversation.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how status changes over time, the same trend view the scorecard needs.
How Safeguard fits
Safeguard offers dependency scanning, policies and gates, and continuous monitoring, which supply the security rows. 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.
