MATTHEW D. WEBB

Engineering Leadership

The two DORAs

One DORA measures how fast you ship software. The other fines you for not proving you would survive a bad day. They keep turning up in the same meetings, answering to the same name.

· 4 min read

Drafted and revised with AI to a series brief, images included; the confusion described is observed first-hand.
Editorial cover: two name badges both reading DORA, one measuring delivery, one regulating resilience Two conference name badges hang side by side, both reading DORA. The left badge carries four small delivery gauges; the right carries a regulation document with a circle of EU stars and an IN FORCE stamp. A double-headed arrow with a question mark sits between them. HOW FAST DO YOU SHIP? WOULD YOU SURVIVE TUESDAY? HELLO, I MEASURE DORA four gauges · zero auditors HELLO, I REGULATE DORA 2022/ 2554 IN FORCE ? Same badge, different questions. One asks how healthy your engine of change is. The other asks who has already decided how bad Tuesday is allowed to get.

There is a moment I have now watched happen in three different organisations. Someone senior says "we need to get on top of DORA" and the room splits cleanly in two: the engineers start talking about deployment frequency, and the risk people start talking about incident reporting deadlines. Both halves nod along for a good ten minutes before anyone realises they are discussing entirely different documents.

This is not anyone's fault. The industry genuinely shipped two DORAs, both aimed at technology organisations, both fond of the word resilience, both now unavoidable. It seems worth writing down which is which, because the cost of confusing them has stopped being social awkwardness and started being regulatory.

The one with the gauges

The first DORA is DevOps Research and Assessment: a research programme, later acquired by Google, that spent a decade surveying tens of thousands of teams and distilled delivery health into four metrics. Lead time for changes, deployment frequency, change failure rate, time to restore service. The findings are genuinely useful and genuinely misused, usually by pointing them at individuals, which I have complained about at length already.

This DORA is descriptive. Nobody audits you against it. It tells you about the health of your delivery system the way a resting heart rate tells you about fitness: a good signal, a terrible target, and no court in the world will ask about it.

The one with the lawyers

The second DORA is the EU's Digital Operational Resilience Act, Regulation 2022/2554, applying to financial entities since January 2025. It is not a survey. It is law, and it reads like the aftermath of every outage the sector has ever had.

It wants ICT risk management that the board actually owns. It wants major incidents reported to regulators on fixed clocks, not when the comms team feels ready. It wants resilience testing up to and including threat-led penetration tests. And, the part with the sharpest teeth, it wants third-party risk taken seriously: registers of every ICT provider, contractual exit plans, and a hard look at concentration risk, which is the regulator's polite phrase for what happens when half the sector discovers it lives in the same cloud region.

The UK runs a parallel regime rather than DORA itself: the FCA and PRA's operational resilience rules, in force in full since March 2025, built around naming your important business services, setting impact tolerances for each, and proving you can stay inside them during severe but plausible scenarios. Different paperwork, same conviction: it is no longer enough to recover eventually. You have to have decided, in advance and in writing, how bad you are allowed to let things get.

Same rooms, same people, different questions

The collision matters because both DORAs now attend the same meetings. A CTO who tells the risk committee "our DORA numbers are excellent" has, at best, answered a question nobody asked. Four green delivery gauges say nothing about whether the payments service has a tested exit plan for its cloud provider, and an immaculate register of ICT third parties says nothing about whether the team can ship a fix in under a day.

The two DORAs are asking different questions about the same system. The metrics one asks: how healthy is your engine of change? The regulatory one asks: when the engine catches fire, who has already decided which passengers get out first, and can you show me the drill logs?

A firm can be elite at one and negligent at the other. Plenty are.

Where they quietly agree

Underneath the vocabulary, the two share a temperament, and this is the useful part. Both are allergic to vibes. The research DORA replaced "we feel like we ship fast" with numbers; the regulatory DORA replaces "we believe we would recover" with evidence: tests run, tolerances stated, scenarios rehearsed. Change failure rate and time to restore are, squinting only slightly, the delivery-side cousins of the Act's incident classification and recovery objectives.

So the honest posture is not to pick a favourite. Use the metrics DORA to earn the right to change systems quickly, because resilience is mostly an organisational property and a team that ships small and often recovers small and often. Use the regulatory DORA as the annual exam that checks the recovery story is written down, rehearsed and survivable by someone other than the one engineer who knows where the runbooks live.

And when someone says "DORA" in a meeting, ask which one. It is a five-second question that saves ten minutes of two conversations answering to one name.

Further reading

Keep reading

Human (you) in the loop

New writing, now and then

Occasional notes on platform engineering, building dependable software and that constant buzz word we doom scroll past on LinkedIn! No cadence promised.

Prefer a reader? Subscribe via RSS.

← All Articles

Jump to

35 articles