The Digital Operational Resilience Act, better known as DORA, has now been in force across the European Union for more than a year. Adopted as Regulation (EU) 2022/2554, it started to apply on 17 January 2025, and it changes how financial firms are expected to manage the technology they depend on. For a jurisdiction like Malta, with a sizeable financial services sector and a busy local information technology industry that supports it, DORA is not an abstract Brussels exercise. It reaches into contracts, incident procedures, and supplier relationships that many organisations here already have in place.
We have been following how local firms are adjusting, and the picture will be familiar to anyone who watched the run up to the General Data Protection Regulation (GDPR). Larger, well resourced entities have compliance programmes underway. Smaller firms, and particularly the technology suppliers that serve them, are still working out how much of this applies to them. This article sets out the essentials.
What DORA is trying to fix
Before DORA, the rules on operational resilience for financial entities were scattered across different pieces of European and national law, and technology risk was often treated as a secondary concern. DORA pulls these threads together into a single regulation that applies directly, without needing national transposition. The aim is straightforward: financial firms should be able to withstand, respond to, and recover from disruptions to their information and communication technology (ICT), whether those come from a failed system, a third-party outage, or a deliberate attack.
The regulation is usually described as resting on five pillars:
- ICT risk management. A documented framework, owned at board level, covering the identification, protection, detection, response, and recovery of ICT systems.
- ICT-related incident reporting. A consistent way to classify and report major incidents to the relevant authority, within defined timelines.
- Digital operational resilience testing. Regular testing of systems, ranging from vulnerability assessments to advanced threat led penetration testing for the largest entities.
- ICT third-party risk management. Rules for how firms contract with, monitor, and exit from technology suppliers.
- Information sharing. Voluntary arrangements to exchange threat intelligence within the sector.
Who is in scope in Malta
DORA applies to a broad list of financial entities. In the Maltese context, that includes credit institutions, insurance and reinsurance undertakings, investment firms, payment and electronic money institutions, and crypto-asset service providers authorised under the Markets in Crypto-Assets Regulation (MiCA). For most of these, the Malta Financial Services Authority (MFSA) is the competent authority responsible for supervision.
It is worth noting that DORA is deliberately proportionate. Microenterprises and certain smaller entities may apply a simplified ICT risk management framework rather than the full set of requirements. Proportionality does not mean exemption, though. A small payment institution still needs to manage supplier risk and report major incidents; it simply has more room to scale its controls to its size and risk profile.
The third-party angle that pulls in local suppliers
This is the part that catches many Maltese technology companies by surprise. DORA does not only regulate financial firms. Through its rules on ICT third-party risk, it reaches the suppliers those firms rely on, including cloud providers, software vendors, managed service providers, and specialist consultancies.
Financial entities are required to keep a register of information listing every contractual arrangement they have for the use of ICT services. The European Supervisory Authorities collected these registers for the first time in 2025, and the exercise gave regulators an unprecedented map of who supplies critical services to the sector. If your firm provides ICT services to a bank, an insurer, or a payment institution here, you have very likely been asked to appear in one of these registers, and to accept contract terms you may not have seen before.
Those terms flow directly from the regulation. Contracts for ICT services now need to cover matters such as service levels, access and audit rights, incident cooperation, subcontracting conditions, and clear exit strategies so that a financial firm can move away from a supplier without disruption. For services that support critical or important functions, the requirements are stricter still. The regulation also created an EU-level oversight framework under which the European Supervisory Authorities can designate the largest and most systemically important providers as critical ICT third-party providers, placing them under direct European oversight. The first designations under that framework have been taking place, and the European Banking Authority (EBA) maintains public guidance on how the oversight regime works.
Testing and incident reporting in practice
For everyday operations, two pillars tend to demand the most attention. The first is incident reporting. Firms need a repeatable process to classify an ICT-related incident, decide whether it is major, and report it within the timelines set out in the technical standards. The classification criteria consider factors such as the number of clients affected, data losses, duration, geographical spread, and economic impact.
The second is testing. Every entity must run a programme of resilience testing appropriate to its size, which for most firms means regular vulnerability scanning, configuration reviews, and penetration testing. Significant entities face an additional obligation: threat led penetration testing, carried out at least every three years and modelled on the European TIBER-EU framework. This is a realistic, intelligence-driven exercise against live production systems, and it is a considerable step up from a routine assessment.
DORA, NIS2, and how they fit together
Malta has spent the past couple of years absorbing the second Network and Information Security Directive (NIS2) as well, and the two regimes can look as though they overlap. The relationship is defined in the legislation: for financial entities, DORA acts as the more specific law. Where DORA sets ICT risk management and incident reporting requirements, those take precedence over the equivalent general obligations in NIS2. A financial firm should therefore treat DORA as its primary reference for technology resilience, while remaining aware of the wider NIS2 picture. We covered the NIS2 side of this in our earlier piece on what local SMBs are expected to do under NIS2.
Practical starting points
If your organisation is still mapping its position, a few steps are worth taking early:
- Confirm whether you are a financial entity in scope, an ICT supplier to one, or both, since the obligations differ.
- Build or refresh your register of ICT contracts, and check whether existing agreements contain the clauses DORA now expects.
- Review your incident classification and reporting process against the technical standards, and rehearse it before you need it.
- Match your testing programme to your size and risk, and plan ahead if threat led penetration testing may apply.
- Read the guidance published by the European Supervisory Authorities, which set out the detailed technical standards.
The regulation is detailed, and the technical standards behind it run to hundreds of pages, but the underlying message is one our community has repeated for years: know what you depend on, plan for it to fail, and be honest about your suppliers. For authoritative detail, the DORA overview maintained by EIOPA is a sensible place to begin, alongside the European Commission’s material on how the wider NIS2 framework operates for organisations that fall outside the financial sector.
We will keep tracking how supervision develops locally, and we would be glad to hear from readers in Maltese financial and technology firms about how the first eighteen months have gone in practice.