DORA for Payment Institutions and EMIs in 2026
What the Digital Operational Resilience Act asks of payment and e-money institutions in 2026: scope and the simplified regime for small firms, ICT risk, incident reporting, testing, the register of information, ICT contracts and what to ask your core banking vendor.
DORA in one paragraph
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It is a regulation, so it applies directly in every Member State without national transposition. For a payment or e-money institution it covers five areas: ICT risk management, ICT incident reporting, resilience testing, management of ICT third-party risk, and information sharing on cyber threats.
Detailed rules sit in technical standards adopted by the Commission on proposals from the three European Supervisory Authorities (EBA, ESMA and EIOPA). The ones a PI or EMI meets most often are the RTS on the ICT risk management framework (Delegated Regulation (EU) 2024/1774), the RTS on the contractual policy for ICT services (2024/1773), the ITS on the register of information (Implementing Regulation (EU) 2024/2956) and the RTS on incident reporting (Delegated Regulation (EU) 2025/301).
DORA is EU law. A UK firm authorised by the FCA is outside it and follows the FCA's own operational resilience rules instead, although a UK group with an EU subsidiary has to apply DORA in that subsidiary.
Building a business on this licence?
See what the platform covers for it: the regulator's IT questions, rails, providers and the technical part of your application.
- Core banking for Lithuanian EMIs
- Digital banking for Luxembourg EMIs
- Digital banking for Portuguese EMIs
Who is in scope, and who gets the lighter regime
Article 2(1) lists payment institutions and electronic money institutions including those exempted under PSD2 and the E-Money Directive. Account information service providers are listed separately. In other words, being small does not take you out of DORA. What size changes is how much of it applies.
| Type of firm | ICT risk framework | Testing | Third-party risk |
|---|---|---|---|
| Authorised PI or EMI | Full framework under Articles 5 to 15. | A testing programme, with yearly tests of systems that support critical or important functions. | Third-party risk strategy, register of information, Article 30 contracts, exit plans. |
| Exempted (small) PI under PSD2 Art. 32 or small EMI under EMD Art. 9 | Simplified framework under Article 16, detailed in Title III of RTS 2024/1774. | Regular testing of continuity plans and controls under Article 16. | No formal third-party risk strategy, but the register of information and contract rules still apply. |
| Microenterprise (fewer than 10 staff and turnover or balance sheet up to EUR 2 million) | Full framework, applied proportionately, with several specific lighter rules. | Risk-based testing plan, no independent tester requirement. | Same core duties. Audit rights can be delegated to a third party appointed by the provider. |
One point is often misread. The simplified regime of Article 16 is for exempted institutions, the small PIs and small EMIs registered under the national waivers. A fully authorised EMI with five employees is a microenterprise, not an Article 16 entity, and keeps the full framework with proportionality.
ICT risk management: what the framework has to contain
The management body is responsible for ICT risk and approves the framework. In practice the regulator will look for these documents and the evidence that they are used:
- ICT risk management framework and digital operational resilience strategy, reviewed at least yearly and after major incidents.
- Asset inventory. Systems, data, network resources and the business functions they support, with critical or important functions marked.
- Security policies. Access control, encryption and key management, change management, patching, logging, network security.
- Detection and response. How anomalies are found, who is called, how an incident is classified.
- Business continuity and ICT recovery plans, with backups, restoration and recovery time objectives, tested on a schedule.
- Training. Security awareness for staff and digital resilience training for management.
If you run on a vendor's platform, much of the evidence for asset inventory, security controls and recovery comes from that vendor. The responsibility does not move with it: Article 28(1) keeps the financial entity fully responsible for compliance at all times.
Major incident reporting: the clock
An ICT-related incident becomes reportable when it meets the major incident criteria in the classification RTS: clients affected, duration, data losses, critical services hit, economic impact and geographical spread. For payment firms this replaced the PSD2 major incident reporting regime: the EBA repealed its PSD2 incident guidelines on 17 January 2025.
| Report | Deadline under Delegated Regulation (EU) 2025/301 |
|---|---|
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after you became aware of it. |
| Intermediate report | Within 72 hours of the initial notification, even if nothing has changed, and again whenever the status changes significantly. |
| Final report | No later than one month after the latest intermediate report, once the root cause analysis is done. |
Two more duties sit in Article 19. If a major incident affects clients' financial interests, you must tell them without undue delay, together with what you are doing about it. And you may outsource the reporting to a provider, but you stay fully responsible for it. For a firm on a vendor platform, this means your contract must oblige the vendor to tell you about incidents fast enough for you to meet the 4 and 24 hour limits.
Resilience testing
Every PI and EMI other than a microenterprise needs a digital operational resilience testing programme (Article 24). Article 25 lists the tools: vulnerability scans, network security assessments, source code reviews where feasible, scenario-based tests, performance and end-to-end tests, and penetration tests. Systems supporting critical or important functions must be tested at least once a year, by testers who are independent of the people who built them.
Threat-led penetration testing (TLPT) under Article 26 is a different matter. It is required only from firms that competent authorities identify, roughly every three years, and Article 16 entities and microenterprises are excluded. Most payment and e-money institutions will not be selected. If you are, the test must cover live production systems, including those run by your ICT providers, which is why Article 30 contracts include a duty to take part.
The register of information
Article 28(3) requires every financial entity, the small ones included, to keep a register of information on all contractual arrangements for ICT services, marking those that support critical or important functions. The format is fixed by Implementing Regulation (EU) 2024/2956: a set of linked tables covering the entity, each contract, each provider and its subcontractors, the functions supported and the assessment of each service.
Reference date
From 2026 the register reflects contracts in place on 31 December of the previous year.
Your deadline
Set by your national authority, earlier than the ESA deadline. Luxembourg's CSSF, for example, collected the 2026 registers between 11 February and 31 March.
ESA deadline
National authorities pass the registers to the ESAs by 31 March each year.
The register is not only an annual file. Your authority can ask for it at any time, and you must tell it in good time about any planned contract for ICT services supporting a critical or important function. The ESAs also used the registers to pick the providers they now oversee directly. Sources: ESAs on the register timeline, CSSF 2026 submission window.
Contracts with ICT providers and exit strategies
Article 30(2) sets the minimum for every ICT contract: a full description of services and whether subcontracting is allowed, the locations where services run and data is stored, data protection, access to and return of data on insolvency or termination, service levels, help during ICT incidents at no extra cost or at a price agreed in advance, cooperation with your authorities, termination rights and participation in your security training.
For services supporting critical or important functions, Article 30(3) adds precise service levels with quantitative targets, notice and reporting duties, the provider's own continuity plans and security measures, participation in TLPT, unrestricted access, inspection and audit rights for you and your regulator, and an exit strategy with a mandatory transition period.
The exit strategy itself is your document, not the vendor's. Article 28(8) asks you to be able to leave a provider without disrupting the business, breaking compliance or hurting customers, to have a documented and tested exit plan, and to know how the data and services would move to another provider or in-house. For a core banking platform this means agreed export formats for client records, balances and transaction history, and a transition period long enough to run a migration.
Critical ICT third-party providers
On 18 November 2025 the ESAs published the first list of critical ICT third-party providers (CTPPs) under Article 31. According to Morgan Lewis, it named 19 providers, mostly large cloud, data centre, network and enterprise software firms. Each now has a Lead Overseer among the ESAs with direct powers to inspect it.
This oversight does not replace your own work. If your platform runs on a hyperscaler that is a CTPP, you still assess the risk, keep the contract terms and list the cloud provider as a subcontractor in your register. Most core banking vendors are not designated, and the duties under Articles 28 to 30 apply to them in full through your contract.
What to ask your core banking vendor
A core banking platform supports almost every critical function of a PI or EMI: accounts, payments, customer data. Before you sign, or before your next register cycle, get clear answers to these questions.
| Question | Why it matters under DORA |
|---|---|
| Where is the platform hosted and where is data stored, and who are the subcontractors? | Locations and subcontracting must be in the contract (Art. 30(2)) and in your register. |
| How fast will you tell us about an incident, and through which channel? | You have 4 hours from classification and 24 hours from awareness to file the initial notification. |
| What are the service levels, with numbers? | Article 30(3) asks for quantitative targets you can monitor. |
| Can we, our auditor and our regulator audit you? | Unrestricted access, inspection and audit rights are mandatory for critical services. |
| What recovery objectives do you test, and can we see the results? | Your continuity plans depend on the vendor's backups and restoration. |
| In what format do we get our data back, and how long is the transition period? | Exit strategies and data return are required by Articles 28(8) and 30. |
| Will you take part in our resilience tests? | Testing, and TLPT if you are selected, covers outsourced systems too. |
How DORA ties into your licence application
DORA came with an amending directive, Directive (EU) 2022/2556, which rewrote parts of PSD2 Article 5(1) on what an application must contain. The governance section now has to describe your arrangements for using ICT services under DORA, the incident procedure has to reflect DORA's reporting duties, and the security measures have to show a high level of digital operational resilience under DORA's ICT risk chapter. The E-Money Directive applies these PSD2 authorisation rules to EMIs as well. An applicant becomes a DORA financial entity on the day it is authorised, so the file has to describe a framework that works from day one.
- Map your functions. Decide which functions are critical or important and which ICT services support them.
- Draft the register early. Your core platform, cloud, KYC provider, card processor and banking partner all belong in it.
- Negotiate Article 30 terms before signing. Amending contracts after authorisation is slower and weakens the file.
- Write the incident procedure around real timings. Include the vendor's notification commitment.
- Prepare the exit plan. Show the regulator how you would leave each critical provider.
Crassula is a technology provider, not a regulated firm, and in most client set-ups it supports critical functions. For the application we supply a description of the platform's architecture, hosting, security controls (role-based access, two-factor authentication, audit trail) and our incident process, which you adapt into your own ICT and outsourcing sections. The platform's back office and reporting endpoints give you data exports, but classifying incidents, filing reports and keeping the register remain your tasks. For the licence itself, see our Payment Institution guide and EMI guide, or request a demo.
FAQ
Yes. Article 2 brings in PIs and EMIs that are exempted under PSD2 and the E-Money Directive. They follow the simplified ICT risk framework of Article 16 instead of Articles 5 to 15, but still keep a register of information and follow the rules on incident reporting and ICT contracts.
It is a structured record of every ICT service contract you have, in the template set by Implementing Regulation (EU) 2024/2956. From 2026 the reference date is 31 December of the previous year and national authorities forward the registers to the ESAs by 31 March. Your own deadline is set by your national authority and is earlier.
The initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours, and a final report within one month of the last intermediate report.
Only if their competent authority identifies them. Small exempted institutions and microenterprises are excluded altogether. All other PIs and EMIs still need a testing programme with at least yearly tests of systems supporting critical or important functions.
Probably not. The ESAs' November 2025 list mostly names large cloud and technology firms. That changes nothing for you: a vendor running your critical functions still needs a contract with the Article 30(3) clauses, an exit strategy and a place in your register.
No. DORA is EU law. A UK EMI or PI follows the FCA's operational resilience rules. If you also hold an EU licence through a subsidiary, that subsidiary is in scope.
You inform your authority in good time about the new contract for a critical function, update the register, and follow your exit plan for the old vendor. This is why DORA asks for exit plans and data return terms before you need them.
No. Crassula provides the technology and documentation for your ICT and outsourcing sections, plus data exports from the platform. Incident classification, reporting to your authority and the register of information stay with your firm.
