DORA metrics are four delivery measures used to understand software performance: deployment frequency, lead time for changes, change failure rate, and mean time to restore. They help leaders assess whether a team can deliver changes quickly without increasing instability or operational risk.
Expanded Definition
DORA metrics are four flow measures originally popularised in DevOps research and widely used to describe software delivery performance: deployment frequency, lead time for changes, change failure rate, and mean time to restore service. In security and resilience discussions, they are useful because they expose whether teams can ship changes safely, recover quickly, and maintain operational control under pressure. They are not a compliance framework on their own, and they should not be confused with the EU Digital Operational Resilience Act, although the acronym overlap is common in industry writing. For regulatory context, see DORA and digital operational resilience and the EU Digital Operational Resilience Act (DORA) materials.
Definitions vary slightly across vendors and engineering teams in how each measure is calculated, but the core intent is consistent: measure speed and stability together rather than treating them as opposing goals. NHI Management Group treats DORA metrics as an operational signal, not a score to game. The most common misapplication is using them as a pure productivity KPI, which occurs when leadership rewards faster releases without also tracking change quality and recovery behaviour.
Examples and Use Cases
Implementing DORA metrics rigorously often introduces measurement overhead, requiring organisations to balance visibility into delivery performance against the cost of instrumenting pipelines and standardising data across teams.
- A platform team tracks deployment frequency to understand whether release bottlenecks are caused by change approval processes, brittle automation, or manual handoffs.
- A security engineering team uses lead time for changes to see whether remediation fixes, policy updates, or access-control changes are taking too long to reach production.
- A SRE function reviews change failure rate after infrastructure updates to identify patterns such as incomplete testing, poor rollback design, or weak release gating.
- A service owner monitors mean time to restore after incidents to measure whether recovery procedures, runbooks, and escalation paths are actually effective.
- A governance group compares trends over time rather than a single number, using the results alongside incident data and EU Digital Operational Resilience Act (DORA) obligations where resilience reporting matters.
These examples show why DORA metrics are best treated as a system-level lens. They help teams distinguish healthy delivery from reckless velocity, and they often reveal hidden dependencies that are not visible in planning tools alone.
Why It Matters for Security Teams
Security teams need DORA metrics because resilience failures usually emerge where change processes, access controls, and incident response collide. A low deployment frequency may indicate overcontrol, but it can also signal that security approvals, secrets handling, or environment provisioning are too manual to support safe change. A high change failure rate can point to weak testing of IAM policies, fragile CI/CD pipelines, poor configuration management, or insufficient validation before release. Mean time to restore is especially relevant when a compromised account, failed policy push, or broken automation path disrupts production and rapid containment becomes the priority.
For teams managing Non-Human Identities, these measures also expose whether automated workloads can be updated, rotated, and recovered without creating standing risk. That makes the metrics useful well beyond engineering performance discussions, because they highlight whether operational controls are actually resilient under real attack or outage conditions. The most important lesson is that delivery speed and resilience are inseparable in modern security operations. Organisations typically encounter the value of DORA metrics only after a failed release, a prolonged outage, or a security incident forces them to prove how quickly they can restore service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI | Recovery metrics align to response and recovery outcomes in cybersecurity operations. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration control underpins safe, measurable change delivery and rollback. |
| DORA | The EU act governs digital operational resilience, a common acronym collision with DORA metrics. |
Disambiguate the acronym in policy and reporting so delivery metrics are not confused with regulation.
