DORA for e-money and payment institutions: ICT risk under control

Article 2(1) lists the financial entities DORA covers; for the payments market the relevant points are (b) payment institutions, (c) account information service providers, (d) e-money institutions and (f) crypto-asset service providers. An exemption under PSD2 or the E-Money Directive leaves an institution inside DORA.

The simplified framework for small institutions

Article 16 lifts Articles 5 to 15 from exempted payment and e-money institutions and several other small entities. In exchange they keep a documented ICT risk management framework, monitor their systems continuously, identify key dependencies on ICT providers, keep continuity plans with backup and restoration, and test them regularly. Commission Delegated Regulation (EU) 2024/1774 sets out the detail of the simplified framework.

Article 6 requires a sound, comprehensive and well-documented ICT risk management framework within the overall risk management system (Art. 6(1)). It is reviewed at least once a year, or periodically for microenterprises, and after major ICT incidents or supervisory instructions; the review report goes to the authority on request (Art. 6(5)). Entities other than microenterprises also need an independent ICT risk control function (Art. 6(4)) and regular internal audit (Art. 6(6)).

The management body's responsibility

Under Article 5(2) the management body defines, approves and oversees every arrangement of the framework and bears ultimate responsibility for ICT risk. In practice the board approves the policies, and its members need to understand what they approved.

Backup and restoration

Article 12 requires documented backup policies that set the scope and minimum frequency of backups by data criticality, plus restoration and recovery procedures. We test them by restoring.

Article 19(4) of DORA sets the sequence, and Commission Delegated Regulation (EU) 2025/301 sets the clocks:

• initial notification within 4 hours of classification, no later than 24 hours from awareness;
• intermediate report within 72 hours of the initial notification, even if the incident's status has not changed;
• final report no later than one month after the latest intermediate report.

Where a major incident affects clients' financial interests, the entity informs them without undue delay about the incident and the measures taken (Art. 19(3)). We prepare the classification procedure, roles and templates, and run a tabletop exercise so the team meets these clocks before a real incident starts them.

The register is kept at entity and group level (Art. 28(3)). Before a contract the entity assesses whether the service supports a critical or important function, identifies risks including concentration risk, and vets the provider (Art. 28(4)). Article 30(2) lists the mandatory contract terms: description of services and subcontracting, data locations, data protection, service levels, assistance during an ICT incident.

A typical EMI's register holds the cloud platform, payment processing, the KYC provider, email, CRM and accounting. We build it and list the contracts to amend.

Article 5(1)(j) of PSD2 requires a security policy document: a detailed risk assessment of the payment services and a description of the security control and mitigation measures. Article 62(2)(j) of MiCA requires technical documentation of ICT systems and security arrangements and a description in non-technical language. We write this section so it matches your DORA framework. The licence as a whole sits with our licensing practice; see also the guide on DORA ICT requirements for an EMI licence.