The Four DORA Metrics and the Naming Clash

Executive Summary

• DORA now names two unrelated things: a set of four engineering metrics for how well software gets delivered, and a binding piece of European law about surviving IT disruption. This guide explains both and shows where they overlap.
• The four DORA metrics measure delivery: how often you ship, how quickly changes reach production, how often they fail, and how fast you recover.
• The Digital Operational Resilience Act is Regulation (EU) 2022/2554, in force for financial entities and their technology suppliers since 17 January 2025.
• ProfessNet runs a dedicated NIS2 and DORA readiness audit for regulated clients, so telling these two apart, and acting on both, is work we do every week.

What Are the Four DORA Metrics?

The metrics come from a research program that has studied software delivery since around 2014, led originally by Nicole Forsgren, Jez Humble and Gene Kim and later carried forward by a dedicated research team at Google Cloud. Its findings appear each year in the Accelerate State of DevOps reports, drawing on surveys of tens of thousands of practitioners. Out of that work came four measurements that reliably predict how well a team delivers software, and they fall into two groups.

The first group is about throughput. Deployment Frequency asks how often a team successfully releases to production, and Lead Time for Changes asks how long a single commit takes to travel from version control into the hands of users. Together they describe speed: how quickly good work reaches the people who benefit from it.

The second group is about stability. Change Failure Rate is the share of deployments that cause a problem in production serious enough to need a fix or a rollback, and Time to Restore Service is how quickly the team recovers when that happens. One piece of trivia matters for anyone reading the source material: the official project has since renamed the recovery metric to Failed Deployment Recovery Time, and added a fifth measure, Reliability, to capture how consistently a service meets its targets. The classic four remain the ones most teams talk about.

The value of the metrics comes from reading them together. High throughput means little if changes keep failing, and a spotless failure rate is small comfort if releases crawl out once a quarter. The research sorts teams into performance levels, from Low through to Elite, and finds that the strongest performers manage speed and stability at the same time rather than trading one away for the other. Used well, the four metrics are a compass for improvement. Used carelessly, as a target to be gamed, they lose their meaning fast.

So, Why Does the Name Cause So Much Trouble?

Here is the catch. Everything above describes a voluntary measurement framework for engineers. There is a second DORA, and it could hardly be more different. Both share the same four letters, and both live in the same broad territory of software, operations and resilience, which is exactly why they get tangled. A quick web search for “DORA requirements” can return financial regulation when you wanted engineering guidance, or the reverse. Inside a regulated company, a DevOps lead and a risk officer can each say the team needs to improve its DORA position and mean completely different programs of work. Getting value from either one begins with knowing which is on the table.

One is a scoreboard a team keeps by choice. The other is a law it is bound by.

What Is the Digital Operational Resilience Act?

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, was adopted in December 2022 and became applicable on 17 January 2025. It exists to make sure financial entities can withstand, respond to and recover from disruption to their information and communication technology, whether that disruption comes from a cyberattack, a software failure or an outage at a supplier.

Key fact: DORA is a Regulation, not a Directive. It applies directly and identically in every EU member state, with no national transposition to slow it down or soften it. Its cross-sector cousin, the NIS2 Directive, works the other way and has to be written into each country's law first.

Its reach is wide. Around twenty categories of financial entity fall inside it, from banks and insurers to investment firms, payment and electronic money institutions and crypto-asset service providers. It also reaches the technology suppliers those firms depend on, in two ways. Providers judged critical to the sector are supervised directly by the European authorities, and every other supplier is drawn in through contractual requirements that flow down the chain from the financial entity. The first list of critical providers, published in November 2025, named the large cloud and technology platforms that most institutions already rely on.

The Act rests on five pillars: managing ICT risk, reporting significant incidents on a defined clock, keeping control of third-party providers through a register of information, testing resilience including threat-led penetration testing, and sharing threat intelligence with peers. Through 2026, the tone of supervision has hardened. The informal settling-in period is over, and regulators have moved from reviewing policy documents to asking for evidence that resilience is real. For the largest institutions, findings now feed into the wider supervisory review process, and responsibility sits squarely with the management body, whose members can be held personally accountable. The second annual cycle of the register of information closed in early 2026.

If Someone Just Says DORA, Which One Do They Mean?

Quick answer: Listen to the words around it. Deployment frequency, lead time, and performance levels point to the metrics. Registers of information, supplier contracts, audits, and supervisors point to the law.

The table below maps the usual signals to the DORA behind them.

Have the Two DORAs Ever Met?

For all their differences, the two DORAs share a patch of common ground, and it is the most useful thing to understand about them. Both care deeply about recovery and reliability. A team that drives down its recovery time and holds its reliability targets is, in practical terms, strengthening exactly the operational resilience the regulation is trying to secure. The Act even requires resilience testing, which echoes the stability half of the metrics. The consequence is a welcome one: the telemetry an engineering team gathers to improve its own scoreboard is often the very evidence a supervisor now expects to see.

This is one reason we built our ZEUS Security360 console to keep operational signals and audit-ready evidence in the same place, so that running systems well and proving they run well stop being two separate jobs.

Where Should a Regulated Team Start?

A few practical moves keep the two DORAs from working against each other.

• Settle the vocabulary. Decide as a company that “DORA metrics” means delivery performance and “the DORA regulation” means the Act, then hold everyone to it.
• Confirm scope before anything else. Most of the risk, and most of the confusion, starts with an unclear picture of whether the Act applies to you and which contracts sit inside it.
• Keep the register alive. Treat the register of information as a living asset rather than a form to file once and forget.
• Share the resilience work. Make resilience testing and recovery drills shared work between engineering and risk, since the same practice lifts the metric and satisfies the mandate.
• Instrument once, use twice. Capture recovery and reliability data in a form that serves both the engineering scoreboard and the compliance file.

Both DORAs are here to stay, and both reward organizations that take measurement seriously. Whether the goal is to deliver software better or to show a supervisor that you can withstand and recover from disruption, the foundation is the same: clear metrics and honest evidence. If your team needs help with either, or with telling them apart in the first place, that is precisely the kind of work ProfessNet does.