DORA incident reporting for financial mobile apps

Financial services have become primarily digital for most customers. Whether it's approving a payment on your phone, sending money via bank transfer, or investing—all these actions are now 'digital-first'.

But this creates a key vulnerability. With financial security being increasingly dependent on these digital services, it's more important than ever that financial entities (FEs) can implement a baseline of effective cybersecurity defense and ensure operational resilience.

Crucially, when security incidents occur, it's vital that information about them is quickly shared with relevant authorities and stakeholders across the EU. This helps strengthen the collective defense of financial entities and enhance resilience against digital threats.

That's where Article 19 of the Digital Operational Resilience Act (DORA) comes in. This is a detailed and stringent set of incident reporting requirements that FEs must adhere to in the event of a 'major' incident. In this blog, we consider the requirements, when they're likely to be implemented, and what they mean for you. 

What is DORA? Recapping the basics

DORA is the regulation governing cybersecurity standards among FEs across Europe. It principally focuses on banks, investment firms, and insurance companies operating in the European Union (EU) and European Economic Area (EEA). 

While the regulation came into force on January 16, 2023, it applies to FEs from January 17, 2025. That said, in practice, there are several stages it still needs to go through before it is fully functional and enforceable. More on this below. 

In addition to several provisions on aimed at ensuring operational resilience, DORA features stringent standards around incident management, classification, and reporting. While the principal focus is on traditional corporate networks, by any reasonable definition, it also must include customer-facing mobile finance apps.

But DORA isn't limited to banks (and mobile banking apps). Credit institutions, payment institutions, electronic money institutions (EMI), and anybody issuing crypto-assets must also comply. That said, it’s important to note that there are exemptions listed in Article 2(3), including managers of alternative investment funds, small insurance providers, and more. Nonetheless, the majority of financial entities will be regulated by DORA.

If this includes your organization, you should technically already be compliant, since the main legislation is already in force. If you aren't, you need to prioritize compliance immediately. 

How to decide if a security incident should be reported

DORA requires FEs to define an incident management process which includes identifying, classifying, and reporting ICT-related incidents. It emphasizes the need for robust governance and risk management structures, including policies and guidelines for incident handling.

Ensuring visibility into your mobile financial apps is essential for timely incident detection and response, helping to prevent minor issues from becoming major incidents that require reporting. 

Under DORA, an incident is classified as either 'major' or 'not major'. The criteria for classifying an incident as major include factors like the criticality of services affected, client impact, reputational impact, duration of downtime, and economic impact. So it follows that your mobile app is subject to DORA and its incident reporting requirements if it affects critical functions.

Under Article 3(10) of DORA, a 'major incident' is defined as:

"An ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions of the financial entity."

And under Article 3(22), a 'critical or important function' is defined as: 

"A function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law."

In practice, anything classified as 'major' under the criteria detailed in the Delegated Regulation on criteria for the classification of ICT-related incidents and cyber threats should be reported. This is a supplement to DORA and outlines specific criteria and materiality thresholds for determining whether an incident is major.

DORA incident reporting timelines: How and when to report significant cyber threats

DORA lays out clear requirements for your incident response in the event of a significant threat. This includes a requirement to report major incidents to the relevant National Competent Authority (NCA). You also generally have to notify your customers about major incidents, though the regulations offer more flexibility here. 

The regulation aims to ensure this information is provided as soon as possible after an incident is detected. But, crucially, it recognizes that expecting a detailed report with full context immediately isn’t practical. So, Article 19(4) of DORA lays out a multi-stage process, with three different stages: 

• Initial notification
• Intermediate report: Submitted after the initial notification when there is a significant change in the status of the incident or its handling due to new information. Additional updates should be provided whenever there are relevant status changes or upon request by the competent authority.
• Final report: Must be submitted once the root cause analysis is complete and actual impact figures are available, even if mitigation measures have not yet been fully implemented.

There is some flexibility in these timelines for incidents that initially seem minor and subsequently are revealed to be broader in scope. In these cases, the timelines can apply from when the incident was designated critical, rather than from when it was first detected.

When it comes to notifying customers, Article 19(3) states:

"Financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incidents."

On the surface, it seems the wording provides some flexibility to assess the scope and implications of the attack before informing customers. 

But it's important not to overestimate the amount of flexibility this allows. Realistically, you won’t be able to comply with these rules without an adequate incident detection and response plan, including client communications.

In short, there is some flexibility to hold off on informing customers while you assess the threat, its scope, and response measures. But NCAs aren't likely to look favorably on delays resulting from inadequate detection measures or poor incident management processes.

DORA timelines: What are they, and when will they become enforceable?

While DORA has been passed and is in force and applies, there is still a lot of confusion around some of the finer details, including those around incident reporting.

This is a feature of how EU compliance laws are created. While the main legislation has been drafted and passed by the EC, the more detailed technical standards are often published separately. 

In the case of DORA, three European Supervisory Authorities (ESAs) have been tasked with supplementing the regulation with various technical standards. These ESAs are the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA). 

At the time of writing, the final draft Regulatory Technical Standard (RTS) on incident reporting—which expands on DORA Article 19(4)—has been adopted by the EBA and submitted to the EC. The RTS mandates the following timelines:

Unfortunately, I can't speak to when these technical standards will be adopted. Once the ESAs submit a draft RTS as in this case, the EC reviews it and decides whether to adopt it as a Delegated Regulation. If adopted, it is published in the Official Journal of the European Union and enters into force on a specified date. While this seems straightforward, the process is often complex and subject to delays or rejections.

For example, the ESAs submitted a draft Delegated Regulation (the RTS on subcontracting), to the EC on July 17, 2024, which was later rejected in a letter dated 21 January 2025, mere days after all FEs were required to comply with DORA. A few weeks later, on March 7, 2025, the ESAs issued an Opinion acknowledging the ECs assessment, confirming proposed amendments, and urging the EC to finalize the adoption.

Understandably, this creates considerable uncertainty about when the remaining technical standards will come into force—and what timelines and rules you should adhere to in the meantime. Until the final details are confirmed, organizations should rely on the main requirements outlined in the main legislation. As a starting point, note that Article 19 of DORA states that FEs should report incidents "without undue delay".

In practice, it also means you should default to incident reporting timelines in existing legislation. Under Article 33 of the General Data Protection Regulation (GDPR) for instance, personal data breaches should be reported within 72 hours. And under Article 96(1) of the revised Payment Services Directive (PSD2), payment service providers must report incidents within four hours. In the case of the draft PSD3 and Payment Services Regulation (PSR), there is a move to harmonize incident reporting requirements with other EU regulations like DORA. 

Read more: Achieve PSD2 compliance with mobile app shielding

Of course, while these timelines serve as benchmarks, they are not directly applicable to all DORA requirements. However, they can serve as interim guidance and inform incident reporting practices until DORA's specific RTS are finalized. When in doubt, report incidents as soon as you reasonably can. 

How to keep financial mobile apps secure and DORA-compliant

The ICT systems DORA regulates must include mobile financial apps. Though not all mobile app-related issues will trigger DORA reporting obligations, incidents that could affect the availability, confidentiality, or integrity of mobile apps—and are classified as major—would require reporting. This could include incidents like injection attacks, man-in-the-middle (MitM) attacks, app tampering, and more.

Case in point, Article 9 establishes a clear continuous monitoring obligation on FEs, with 9(1) highlighting a broader set of requirements for protection and prevention:

"For the purposes of adequately protecting ICT systems and with a view to organising response measures, financial entities shall continuously monitor and control the security and functioning of ICT systems and tools and shall minimise the impact of ICT risk on ICT systems through the deployment of appropriate ICT security tools, policies and procedures."

In addition, Articles 10 and 17 establish clear detection and incident management requirements for FEs. Together, they are part of a comprehensive approach to ICT risk management that includes identification, protection, detection, response, recovery, and learning and improvement.

"Financial entities shall have in place mechanisms to promptly detect anomalous activities, in accordance with Article 17, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure... ."

It should go without saying that the best way to comply is, as usual, prevention. And for that, you’ll need multi-layered mobile app protection. However, in the event of an incident, and to effectively meet your reporting obligations under DORA, it's crucial to have deep insight into your mobile financial apps. This allows you to identify potential threats early and prevent incidents from escalating into major issues. Without robust detection capabilities, you risk failing to identify and classify incidents, which can significantly hinder your ability to comply with the stringent reporting requirements outlined in DORA. 

This is a particular challenge if your app depends on external SDKs or 3rd-party code libraries, where you might not have oversight over the risks they might introduce. In this case, it’s just as important to protect your entire app as it is to detect malicious activity or performance degradation immediately to comply with DORA, which falls in line with the Chapter V obligations around third-party risk management.