DORA for financial institutions and their IT providers: what will be required of you

The five DORA pillars in plain language: what the regulation means for a financial institution and what it demands from its IT providers, from contracts and registers to exit plans and recovery.

DORA for financial institutions and their IT providers: what will be required of you

If you are a credit union, a payment institution, an insurance broker or an investment fund manager, DORA already applies to you. If you are an IT company that maintains servers, provides cloud services or builds software for such clients, DORA reaches you through customer contracts, most often as a surprise, with a request to sign a new addendum within two weeks.

DORA is EU Regulation 2022/2554 on digital operational resilience in the financial sector, applicable since January 17, 2025. Unlike a directive, a regulation applies directly, without being transposed into national law, so the financial regulator supervises it exactly as written.

In this article we explain the five pillars of the regulation in plain language, show what they mean in practice for an IT provider, and share how we handle them for our own customers.

The five pillars of DORA

The regulation is built on five areas. Each has a documentation side and a technical side.

ICT risk management

A financial institution must have an information and communication technology (ICT) risk management framework approved by senior management: an asset register, a risk assessment, protection measures, detection capabilities, and response and recovery plans. The management body is accountable for all of it, not the IT department. In practice, this means leadership must understand which systems are critical, what happens when they stop, and how long the institution can operate without them.

Incident management and reporting

All ICT-related incidents are logged and classified by impact, and major ones are reported to the supervisory authority within strict deadlines: an initial notification within a few hours, then an intermediate and a final report later. The institution must be able to quickly assess how many customers were affected, how long the service was down and whether data leaked. Without logs and monitoring, that is impossible.

Digital operational resilience testing

Having protection is not enough; it has to be tested regularly. The baseline level covers vulnerability scanning, configuration reviews, backup restore tests and scenario exercises. Larger and systemically important institutions are also required to run threat-led penetration testing, where specialists simulate a real attack. Test results are documented, and weaknesses are fixed according to a plan.

Third-party ICT risk management

This is the pillar that affects IT providers most. An institution must keep a register of all its ICT service providers, assess the risk of each one, include mandatory terms in contracts and have an exit strategy in case a provider stops delivering the service. Services that support critical functions, such as hosting an accounting system or storing backups, get especially close scrutiny.

Information sharing

Institutions are encouraged to share information about threats and vulnerabilities with each other and with authorities. For a small institution this usually means taking part in sector groups and following alerts from the national cybersecurity authority.

What this means for an IT provider

If you provide IT services to a financial institution, the client cannot work with you unless you support its DORA obligations. In our experience, on the provider side this comes down to three concrete things.

Contracts

The contract with a financial institution must contain clear provisions: precisely described services and service levels, the data storage location (inside the EU or not), incident notification deadlines to the client, the right of the client and the supervisory authority to audit, rules on the use of subcontractors, and termination conditions with a transition period. If your standard contract does not have these, the client will send its own addendum. It is better to have your own, prepared in advance.

The register

The client fills in a register of providers in a prescribed format and will need information about you: legal entity details, type of service, criticality, data location and subcontractors. A provider should keep a ready set of answers, because questionnaires from different clients overlap heavily.

Exit plans

Every institution must be able to move from one provider to another without disrupting operations. Your duty is to describe how you will return the data, in what format, within what time, and what you will delete after the handover. A provider that cannot clearly say how the client gets its data back on exit is a risk and will be replaced.

One more thing providers often overlook is subcontractors. If you provide backup storage to your client and the copies physically sit with a third party, the client must know about it and have the right to object. The chain of subcontractors has to be described in the contract and updated when it changes.

Below is how the same requirements look from both sides.

RequirementFinancial institutionIT provider
Risk managementRisk register, management decisionsEvidence of its own security policies and controls
IncidentsNotification to the authority within the deadlinesNotification to the client within the agreed time, logs
TestingTest plan and resultsTaking part in restore tests, fixing vulnerabilities
Third partiesProvider register, exit strategyContract addendum, subcontractor list, exit plan
Information sharingThreat monitoring, participation in groupsAlerts to the client about relevant threats

Backup and recovery: where it most often goes wrong

DORA requires not only having backups but also proving that operations can be restored from them within a defined time. The institution must set recovery time and recovery point objectives (RTO and RPO) for every critical system, and backups must be physically and logically separated from the main environment.

The most common mistake is keeping backups on the same network, or with the same provider in the same data centre. Ransomware that encrypts the servers encrypts them too. The second mistake is a restore that has never been tested, so during an incident it turns out that the backup is incomplete or that recovery takes days instead of hours.

For our customers we offer immutable backups, which cannot be altered and are invisible from the network, and for critical systems PlanB infrastructure recovery, where the whole environment can be brought up in our cloud if the primary one becomes unavailable. On request, backups are also stored in an Amazon data centre in Germany, so that geographic separation is real, not just declared.

How MDP CLOUD helps

We work from both sides: we are an IT provider to financial institutions and we help other IT providers prepare for their clients’ requirements. Our team holds current ISACA certifications (CISA, CISM, CRISC and others), and we deliver our services in line with ISO 27001 requirements, so we already have answers ready for customer questionnaires.

For a financial institution, we help build the ICT asset and provider registers, carry out a risk assessment, prepare an incident management procedure with notification templates, and plan and run resilience tests. For an IT provider, we help prepare the contract addendum, a set of security policies, an exit plan template and the technical evidence a client will ask for.

Where to start

  1. Determine whether DORA applies to you directly (you are a financial institution) or through clients (you are a provider). The order of work depends on it.
  2. List your critical functions and the systems and providers that support them. This is the basis for the register and the risk assessment.
  3. Review contracts with providers or clients and mark which terms are missing.
  4. Check your backups: where they are, whether they are separated from the main network, and when they were last actually restored.
  5. Prepare an incident notification procedure with contacts and deadlines, so nobody has to look for whom to call during an incident.

We described the full path from the first step to readiness for the supervisory authority on the DORA service page. If you would rather start with a conversation, get in touch, and at the first meeting we will tell you which requirements matter to you and which you can stop worrying about.