A serious cyberattack can demand more than one regulatory notification, but a bank does not normally owe three parallel filings merely because DORA, NIS2 and GDPR all appear in its regulatory map. For financial entities covered by DORA, its ICT incident-reporting rules take the place of the corresponding NIS2 rules. GDPR can still impose an independent personal-data-breach notification. A separately constituted cloud or managed-service provider may have its own NIS2 duty for the same attack. Those are distinct legal decisions, not three automatic reports by the bank.
The useful starting point for DORA NIS2 GDPR incident reporting is therefore the legal entity, its regulated activity and the applicable incident threshold. The European Commission’s guidance on NIS2 Article 4 expressly identifies DORA as the sector-specific law for covered financial entities: DORA’s major ICT-incident reporting applies instead of NIS2 reporting. This page explains that boundary, compares the real clocks, and supplies a worked routing record that an incident team can adapt to its own country and authority.
First decide which legal entity must report
Do not begin with a single group-wide list of regulations. Begin with the bank, insurer, payment institution, cloud provider or other legal person that suffered or caused an incident. Confirm whether each entity falls within DORA Article 2, national NIS2 scope, and GDPR’s controller or processor roles. Being a supplier to a bank does not by itself make a provider a DORA financial entity; being a GDPR processor does not by itself make that provider responsible for the controller’s Article 33 filing.
| Entity and event | DORA major-incident route | NIS2 significant-incident route | GDPR breach route |
|---|---|---|---|
| DORA-covered bank; material service outage and customer-data exfiltration | Assess DORA classification, then report if major | Corresponding NIS2 Article 23 duty is displaced by DORA Article 1(2) and NIS2 Article 4 | Assess the bank’s controller duty under Article 33; consider Article 34 separately |
| DORA-covered bank; small technical fault with no reportable personal-data breach | Record and assess; report only if the DORA major threshold is met | No duplicate NIS2 Article 23 track for the bank | Record the incident; no authority notice solely because a system failed |
| Separate cloud provider; outage affecting the bank and the provider’s own in-scope service | DORA Article 19 duty normally belongs to the bank as financial entity | Provider assesses its own national NIS2 scope and Article 23 significance; it may need to report | If acting as processor, notify the controller without undue delay under Article 33(2) when it becomes aware of a personal-data breach |
| Non-financial NIS2 entity; significant service disruption and personal-data breach | Not applicable unless it separately qualifies as a DORA financial entity | Assess Article 23 and applicable national rules | Its controller assesses Article 33 and, if high risk, Article 34 |
The table is an applicability matrix, not a statement that each example necessarily meets a reporting threshold. DORA’s classification regulation, Delegated Regulation (EU) 2024/1772, evaluates criteria such as affected critical services, clients and transactions, downtime, data losses, geographic spread and economic impact in the required combination. An event’s record count or outage duration alone cannot replace that classification. NIS2 Article 23 asks whether the incident has a significant impact on the entity’s service under the directive and relevant national or sector-specific rules. GDPR Article 33 asks whether a personal-data breach is unlikely to result in risk to people’s rights and freedoms; Article 34 uses the higher likely high-risk test for communication to individuals.
Why a DORA report is not a second NIS2 report
NIS2 Article 4 disapplies equivalent sector-specific reporting provisions. DORA Article 1(2) designates DORA as that sector-specific act for the relevant financial entities. The Commission’s Article 4 guidance says Member States should not apply the NIS2 incident-reporting obligations to DORA-covered financial entities. This rule is often lost when an incident is described simply as affecting a “banking sector” organisation listed in NIS2’s annex.
There is an important routing qualification. DORA Article 19(1) allows a Member State to require some or all financial entities to provide their DORA initial notification and reports, using DORA templates, also to a NIS2-designated competent authority or CSIRT. Check whether that option applies in the relevant country. A required copy is still a DORA report; it is not a new NIS2 Article 23 early-warning, notification and final-report sequence. National contact lists and portals must be verified before an incident because they can differ by entity and jurisdiction.
Compare the deadlines without combining the clocks
The three regimes start from different legal facts. The following is an EU-level comparison for entities to which each route actually applies. It is not a timetable requiring a covered bank to file every column. DORA detail comes from Delegated Regulation (EU) 2025/301, Article 5; NIS2 detail comes from Article 23; GDPR detail comes from Articles 33 and 34.
| Stage | DORA: covered financial entity with a major ICT incident | NIS2: in-scope entity with a significant incident | GDPR: controller with a reportable personal-data breach |
|---|---|---|---|
| First submission | As early as possible, within four hours after classification as major and normally no later than 24 hours after awareness of the ICT incident | Early warning without undue delay, in any event within 24 hours after awareness of the significant incident | Notify supervisory authority without undue delay and, where feasible, within 72 hours after awareness of the personal-data breach |
| Next required submission | Intermediate report within 72 hours after the initial notification, even if status has not changed; update when regular activities recover | Incident notification without undue delay, in any event within 72 hours after awareness of the significant incident; a trust-service exception may shorten this stage to 24 hours | No fixed “intermediate” stage; provide information in phases without undue further delay if all facts are not yet available |
| Later report | Final report no later than one month after the intermediate report or latest updated intermediate report | Final report no later than one month after the incident notification; requested intermediate reports and an ongoing-incident progress report may also be required | Communicate to affected people without undue delay if likely high risk, unless an Article 34 exception applies |
If a DORA incident is first classified as major more than 24 hours after awareness, Article 5(2) of Regulation 2025/301 requires the initial notification within four hours of that later classification. This exception is not a licence to delay reasonable assessment. If a financial entity cannot submit within a deadline, Article 5(3) requires it to inform the competent authority without undue delay, no later than that deadline, and explain the delay. Keep separate timestamps for first awareness, major classification, each submission and the authority’s receipt. For NIS2, the ordinary 72-hour filing is the substantive incident notification, not an “intermediate report”; an intermediate report follows if the competent authority or CSIRT asks for one. If the incident is still ongoing when the NIS2 final report would be due, Article 23(4)(e) calls for a progress report then and a final report within one month of handling the incident.
GDPR’s 72 hours is qualified by “where feasible,” not a grace period to wait for complete forensic certainty. Article 33(4) permits phased information when it cannot all be provided at once. The controller must still justify any delay, document the breach under Article 33(5), and assess communication to individuals separately. A processor must inform its controller without undue delay under Article 33(2); the processor’s notice does not itself discharge the controller’s authority duty. For a focused sequence, use the GDPR breach-notification playbook. For the financial clock and report content, use the DORA incident-reporting guide.
Worked example: one attack, several legal decisions
Assume a bank and a separately incorporated cloud provider operate in the same Member State. At 08:00, both discover that the bank’s customer portal is unavailable and that suspicious access and outbound traffic occurred on a hosted system; neither yet knows whether customer records were copied. The cloud provider is a managed-service provider in scope of that country’s NIS2 law; that status is an explicit assumption for the example. The bank controls the customer data and the provider processes it under contract. These assumed facts illustrate the decision path, not a conclusion about a real entity.
At 08:20, the provider tells the bank about the suspected data compromise. That communication matters under GDPR Article 33(2) and the contract, even before either organisation has a complete root-cause analysis. At 09:00, the bank’s incident team records the systems affected, customer impact, data types, service dependency and first containment action. For this fictional exercise, assume the portal supports a critical or important bank function and investigators establish at 10:00 that the attacker obtained successful malicious unauthorised access to its supporting network, with possible data loss. That supplies the affected-critical-services condition in Article 6 and the Article 9(5)(b) materiality route under Article 8(1)(a) of Regulation 2024/1772; the bank therefore classifies the incident as major at 10:00. It has until 14:00 under the four-hour classification limit for the initial DORA notification, subject also to the normal awareness limit. If it files at 12:00, its intermediate report is due within 72 hours from 12:00, not 72 hours from discovery at 08:00.
The bank’s privacy team separately assesses what was accessed, whether confidentiality was lost and the likely risks to people. Suppose at 11:00 it has enough evidence to be aware of a personal-data breach likely to create risk. It begins an Article 33 notification to the competent data protection authority and records the 72-hour reference point. The bank should not assume that filing its DORA notice informs the DPA. If the likely risk becomes high, it also assesses Article 34 communication to individuals without undue delay and any applicable exception, such as effective encryption of the affected data. It can state unknown details as such and supplement the authority report later.
The provider asks a different question: has this incident significantly affected the provision of its own NIS2-covered service under applicable rules? If it becomes aware of that significance at 09:30, its NIS2 early warning is due without undue delay and in any event within 24 hours of 09:30; its substantive incident notification is due within 72 hours of that awareness. The bank’s DORA notice neither fulfils nor automatically triggers the provider’s NIS2 duty. Conversely, if the provider’s own service does not meet the NIS2 significance test, the bank’s major incident does not turn the provider’s incident into a reportable NIS2 event by association. The NIS2 incident-reporting guide describes that provider’s later stages and trust-service exception.
The resulting record may contain bank DORA, bank GDPR and provider NIS2 reports, but those belong to two entities under different tests. It is not a “triple filing” by the bank. The provider may also have its own GDPR role and duties if it is a controller for another data set; that requires a separate data-flow analysis. A Member State may require the bank to copy its DORA reports to a NIS2-designated authority under DORA Article 19(1), but the copied DORA form does not add a NIS2 Article 23 deadline for the bank. The DORA compliance guide explains the financial entity’s wider governance responsibilities.
Build one evidence record with separate filing decisions
A shared incident record reduces contradictory facts across submissions, provided it does not erase each entity’s legal responsibility. Capture the incident’s timeline, observed systems, service impact, personal-data categories, evidence quality and outstanding uncertainties. Then create a decision row for each potentially applicable route. The detection use-case validation card can document whether an alert path produced the expected telemetry in a safe simulation; a successful test is useful readiness evidence, not an incident classification or filing decision.
For each decision row, name the entity, legal basis, trigger fact, awareness/classification time, deadline, recipient, submitter and receipt evidence. Record a reasoned “not reportable” conclusion as carefully as a filing. If facts change, reopen the decision; do not silently overwrite the earlier assessment. A central incident commander can coordinate the factual record while the bank’s DORA lead, the controller’s privacy lead and the provider’s NIS2 lead retain their own authority to classify and submit.
An effective rehearsal includes a late-classification variant. For example, if a bank initially treats an outage as minor but learns on day two that a critical service was compromised, the team must document when it first had enough facts to classify the event as major and apply DORA’s later-classification rule. Rehearse how the GDPR team receives processor updates, how a provider decides its own NIS2 significance, and which alternate channel is used if an authority portal is unavailable. These exercises test escalation and evidence sharing without inventing a universal internal two-hour statutory deadline.
The recipient map should be entity-specific. A DORA-covered financial entity reports under Article 19 to its designated financial competent authority; for significant credit institutions, the national authority transmits to the ECB. A GDPR controller reports to its competent supervisory authority under Article 33. An entity with an independent NIS2 duty reports to its designated CSIRT or, where applicable, competent authority under Article 23 and national implementation. Do not hard-code ANSSI, the ECB, a DPA or a CSIRT for every organisation in a country without confirming jurisdiction, role and the current portal. Save the local contact and fallback instructions with the playbook, and review them when laws or supervisory guidance change.
Enforcement, statistics and the proposed EU entry point
Missing a required notice creates a compliance risk, but adding the maximum fine amounts of all three laws for a bank’s supposed triple filing is legally misleading. GDPR Article 83(4)(a) places infringements of Articles 25–39, including breach-notification duties, in the tier of up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher for an undertaking; an authority assesses the actual case under Article 83(2). The GDPR fines guide explains why a ceiling is not an expected sanction. DORA Article 50 requires Member States to establish appropriate administrative penalties and remedial measures; it does not give one universal EU-wide fine figure for every late report. For entities independently subject to NIS2, Article 34 requires national maxima of at least EUR 10 million or 2% for essential entities and at least EUR 7 million or 1.4% for important entities, whichever is higher. Check the actual national law and entity category before describing exposure.
The old page claimed an EU-wide annual total for combined GDPR, DORA and NIS2 reports without evidence. DLA Piper’s January 2026 survey reports an average of 443 personal-data-breach notifications per day between 28 January 2025 and 27 January 2026 across the European jurisdictions it surveyed. That is a GDPR-related survey figure; it is not a count of unique cyber incidents or a combined three-regime reporting total. It should not be multiplied into a conjectural demand estimate for this page.
The European Commission published its Digital Omnibus Regulation proposal on 19 November 2025. Its Digital Package explanation describes a proposed ENISA-managed single entry point through which comparable information could contribute to notifications under NIS2, GDPR, DORA and other listed acts. The Commission says this would not change existing reporting obligations or the authorities designated to receive reports. It does not support an assertion that GDPR would remain a permanently separate portal, that DORA and NIS2 classification tests would merge, or that a proposal has already replaced current submission routes. Plan for the law and channel in force when an incident occurs; track later adoption and implementation separately from the proposal.
Frequently asked questions
Does every bank breach require DORA and GDPR notices?
No. A bank’s ICT event needs the DORA major-incident classification; a personal-data event needs GDPR’s separate breach and risk assessment. A major DORA outage need not involve personal data. A personal-data breach can fall below the DORA major threshold. When both thresholds are met, preserve a common factual record and make both required submissions through their respective routes. The DORA and GDPR overlap analysis explains where the two legal tests meet and diverge.
Does a DORA-covered bank also send a NIS2 early warning?
Normally no separate NIS2 Article 23 early warning is owed for the corresponding incident-reporting duty: DORA is the sector-specific regime under NIS2 Article 4. Check whether national law invokes DORA Article 19(1)'s option to send copies of DORA reports to a NIS2-designated authority or CSIRT. That routing requirement is different from a second NIS2 classification, clock and template. A group company’s own NIS2 status must be assessed independently.
Can a provider’s NIS2 filing satisfy the bank’s DORA duty?
No. A separately constituted provider’s NIS2 duty concerns that provider’s in-scope services and recipient. DORA Article 19 assigns the bank’s major-incident reporting duty to the financial entity, although reporting tasks may be outsourced under DORA’s conditions. The bank needs reliable contractual information and an accountable internal owner. The DORA third-party risk guide helps map supplier evidence without transferring the bank’s legal accountability.
If the incident is still evolving, should we wait to notify?
Do not wait merely for a complete root cause. Apply each route’s awareness and classification rule, use the available facts and mark uncertainty. DORA requires an initial, intermediate and final process; NIS2 requires early warning, substantive notification and final reporting with requested or ongoing-incident updates; GDPR permits phased information. Reassess and correct submissions as evidence develops. Record why a deadline was calculated from a particular time and retain receipts so the sequence can later be reconstructed.
Will the proposed single entry point eliminate the legal analysis?
No. As proposed, it is an interface for overlapping information, not a replacement for each regime’s reportability test or recipient authority. A bank would still decide whether DORA and GDPR apply, while an independent NIS2-covered provider would decide its own duty. Until any adopted rules apply, use the currently required channels. A shared incident record remains useful regardless of how the final EU interface develops.