DORA Reads Like Law. It Audits Like Your Architecture.

Since 17 January 2025, the EU grades financial software the way a good SRE would: not on whether it fails, but on how it behaves while failing. The rulebook is DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — and a year and a half in, I still meet fintech engineering teams who treat it as a document their counsel owns and they'll be briefed on eventually.

One collision to clear first, because search engines won't: this DORA is not DevOps Research and Assessment. If you came for deployment frequency and lead time, my review of Accelerate covers those four metrics; this DORA arrives with supervisors attached.

I should also say what I am and am not. I'm not a lawyer, and none of this is legal advice. I've spent two decades in enterprise operations, a good stretch of it on incident bridges at Clarivate scale, and DORA is the first piece of financial regulation I've read that feels written by someone who has been paged at 3 a.m. That's the seat this post is written from: the engineer who has to build under the rules, reading the rules as a spec.

The regulation assumes your system will fail — and grades the choreography

DORA stands on five pillars: an ICT risk management framework (Articles 5–16), incident classification and reporting (17–23), resilience testing (24–27), third-party ICT risk (28–30), and information sharing. Strip the legal scaffolding and Chapter II is an SRE handbook — identify, protect, detect, respond, recover, learn. The premise underneath all five pillars is the one operations people internalized years ago: failure is a property of the system, not an anomaly. What the regulation adds is that your response to failure now has to be legible from outside — documented, timed, and reproducible on request.

That word, legible, is the whole shift. Most engineering teams already do some version of this work. Few can prove it on a supervisor's schedule.

A 4-hour clock is an observability requirement in legal costume

The reporting timeline for a major incident runs on three clocks: an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours from detection), an intermediate report within 72 hours, and a final report within one month.

Read that as an engineer and the dependency is obvious: you cannot classify an incident in hours if classification is a judgment call made in a meeting. DORA's classification criteria — clients and counterparties affected, duration and service downtime, geographic spread, data losses, criticality of services — have to be computed, which means your monitoring already knows how many clients an outage touches and your incident tooling can produce that number while the incident is still open. A spreadsheet and a Tuesday review don't make a 4-hour clock. Instrumentation does.

There's a subtlety worth engineering around: the 4-hour clock starts at classification, not detection. A vague classification process doesn't buy you time — it moves the risk into an argument with a supervisor about when you should have classified. The teams that handle this well treat severity thresholds like alerting thresholds: defined in advance, evaluated by machines, escalated to humans for confirmation rather than debate.

And the report goes to your national competent authority on their template, not to a mailbox in prose. That sounds trivial until you've tried to fill a structured regulatory template at hour three of an outage, with the people who know the answers busy fixing the outage. The fix is the same one we use for status pages: the incident record is the report's data source, and someone who isn't on the bridge owns the submission. Deciding that during an incident is how you lose an hour you were given four of.

Someone will attack your production system, with permission

Pillar three includes threat-led penetration testing (TLPT) for entities significant enough to qualify: a red team, aligned with the TIBER-EU framework, attacking live production, roughly every three years.

The staging-only pentest culture ends there. When the test target is production, every comfortable fiction becomes testable — the network segmentation that exists in the diagram, the break-glass account nobody has rotated, the detection rule that fires in staging where the noise floor is quiet. I've watched production incidents expose all three; TLPT just schedules the exposure while the stakes are survivable.

Your vendor list became a regulated artifact

The pillar with the most day-to-day consequence for how you build is third-party risk. Every ICT arrangement goes into a register of information: what function it supports, how critical that function is, whether the provider is substitutable, and who they subcontract to. That last field is the one that surprises engineering teams — the register wants the chain, not the first link. Your managed database vendor runs on a hyperscaler; your fraud-scoring API calls a model provider; the register expects you to know, and supervisors have been collecting these registers from financial entities since 2025. In practice it's a dependency graph — the same artifact you'd build for a serious availability review, which is exactly the point. Contracts with critical providers must carry audit rights, service levels, termination assistance and a tested exit strategy (Article 28). Supervisors can, and do, ask the concentration question: what happens to you if this one cloud region, or this one provider, has a very bad day? The CrowdStrike outage of July 2024 — 8.5 million systems down through one vendor's update — is the case study regulators no longer have to hypothesize.

This is also where an external engineering partner shows up, and I'll disclose the interest plainly: Conectia embeds engineers with regulated clients, so we are an entry in registers like these. An engagement with a fintech has to be legible to this pillar from day one — who holds which access, under what contract, and what the exit produces. It's part of why our engagements end with a documented handover and a safe delete: every credential, mailbox and repository access accounted for and closed out. In a DORA context that isn't courtesy. It's the evidence your register points to when someone audits the exit.

The honest counter-argument: compliance is not resilience

Now the concession, because it's real: you can satisfy DORA on paper and still be fragile. A register can be complete and stale. A tested exit plan can be tested against last year's architecture. Proportionality (Article 4) means a 20-person fintech isn't running TIBER-EU exercises, and the incident that takes you down may arrive through a compliant vendor anyway — CrowdStrike's victims included plenty of institutions with immaculate paperwork.

So why do I defend it? Because DORA makes resilience work fundable. Every operations engineer has lost the budget argument for observability, for a second region, for the deprovisioning audit — work with no feature attached. DORA reprices that argument. The board that wouldn't fund incident tooling as engineering hygiene will fund it as a regulatory deadline, and the work is identical. Take the funding.

What I'd do this quarter if I ran engineering at a fintech

1. Wire the classification criteria into monitoring. Clients affected, downtime, data loss — computed fields on the incident record, not prose written afterwards.
2. Run one reporting fire drill. Take a past sev-1, replay it against the 4h / 72h / 1-month clocks with the actual reporting template, and time every step. The gaps you find are your backlog.
3. Build the register as data, not a document. A vendor inventory in version control, with owner, criticality and subcontractor fields, reviewed on a cadence — a stale register is the failure mode.
4. Ask every critical vendor for their exit story. Then test one: restore the backup, export the data, rebuild the pipeline. An exit strategy that has never run is a hypothesis.
5. Make offboarding produce evidence. Every leaver — employee or external — should close out with an access checklist someone signs. Endings are where audit trails go to die.

Eighteen months into DORA, the teams that struggle are mostly the ones still translating it through legal into engineering, one memo at a time. Read it yourself, once, with an operator's eyes. It reads like law. It audits like your architecture.

---

If you're staffing resilience work under regulatory deadlines and want engineers who have operated under audit before, talk to a CTO.