DORA is live. What your technology function needs to do now.

If your business is a financial entity operating in the EU, the Digital Operational Resilience Act — DORA — is not a future deadline to plan for. It has applied since 17 January 2025, with no transition period. That date has passed. National regulators, including CySEC here in Cyprus, are supervising against it now. If your technology function has not fully responded, you are already behind, and the work is overdue rather than upcoming.

DORA is a regulation, not a directive, which means it applies directly and consistently across the EU. It covers around twenty types of financial entity — banks, insurers, investment firms, payment institutions, fund managers and more — as well as the technology providers that serve them. If you are a CySEC-regulated firm, the odds are high that you are in scope.

What DORA is actually about

The purpose is straightforward to state. Financial services now run on technology, so a serious technology failure is a serious business and systemic risk. DORA exists to ensure that financial entities can withstand, respond to and recover from technology disruptions — whether a cyberattack, an outage, or a failure at a third-party provider. It turns operational resilience from good practice into a legal obligation, with a single framework across the EU rather than a patchwork of national rules.

Crucially, DORA is a governance regulation as much as a technical one. It is concerned with how you manage technology risk, what you can evidence, and who is accountable — not just with what tools you have installed.

What your technology function has to deliver

DORA’s requirements gather into four areas, and each places a concrete demand on the technology function.

The first is ICT risk management. You need an internal framework for identifying, managing and controlling technology risk, owned at the right level and not buried in the IT team. This is the backbone, and everything else hangs off it.

The second is incident management and reporting. You must be able to detect, classify and report major technology-related incidents to your regulator within defined timeframes. That requires a process that works under pressure, not a document that exists in theory.

The third is resilience testing. You need to test your ability to withstand and recover from disruption, on a regular and structured basis, and act on what the testing reveals.

The fourth, and the one most often underestimated, is third-party risk. Financial entities depend heavily on outside technology providers, and DORA holds you responsible for that dependency. You must maintain a register of your technology third-party arrangements, manage the risk they represent, and ensure your contracts meet DORA’s requirements. The register of information, in particular, has caught many firms out, because it demands a level of detail about who you depend on that most businesses never had to assemble before.

Where firms are behind

Because some of the detailed technical standards underneath DORA were still being finalised around the application date, a lot of firms treated that as permission to wait. That was a misreading. The core obligations applied from day one, and the absence of every last piece of guidance is not a defence for having no framework, no incident process and no third-party register.

There is also a quieter gap. DORA expects resilience, and resilience is impossible to claim honestly while critical systems run on unsupported, unpatchable software. A frozen technology stack — the kind described in the compound problem, or an estate still running end-of-life Windows — is the opposite of operational resilience, and it is exactly the sort of thing a regulator’s review will surface.

Where to start if you have fallen behind

The starting point is a gap assessment against the four areas: what does DORA require, what do you actually have, and where are the holes. From there it becomes a prioritised plan — build the risk-management framework, stand up a real incident process, assemble the third-party register, and put the testing regime in place. Much of this overlaps with controls you may already be evidencing elsewhere, including for cyber insurance, so the work is rarely starting from zero.

DORA sits across technology, risk, legal and procurement, so it should not be left as an IT project. It needs someone who can translate between the regulation and the technology function and hold the two together. This article describes the requirements; the specifics of your obligations should be worked through with your compliance and legal advisers as well.

If you are an EU financial entity and you have not fully responded to DORA, this is overdue rather than optional. We will assess where you stand against the four areas and what to address first.

Start a Conversation

Further reading

• DORA Article 6 ICT Risk Management Framework: A Practical Reading
• DORA Threat-Led Penetration Testing (TLPT): What Firms Must Actually Commission
• DORA Critical Third Party Designation: A Reading for Both Sides
• DORA for Maltese Financial Institutions: Six Questions Your Board Should Be Asking
• DORA for Irish Financial Services: A Practical Reading for Boards