DORA for MFSA-licensed firms: what to have ready

The short answer: if your firm is licensed by the Malta Financial Services Authority and is one of the financial entities listed in Article 2 of Regulation (EU) 2022/2554 (DORA), the regulation has applied to you since 17 January 2025. The MFSA expects four things in place: an ICT risk management framework owned by the board, major incident reporting through its Cyber Reporting Management System, a testing programme, and a register of information on ICT providers submitted every year between 1 January and 21 March.

DORA is a regulation, so it applies directly in Malta. The national pieces came with Legal Notice 166 of 2024, the DORA Regulations, 2024, made under the MFSA Act, which the MFSA's circular of 11 November 2024 describes as implementing DORA in the national legal framework. Below, each block with the article that requires it and what the MFSA has published.

Who is in scope in Malta

Article 2(1) of DORA lists the financial entities in points (a) to (t): among them credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, fund managers, insurers and insurance intermediaries. Three limits are worth checking first:

• Exclusions. Article 2(3) leaves out, among others, insurance intermediaries that are micro, small or medium-sized enterprises and occupational pension institutions whose schemes together have no more than 15 members.
• Simplified framework. Under Article 16(1), Articles 5 to 15 do not apply to, among others, small and non-interconnected investment firms, exempted payment institutions, exempted electronic money institutions and small occupational pension institutions. They follow a lighter, documented ICT risk framework instead.
• Proportionality. Article 4 asks every entity to apply the ICT risk rules in line with its size, overall risk profile and the nature, scale and complexity of its services. It sizes the work, it does not remove it.

Credit institutions classified as significant are supervised by the ECB for DORA purposes (Article 46(a)), and the MFSA tells them to follow ECB guidance on the register of information. For groups, the register is kept at entity level and at sub-consolidated and consolidated level (Article 28(3)).

1. ICT risk management (Articles 5 to 16)

This is the base everything else rests on. DORA puts it on the board first: under Article 5(2) the management body defines, approves, oversees and is responsible for the ICT risk management framework, and point (a) says it shall "bear the ultimate responsibility for managing the financial entity’s ICT risk". The same article asks the board to approve the digital operational resilience strategy and the ICT risk tolerance (point (d)), to allocate the budget (point (g)) and, in paragraph 4, to keep its own knowledge up to date through regular training.

Below the board, the regulation asks for evidence that a supervisor can read:

• a framework that is documented and reviewed at least once a year, and again after major ICT-related incidents (Article 6(5)), with a control function that has an appropriate level of independence (Article 6(4)) and regular internal audit (Article 6(6));
• inventories of information assets, ICT assets and ICT-supported business functions, with the critical ones mapped and the classification reviewed at least yearly (Article 8);
• mechanisms to promptly detect anomalous activities, and enough resources to monitor user activity, ICT anomalies and incidents, in particular cyber-attacks (Article 10);
• an ICT business continuity policy with response and recovery plans tested at least yearly (Article 11(6)), and, when backups are restored on the firm's own systems, systems physically and logically segregated from the source (Article 12(3));
• a yearly report from senior ICT staff to the management body (Article 13(5)) and compulsory security awareness training for all staff (Article 13(6)).

The detail sits in Commission Delegated Regulation (EU) 2024/1774, which also covers the simplified framework of Article 16.

2. Incident classification and reporting (Articles 17 to 23)

Article 17 asks for an incident management process that detects, manages and notifies ICT-related incidents, records all of them along with significant cyber threats, and informs the management body of at least the major ones. Article 19 then requires major incidents to be reported to the competent authority.

When an incident is major

Commission Delegated Regulation (EU) 2024/1772 sets the test in Article 8. An incident is major when it has affected critical services and either there has been a successful, malicious and unauthorised access to network and information systems that may result in data losses, or two or more of the other materiality thresholds are met. Those thresholds include, for example, an incident lasting longer than 24 hours, service downtime longer than 2 hours for ICT services supporting critical or important functions, impact in two or more Member States, and costs and losses exceeding or likely to exceed 100,000 euro. Recurring incidents with the same apparent root cause, occurring at least twice within six months, count as one major incident if together they meet the criteria; the check runs monthly.

The time limits

Commission Delegated Regulation (EU) 2025/301, Article 5(1), sets three steps:

1. Initial notification: as early as possible, and in any case within four hours from classifying the incident as major and no later than 24 hours from becoming aware of it.
2. Intermediate report: at the latest within 72 hours from the initial notification, even if nothing has changed, with an update when regular activities have been recovered.
3. Final report: no later than one month after the latest intermediate report.

If a time limit falls on a weekend or bank holiday, Article 5(4) allows submission by noon of the next working day, but not for the initial notification or intermediate report of credit institutions, central counterparties, trading venue operators and entities identified as essential or important under NIS2 (Article 5(5)). The forms come from Commission Implementing Regulation (EU) 2025/302. Clients whose financial interests are affected are informed without undue delay (DORA Article 19(3)), and reporting can be outsourced, but the entity remains fully responsible (Article 19(5)).

What the MFSA has set up

The MFSA circular of 17 January 2025 on the Cyber Reporting Management System (CRMS) says that in-scope authorised persons report major ICT-related incidents, notify significant cyber threats on a voluntary basis, and notify participation in information-sharing arrangements through the CRMS in the License Holder (LH) Portal, using the MFSA templates. The MFSA applies the same incident process to authorised persons outside DORA's scope on an expectation basis. The mailbox for this stream is mirt@mfsa.mt.

The practical point: the 24-hour clock starts when the firm becomes aware of the incident, not when compliance hears about it. If nobody watches alerts at night or over a weekend, the four-hour window after classification is hard to meet.

3. Digital operational resilience testing (Articles 24 to 27)

Financial entities other than microenterprises keep a risk-based testing programme as part of the ICT risk framework (Article 24). Tests are run by independent parties, internal or external, and at least yearly every ICT system and application supporting critical or important functions goes through appropriate tests (Article 24(6)). Article 25 lists the kind of tests, from vulnerability scans and scenario-based tests to penetration testing.

Advanced testing is narrower. Under Article 26, entities identified by the competent authority carry out threat-led penetration testing (TLPT) at least every three years, on live production systems supporting critical or important functions. The details are in Commission Delegated Regulation (EU) 2025/1190.

In Malta, the MFSA circular of 7 July 2025 states that the MFSA is designated as the TLPT Authority and that TLPT follows the TIBER-EU framework. It published the TIBER-MT and DORA TLPT-MT National Implementation Document: entities licensed by the MFSA and identified for TLPT undergo a TIBER-MT test, which leads to attestation provided the DORA and RTS requirements are met. TLPT correspondence goes to tlpt@mfsa.mt.

4. ICT third-party risk and the register of information (Articles 28 to 30)

Outsourcing ICT does not outsource the obligations: under Article 28(1)(a) the entity remains fully responsible. Entities outside the simplified regime and other than microenterprises adopt a strategy on ICT third-party risk, with a policy on ICT services supporting critical or important functions (Article 28(2)). Before signing, the entity assesses risks, concentration and the provider's suitability (Article 28(4) and Article 29), and for critical or important functions it keeps tested exit strategies (Article 28(8)). Article 30 lists the minimum clauses; for critical or important functions they include service levels with quantitative targets, participation in the entity's TLPT, unrestricted access and audit rights, and a transition period on exit.

The register, and how the MFSA collects it

Article 28(3) requires a register of information on all contractual arrangements for ICT services provided by third parties, distinguishing those that support critical or important functions. The templates are set by Commission Implementing Regulation (EU) 2024/2956.

The MFSA circular of 3 November 2025 fixes the collection from 2026 onwards:

• the full register, at entity or consolidated level, is submitted once a year through the LH Portal;
• the reporting period runs from 1 January to 21 March (or the next working day) of each reporting year;
• the reference date is 31 December of the previous year;
• a submission counts as DORA compliant only when its status on the LH Portal is Accepted; if it is rejected, the firm fixes the issues and resubmits;
• the file is a DORA-compliant plain-csv aligned with the ESAs' latest reporting technical package, and building and converting it is the firm's job: the MFSA states it is not an XBRL provider.

The first collection ran from 1 to 8 April 2025, and the MFSA reminded firms of the 2026 window in a circular of 28 January 2026. On the rule set in November 2025, the next window opens in January 2027 with 31 December 2026 as reference date. The circulars state that failing to submit an accepted register within the period may lead to regulatory action under L.N. 166 of 2024 and the MFSA Act. Questions go to roi@mfsa.mt.

What happens if something is missing

DORA does not fix amounts. Article 50 asks Member States to give competent authorities sanctioning powers, including orders to cease conduct, measures of a pecuniary nature and public notices, and Article 50(5) lets those measures reach members of the management body under the conditions of national law. In Malta, the MFSA's circulars point to L.N. 166 of 2024 and the MFSA Act as the basis for regulatory action.

A short checklist for the next board meeting

1. Is there a board resolution approving the ICT risk framework, the resilience strategy and the ICT risk tolerance, reviewed in the last twelve months?
2. Who is the independent control function for ICT risk, and who monitors ICT providers under Article 5(3)?
3. Can the firm classify an incident against the 2024/1772 thresholds and file an initial notification in CRMS within the time limits, including at night and over a weekend? Who has LH Portal access?
4. Did every system supporting a critical or important function get an appropriate test this year, and were the findings closed?
5. Was the 2026 register accepted on the LH Portal, and who owns the 2027 submission?
6. Do contracts for critical or important functions contain the Article 30(3) clauses, and is there a tested exit plan?

How AmagisTech can help

We work with financial entities on the four blocks above: gap analysis, ICT risk framework, incident procedures aligned with the 2025/301 time limits, the register of information, and a 24/7 SOC for detection and response. The scope is on our DORA services page, the SOC side under managed SOC and MDR; if you already run an ISO 27001 system, part of the documentation exists.

If you want an honest reading of where your firm stands against DORA and the MFSA's requirements, book a 30-minute call.