DORA explained: what the Digital Operational Resilience Act asks of the developers who serve financial clients

The honest starting point: I build for DORA, I am not a financial entity

DORA is the Digital Operational Resilience Act, Regulation (EU) 2022/2554, and it has applied across the European Union since 17 January 2025.¹ It is a law for the financial sector: banks, insurers, investment firms, payment and e money institutions, crypto asset service providers and many more.¹ I am none of those. I build software.

So why does a law for banks matter to a developer? Because DORA does not stop at the financial entity. It reaches the companies that supply the financial entity's technology, and it reaches them through the contract. A financial entity has to push a set of resilience and security obligations down into every contract it signs with an ICT third party service provider, and if I build the customer dashboard for a payments firm, I am one of those providers.¹ I am pulled in by the clauses in my contract, not by the regulation naming me directly.

That distinction is the whole article, and it is the honest line I hold to. I am an ICT provider to a financial client. I am not a regulated financial entity, I never present as one, and building to DORA does not make me one. My job is to build and to contract in a way that lets a financial client meet DORA. This piece sits under my work on business critical software, which is the parent to all of this, and it is the most contractual version of that discipline I deal with.

The businesses in the worked example are invented. The law, the dates and the articles are footnoted to the regulation and to the European Supervisory Authorities.

What DORA is and when it started

DORA sets, in its own words, "uniform requirements concerning the security of network and information systems" that support the business of financial entities.¹ Before it, operational resilience and the handling of technology risk were covered unevenly across member states and across different pieces of financial law. DORA pulls that together into one regulation, directly applicable in every member state without a national transposition step, which is why it is a regulation and not a directive.

It entered into force on the twentieth day after publication in the Official Journal in late 2022, and it has applied since 17 January 2025.¹ That application date is the one that matters. Since that day, a financial entity in scope has been expected to run its ICT risk management, incident reporting, testing and third party arrangements to the standard DORA sets, and the contractual obligations it must flow down to suppliers have been live.

The regulation is backed by a layer of technical standards drafted by the three European Supervisory Authorities, the European Banking Authority, the European Securities and Markets Authority and the European Insurance and Occupational Pensions Authority, together known as the ESAs.² These regulatory and implementing technical standards fill in the detail: the exact content of incident reports, the templates for the register of information, the methodology for threat led testing. When I need the specifics of a clause, those standards, not the regulation alone, are where the real requirement lives.

Who is in scope

DORA lists the entities it applies to in Article 2. EIOPA sums it up as twenty types of financial entity plus their ICT providers.² The list in Article 2(1) runs through credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto asset service providers and issuers of asset referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance and reinsurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers and securitisation repositories.¹

Items (a) to (t) on that list are the "financial entities".¹ Then comes item (u): ICT third party service providers.¹ That final entry is the door through which a software supplier is relevant at all. It does not make an ICT provider a financial entity, and it does not subject an ordinary supplier to the full regulation. It is the hook that lets DORA build an oversight regime for the largest, most systemically important technology suppliers, which I come to below.

DORA also builds in proportionality. Microenterprises and certain small entities run a lighter, simplified ICT risk management framework rather than the full one, and the depth of what is expected scales with the size, risk and complexity of the entity.¹ A small occupational pension scheme is not asked to do what a systemic bank does. But proportionality is about how much, not whether: an entity in scope is in scope.

The five pillars, in plain terms

DORA is usually described as five pillars, though the regulation itself does not use that word. They map onto Chapters II to VI. EIOPA lists six areas, splitting the oversight of critical providers out as its own heading.² Here are the five as a developer meets them.

ICT risk management. The entity must have a documented framework for identifying, protecting against, detecting, responding to and recovering from technology risk: governance by the management body, an up to date map of its systems and dependencies, protection and prevention measures, detection, and business continuity with backup and recovery.¹ This is the backbone, and most of what follows is a specific obligation hanging off it.

ICT incident management and reporting. The entity must detect, manage and classify technology incidents, and report the major ones to its competent authority on a tight clock. I set out the clock in its own section below.¹

Digital operational resilience testing. The entity must test its resilience regularly, from basic vulnerability assessments and penetration tests up to, for the larger entities, advanced threat led penetration testing.¹ More on who tests, and how, further down.

ICT third party risk management. The entity must manage the risk of relying on outside technology suppliers: a strategy, a register of every arrangement, due diligence before signing, and a defined set of clauses in the contract.¹ This is the pillar that reaches me.

Information sharing. Entities may, voluntarily, share cyber threat intelligence among themselves within trusted communities, to help each other spot and blunt attacks.¹ This one is permissive rather than mandatory.

The pillars are not separate projects. A single incident touches risk management (did the controls hold), reporting (the clock starts), testing (did a test miss this), and third party risk (was a supplier involved). DORA's point is that resilience is one discipline seen from several angles.

The incident clock: four hours, 72 hours, one month

Incident reporting is where DORA, like NIS2, runs a stopwatch, and the detail sits in the technical standards. Under the regulation, when a financial entity suffers a major ICT related incident it must submit an initial notification, then an intermediate report, then a final report once the root cause analysis is done.¹ The deadlines come from the regulatory technical standards, Commission Delegated Regulation (EU) 2025/301.³

The initial notification is due within four hours of the entity classifying the incident as major, and in any case no later than 24 hours after the entity became aware of it.³ The intermediate report is due within 72 hours of the initial notification, even if the situation has not changed, with updates as it does.³ The final report is due no later than one month after the intermediate report, or after the last updated intermediate report where there are several.³ There is a small concession for weekends and bank holidays, where a deadline can fall to noon of the next working day.³

Those first four hours are the part that changes how I build. You cannot classify an incident you cannot see, and you cannot report inside four hours what your logs did not capture. So the reporting clock is really a requirement on monitoring, logging and a written procedure, long before it is a requirement on anyone's inbox. Where an incident hits clients' interests, the entity must also tell the affected clients without undue delay.¹

How DORA reaches a developer like me: by contract

Now the part that lands on my desk. A financial entity stays fully responsible for its obligations even when it outsources the work, so it cannot sign them away to a supplier.¹ To keep that responsibility real, DORA makes the entity manage its ICT third party risk directly, and the mechanism is the contract.

First, the entity must keep a register of information: a maintained, updated record of every contractual arrangement for ICT services, at entity level and at group level, reported to its competent authority at least once a year and handed over on request.¹ If I build and host part of a financial entity's service, my contract is a line in that register. The entity must also tell its authority in good time about planned arrangements that would support a critical or important function.¹

Second, before signing, the entity must do its due diligence: assess whether the service supports a critical or important function, assess the risks including concentration risk (too much riding on one supplier), check my suitability, and look at whether and how I subcontract.¹ This is the same vendor vetting discipline I wrote about for GDPR vendor risk, turned up a level and made mandatory.

Third, the contract itself must carry a defined set of terms. DORA splits these into the ones every ICT contract needs (Article 30(2)) and the extra ones for contracts that support a critical or important function (Article 30(3)).¹ Every contract needs, among other things, a clear and complete description of the services, the locations where the service is delivered and data is processed with notice before those change, provisions on the availability, authenticity, integrity and confidentiality of data, the entity's right to get its data back in an accessible format if I go under or the contract ends, service level descriptions, my assistance on incidents at no extra cost or at a cost agreed in advance, cooperation with the entity's regulators, and termination rights with sensible notice.¹

Where my work supports a critical or important function, the contract must go further. It sets full, measurable service levels. It obliges me to report developments that could affect my ability to deliver, to test my own contingency plans, and to keep my security up to the entity's regulatory standard. It requires me to take part in the entity's threat led penetration testing. It grants the entity, its appointee and the competent authority unrestricted rights of access, inspection and audit, including on site. And it sets a documented exit strategy, with a transition period during which I keep the service running while the entity moves to another supplier or brings it in house.¹

Read that list as a developer and it is not exotic. It is audit trails, documented recovery, incident cooperation, data portability, access for auditors and a clean exit. It is, in other words, the engineering discipline of a serious build, written into a contract and made enforceable.

Critical ICT third party providers and the oversight regime

There is one route by which an ICT provider is reached by DORA directly rather than only by contract, and it is worth being precise about because it is often misread. The ESAs can designate a provider as a critical ICT third party service provider, a CTPP, and place it under a direct oversight regime.¹

Designation runs through the ESAs' Joint Committee and is based on criteria in Article 31: the systemic impact if the provider failed, how many financial entities rely on it and how important they are, how far entities depend on it for critical functions, and how substitutable it is.¹ Each designated provider gets a Lead Overseer, one of the three ESAs, chosen by which authority supervises the financial entities that together hold the largest share of assets among the provider's clients.¹

The Lead Overseer can request information, run investigations and inspections, require reports on remedial action, and issue recommendations.¹ If a critical provider does not comply, the Lead Overseer can impose a periodic penalty payment of up to 1% of the provider's average daily worldwide turnover in the preceding business year, charged daily until it complies, for up to six months.¹

Here is the honest reading. This regime is aimed at the handful of genuinely systemic suppliers: the large cloud platforms and the biggest shared infrastructure the whole sector leans on. A solo developer or a small studio building one firm's dashboard will not be designated a CTPP. So for almost every software supplier, DORA still arrives only through the contract, not through designation. Saying otherwise, implying that building for a bank makes me a supervised entity, would be false, and I do not say it.

Who tests, and how: resilience testing and threat led penetration testing

DORA's testing pillar has two tiers. Every entity in scope, beyond the smallest, runs a programme of basic testing: vulnerability assessments, scans, penetration tests, source code review and the like, on the systems behind its important functions.¹ This is the ordinary security testing a careful team already does, made a standing obligation.

The second tier is advanced testing based on threat led penetration testing, or TLPT. Entities that the competent authority identifies, based on their impact on the sector, financial stability concerns and their ICT risk profile, must carry out TLPT at least every three years, though the authority can vary that frequency.¹ TLPT is a controlled, intelligence led attack on the entity's live production systems, designed to mimic the tactics, techniques and procedures of real attackers and to find strengths and weaknesses rather than to produce a pass or fail.⁴

DORA requires TLPT to follow the TIBER EU framework, the European framework for threat intelligence based ethical red teaming developed by the ECB and the national central banks and updated in 2024 to align with DORA's standards.⁴ The testers must meet requirements set in Article 27, entities must use external testers at least every third test (and significant banks only external testers), and where my systems sit behind a function in scope, my contract can require me to take part in the test.¹ That is the practical link back to me: I do not commission the TLPT, the financial entity does, but I may be inside its scope and must cooperate.

DORA and NIS2: one sector carved out

If you have read my piece on the NIS2 Directive, DORA will feel like a close relative, and the two can be confused. The clean way to hold them apart is this: NIS2 is the broad baseline for cyber security across many sectors, and DORA is the specialist regime for finance that overrides it there.

DORA says so itself. For financial entities that also count as essential or important entities under NIS2, DORA "shall be considered a sector specific Union legal act" for the purposes of NIS2.¹ In plain terms, where DORA and NIS2 would both bite on a financial entity, DORA's rules take precedence as the more specific law. A bank does not run two parallel incident regimes. It runs DORA's.

For a developer the difference is in who you serve. If my client is a SaaS platform, a managed service provider or an online marketplace, NIS2 is the law in the background, and the security demands reach me through that client's supply chain duties. If my client is a bank, an insurer or a payments firm, DORA is the law in the background, and the demands reach me through the DORA contract clauses above. The engineering I do is much the same. The paperwork, the reporting clocks and the audit rights differ.

Worked example: a Leeds fintech hires me

Take an invented client: Northbank Pay, an electronic money institution based in Leeds, trading at northbankpay.example. It issues e money and runs a payments app, so it is a financial entity in scope of DORA.¹ It hires me to rebuild its customer dashboard and the service that moves balance data between the app and its ledger. That service sits behind a function Northbank treats as critical, because if it fails, customers cannot see or move their money.

I am not in scope of DORA. Northbank is. But because my work supports a critical function, Northbank must flow the full set of clauses into my contract, and here is what actually lands.

My contract joins Northbank's register of information, and Northbank tells its competent authority about the arrangement in good time.¹ Before signing, Northbank runs due diligence on me: it assesses the concentration risk of putting the dashboard and the ledger sync with one supplier, checks how I would subcontract hosting, and asks for evidence of how I build and test.¹

The contract itself sets measurable service levels for the ledger sync, not vague "best efforts". It names the regions where the service runs and where data is stored, and says I must give notice before moving them. It gives Northbank the right to recover its data in an accessible format if I stop trading. It obliges me to assist on any incident at an agreed cost, and to report to Northbank anything that could affect my ability to deliver. It grants Northbank, its auditors and the competent authority unrestricted rights to inspect and audit what I run, including on site. It requires me to keep my security to Northbank's regulatory standard and to test my own recovery. It requires me to take part in Northbank's threat led penetration test if my systems fall in scope. And it sets an exit strategy: a defined transition period in which I keep the dashboard running while Northbank moves it elsewhere or in house.¹

None of that asks me to be a bank. It asks me to build something I can stand behind under audit, operate with a recovery plan I have actually tested, and hand over cleanly if Northbank ever wants to leave. If I could not meet those clauses, I should not take the contract. Because I build to them anyway, the contract is a formality rather than a scramble.

What this looks like in a Rails build

Translate the DORA clauses into engineering and they become a familiar list, the same rigour I bring to any business critical build.

Audit trails first. Every change to balance data, every admin action, every access to customer records is logged with who, what and when, in an append only record that survives the request. That log is what makes the four hour incident clock achievable and what an auditor asks to see. I wrote separately about evidencing compliance through release registers and testing per release, and that record is exactly what a DORA audit right reaches for.

Recovery with real numbers. Business continuity under DORA is not a backup you hope works. It is a recovery you have timed. I set a recovery time objective (how long until the service is back) and a recovery point objective (how much data you could lose), then I prove them on staging by restoring from backup and writing down the minutes and the data gap. A number you have measured beats a promise you have not.

Least privilege and change management. Multi factor authentication on the admin panel, the deployment pipeline and the production console. Roles scoped so the support team cannot reach the ledger. Changes to production that go through review and leave a trail. On Ruby on Rails this is ordinary, careful engineering: encrypted data at rest, TLS everywhere, rate limiting on authentication, and dependencies kept patched.

Incident response, written down. A procedure that says who classifies an incident, who notifies the client, and what the four hour and 72 hour steps are, rehearsed so that the first time anyone follows it is not during a real breach.

How I build and contract for this

This is where the honesty guard matters most, so let me be plain about what I am and am not.

I am a developer and growth engineer. I build SaaS on Ruby on Rails and shops on Solidus, and I build them to be secure and recoverable from the start: audit trails, tested recovery, least privilege, documented incident procedures and independent penetration testing before anything faces the internet. That is the engineering DORA's contract clauses describe, and I can show it rather than assert it.

I am not a financial entity, not a bank, not a regulated institution, and building to DORA does not make me one. I am not an auditor, and I do not issue anyone a certificate. When a financial client needs to meet DORA, my role is to build and to contract so that it can: to meet the Article 30 clauses, to keep the evidence an audit right reaches for, to cooperate with a threat led test, and to hand over cleanly under an exit plan. The client's own competent authority and its own auditors do the regulating. For DORA and its near relatives like SOC 2, which I cover in SOC 2 Type II explained, the standard rests on the discipline I build to, never on a stamp I claim to hold.

That honesty is the selling point. Plenty of suppliers will tell a bank what it wants to hear and discover the audit rights and the exit clause only when the contract is in front of them. I would rather tell you up front that these clauses are real, that meeting them adds cost to the build, and that it is worth it because it is what keeps a financial client's regulator, and its customers, trusting the service I built.

What to do now

If you are a financial entity, or you supply one, work through these in order.

Place yourself. Are you a financial entity in Article 2, or a supplier reached by contract? If you supply one, you are almost certainly reached through the contract, not by CTPP designation.
If you are an entity, map your ICT providers into a register of information and run due diligence before you sign, with concentration risk and subcontracting assessed.
Get the contract clauses right, splitting the baseline terms from the extra ones for critical or important functions, and do not forget the exit strategy.
Build the monitoring and logging that make a four hour classification and report possible, because the clock is a requirement on your systems before it is one on your staff.
Set and test a recovery time objective and a recovery point objective. Measure them on staging, do not assume them.
If you are a supplier, build to the clauses whether or not a given client asks, so the contract is a formality. Treat audit rights, incident cooperation and a clean exit as normal.
Keep the line clear. Building for a regulated client does not make you regulated. Say what you are, and do not imply what you are not.

DORA is strict, and for a reason: when the technology behind payments and insurance fails, people lose access to their own money. The suppliers who treat it as a reason to build properly, rather than as clauses to survive, end up with systems that recover faster, audits that go quietly, and financial clients who trust them with more.