DORA vs GDPR incident reporting

DORA vs GDPR incident reporting: which clock starts first

A financial entity whose ICT incident also exposes personal data runs two reporting clocks that go to different recipients. DORA major incident reports go to the financial supervisor, and the GDPR breach notice goes to the data protection authority, so filing one does not satisfy the other. The DORA clock depends on classification. Under Delegated Regulation (EU) 2024/1772, the entity first decides whether the incident is major by testing thresholds such as the share of clients affected, downtime for services supporting critical or important functions, and costs and losses over EUR 100 000. Once the incident is classified as major, the initial notification under Delegated Regulation (EU) 2025/301 is due within 4 hours, and in any case no later than 24 hours after the entity became aware of the incident. The GDPR clock starts when the controller becomes aware of the breach, and classification plays no part in it. The controller must notify without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to individuals.

The answer depends on the incident facts, so settle both questions in the first hours, before any draft is written. Record the time of awareness, the classification decision and the reasons for each one. A late GDPR notice must explain the delay, and the 24-hour outer limit applies to the DORA initial notification. Whether a breach is unlikely to create a risk is a documented judgment for the controller, and a wrong call can be costly: failing Article 33 can draw fines of up to EUR 10 million or 2% of total worldwide annual turnover. The Commission's Digital Omnibus proposal COM(2025) 837 would route DORA and GDPR incident reports through a single ENISA-run entry point, but it remains a proposal, and the Commission says existing reporting obligations would not change. Ask your supervisor and data protection authority which templates and channels they expect today, and confirm the proposal's status with counsel before building the process around it. The wider comparison of triggers, content and recipients is on the DORA vs GDPR page.

How triggers, clocks, recipients and content differ

This table compares the two reporting regimes row by row, from legal basis and trigger to clocks, recipients, content and penalties. Read each row as a question you need answered for your incident playbook, and note where the Digital Omnibus proposal would change routing without changing the underlying clocks.

Dimension	DORA major ICT-related incident reporting	GDPR personal data breach notification
Legal basis	Regulation (EU) 2022/2554, Chapter III, with Delegated Regulation (EU) 2025/301 Article 5 setting the report timings	Regulation (EU) 2016/679, Article 33(1)
What triggers the report	An ICT-related incident classified as major under the Delegated Regulation (EU) 2024/1772 thresholds, such as a service outage over 2 hours for services supporting critical or important functions or costs and losses over EUR 100 000	A personal data breach, notified unless the breach is unlikely to result in a risk to individuals
First notice clock	Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it	Without undue delay and, where feasible, within 72 hours of becoming aware of the breach
Intermediate report clock	Within 72 hours of the initial notification	Not applicable; the GDPR sets a single notice, with reasons required if the 72 hours are missed
Final report clock	No later than one month after the latest intermediate report	Not applicable; later information is provided as it becomes available
Recipient	The competent financial supervisor for the entity, as set out in Article 46 of DORA	The competent data protection supervisory authority, as set out in Article 51 of the GDPR
Content	Staged content across initial, intermediate and final reports, covering classification and impact; confirm the field list against the Delegated Regulation before drafting templates	Notice to the supervisory authority; if late, the reasons for the delay must be stated
Penalty ceiling for late or missed reporting	Set by national competent authorities under DORA Chapter VII; confirm the applicable national penalty regime with counsel	Up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, under Article 83(4)(a)
Single entry point	Not in force. The Digital Omnibus proposal COM(2025) 837 would route DORA major incident reports through a single entry point under NIS2, and it remains a proposal awaiting committee decision	Not in force. The same Digital Omnibus proposal would create an ENISA-run single entry point covering GDPR and other laws, and the Commission says existing obligations would not change

When a DORA major incident triggers reporting and when a GDPR breach does

A DORA report starts with a classification decision, not with the discovery of a problem. Under the criteria in Article 9 of Delegated Regulation (EU) 2024/1772, an ICT-related incident is assessed against thresholds that include more than 10 % or more than 100 000 of the clients using the affected service, more than 30 % of financial counterparts, more than 10 % of the daily average transaction number or value, and, for services supporting critical or important functions, a duration over 24 hours or downtime over 2 hours. Further criteria cover impact in two or more member states and costs and losses over EUR 100 000. Classification is what starts the DORA clock, so document each criterion you tested and the data behind it. Confirm the current wording of Article 9 against the full text before you build your checklist.

The GDPR asks a different question. Under Article 33(1), the trigger is a personal data breach, and the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. The exception is a breach that is unlikely to result in a risk to individuals, and that conclusion also needs a written record. A late notice must give the reasons for the delay. None of the Article 9 criteria refers to personal data, so a major ICT incident with no personal data involved may require no GDPR notice, and a personal data breach does not make an incident major for DORA purposes.

The two regimes therefore produce four outcomes: both, DORA only, GDPR only, or neither. An illustrative case: a multi-day outage of a payment service that also exposes customer account records could meet both tests, while a misconfigured batch job that exposes records but stays under every Article 9 threshold would fall under the GDPR alone. Assess each regime on its own evidence, date and sign each classification and risk assessment, and agree in advance who in legal, privacy and operations makes each call. The Digital Omnibus proposal would route both kinds of report through one entry point, but it remains a proposal, so confirm current procedures with your supervisor and data protection authority before an incident occurs.

Who receives each report and what each one asks for

Under DORA Chapter III, a financial entity reports major ICT-related incidents to the competent authority for its type of entity. Article 46 assigns supervision to the national authority for each category of financial entity listed in the Regulation, and the ECB supervises credit institutions classified as significant. Critical ICT third-party providers are overseen directly by the ESAs as Lead Overseers, so they do not report to the national authority in the same way.

Who receives it: the national competent authority for your entity type, or the ECB for a significant credit institution.
What the clock looks like: 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, followed by an intermediate report within 72 hours of the initial notification and a final report no later than one month after the latest intermediate report.
What the content is about: the ICT incident itself, its classification against the thresholds in the delegated regulation, its impact on services and clients, and the recovery and root cause picture as it develops.
Who decides the format: the authority's templates and submission channel, which the technical standards describe only in outline.
What the report is not: it is not an attestation. Supervision is exercised through the powers in Article 50, not through a certificate.

Confirm the exact templates, data fields, submission channel and the authority's expectations for interim updates with your supervisor before an incident occurs.

How to run both clocks in one incident

This sequence lets one incident team meet the DORA reporting clock and the GDPR 72-hour clock without losing track of either, by fixing the time of awareness first and recording every decision with its timestamp. The sequence is an illustrative operating model to confirm with counsel and your competent authority.

Detect and log the incident
The security or operations team opens a single incident record as soon as an ICT-related event is identified, and tags it for both regulatory tracks from the start. The record names an owner, lists the affected systems and services, and links to the detection source. The step is complete when the record exists, has a unique reference, and the incident lead has been named.
Record the time of awareness
The incident lead writes down the moment the organization became aware of the incident, using a timestamp from a synchronized log source rather than an estimate. This single time anchors the GDPR 72-hour period and the DORA 24-hour outer limit for the initial notification. The step is complete when the timestamp is recorded in the incident record and the reference clock source is noted.
Assess DORA classification against Article 9 thresholds
The ICT risk or operational resilience function checks the incident against the thresholds in the Delegated Regulation (EU) 2024/1772 Article 9, such as client impact, duration and downtime for services supporting critical or important functions, cross-border impact and costs and losses. The assessment must be finished before the initial notification is due, and the 24-hour outer limit runs from awareness, not from classification. The step is complete when a dated classification memo states whether the incident is major and which thresholds were met.
Determine whether personal data is affected
The data protection lead, with the incident lead, establishes whether personal data was accessed, altered, lost or made unavailable, and which data subjects and categories are involved. The team also records whether the breach is unlikely to result in a risk to individuals, because that conclusion is the only basis for not notifying under the GDPR. The step is complete when a documented finding states the data affected and the risk conclusion, signed off by the data protection lead.
Notify the GDPR authority within 72 hours
Where personal data is affected and the risk exception does not apply, the data protection lead submits the notice to the competent supervisory authority within 72 hours of awareness, using the timestamp from step two. If the notice goes later, the submission must give the reasons for the delay. The step is complete when the notice reference, submission time and any reasons for delay are filed in the incident record.
Send the DORA initial report
Once the incident is classified as major, the incident lead submits the initial notification to the financial supervisor within 4 hours of classification and no later than 24 hours after awareness, as set by Delegated Regulation (EU) 2025/301 Article 5. The notice should draw on facts already in the GDPR file so that the two filings do not contradict each other. The step is complete when the supervisor's acknowledgment or submission record is filed.
Send the DORA intermediate and final reports
The incident lead sends the intermediate report within 72 hours of the initial notification, updating root cause, impact and recovery facts, and the final report no later than one month after the latest intermediate report. Each update is checked against the GDPR record so any change in personal data scope is reflected in both filings. The step is complete when the final report is accepted into the file and a closing review confirms both tracks are consistent.

What makes the two reporting paths harder or easier to run

Both paths start from the same incident record, but the clocks, recipients and content differ. The cards below name the conditions that make a dual report slower or simpler to produce, so you can test each one against your own incident process before a real event forces the question.

Speed of classification

DORA's initial notification clock starts when the incident is classified as major, but no later than 24 hours after you become aware of it. The GDPR clock starts at awareness. If your classification workflow is slow, the DORA clock can run out before the team has agreed the severity, so the GDPR 72-hour deadline becomes the binding constraint. Check who can make the classification call out of hours and how fast that decision is recorded.

Personal data fields in incident records

The GDPR path applies only when the incident involves personal data, and it needs to know which categories of data and how many individuals are affected. If your incident record has no fields for personal data categories, data subject counts or the affected processing activity, the DPO or privacy team will reconstruct them under pressure. Add these fields to the template so the same record can feed both the DORA reports and a GDPR breach assessment.

Cross-border impact across member states

Several DORA major-incident thresholds count impact in two or more member states, and the GDPR involves the supervisory authority of each affected country in cross-border cases. A single incident can therefore trigger a DORA report to one competent authority and GDPR notices to several data protection authorities. Map which countries your clients, data subjects and services touch before an incident, so the recipient list is ready.

Involvement of an ICT third party

When a cloud provider, software vendor or outsourced processor is part of the incident, the DORA record needs details of the provider and the affected service, and the GDPR processor terms determine who informs you and by when. Vendor notices can arrive late or incomplete, which shortens the time you have to assess the personal data side. Confirm in each contract how quickly the provider must tell you about incidents and what information it must supply.

Number of supervisors involved

A DORA report goes to the competent authority for your entity type, and the GDPR notice goes to the data protection authority. Where the ECB, a national financial supervisor and a data protection authority all have a stake, the same facts must be presented in three formats with different wording and emphasis. Assign one owner for each recipient and agree a single fact base, so the reports do not contradict each other as the investigation changes.

Effect of the single entry point proposal

The Digital Omnibus proposal COM(2025) 837 would route DORA major incident reports and voluntary threat notifications through a single entry point under NIS2, with the Commission stating it would not change existing reporting obligations. The proposal is still awaiting committee decision, so the current DORA and GDPR routes remain in force. Build your runbook around the present obligations, then track procedure 2025/0360(COD) and revise the recipient steps only if it is adopted.

What the proposed single entry point would and would not change

The Commission's Digital Omnibus proposal COM(2025) 837, dated 19 November 2025 and tracked under procedure 2025/0360(COD), would create an ENISA-run single entry point for incident reports under NIS2, the GDPR, DORA and other laws. As of October 2026 the procedure is awaiting committee decision in the European Parliament, so it is a proposal and not law. The Commission states that it would not modify existing reporting obligations. That means the proposal changes where reports are sent, not what must be reported, how fast, or to whom the legal duty applies.

Until any amendment is adopted and applies, your current clocks stay in force. For a major ICT-related incident that also involves personal data, that means the DORA initial notification within 4 hours of classification and no later than 24 hours after awareness, the intermediate report within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report, alongside the GDPR notice to the data protection authority within 72 hours of awareness. Do not assume a single submission will discharge both duties. Check with your competent authority and your data protection authority how they expect a joint notice to be handled today.

Plan for both paths now. Map each incident playbook to the current recipients, keep the DORA and GDPR templates and internal approval steps in place, and record the fields that each regime requires so that any future single entry point can be fed from the same data. Ask your legal team to track the Omnibus procedure and the Commission's Digital Omnibus press release for changes to the reporting articles, and confirm with your supervisors whether any interim guidance will apply before amendments take effect.

How to test your incident reporting before a real incident

This sequence runs a tabletop exercise on one event that is both a major ICT-related incident under DORA and a personal data breach under the GDPR, so the team can see where the two reporting clocks, recipients and records diverge before a real incident forces the decisions. The output is a dated record of who acted, when each clock started, what each report needed, and which open questions must go to the supervisor and the data protection authority.

Write a scenario that triggers both regimes
Build one written scenario in which an ICT outage or compromise affects a service supporting a critical or important function and also exposes customer personal data. Check the scenario against the Delegated Regulation (EU) 2024/1772 thresholds, such as client impact, duration, geographic reach and cost, so that it is classified as major under DORA, and confirm that a personal data breach is likely under the GDPR. Label the scenario as illustrative and keep a copy in the exercise file. The step is done when the incident lead and the compliance lead have both signed off on the threshold reasoning.
Record the awareness moment and start the clocks
Ask the exercise facilitator to fix a single awareness time in the simulated incident record, and have participants note whether that time is the moment the entity became aware of the incident, the moment it classified the incident as major, or both. DORA's initial report is tied to classification within 4 hours and to awareness no later than 24 hours, while the GDPR 72-hour clock runs from awareness of the breach. Write each deadline next to the time it was derived from. The step is done when every clock has a calculated due time and a recorded starting point that the group agrees on.
Confirm an owner for each recipient
List each recipient in the scenario: the national competent authority for DORA, the data protection authority for the GDPR, and any other body the entity's own procedures require. Name one accountable person for each, with a deputy, and state who drafts, who approves and who sends. Test the handoff by having the exercise lead ask each owner to explain, in one sentence, what they will send and when. The step is done when the RACI for the exercise shows a named owner for every recipient and no recipient is left with a shared mailbox as its only owner.
Check the incident record holds the required fields
Compare the simulated incident record against the content each report needs: the DORA initial, intermediate and final reports, and the GDPR notice content for the affected categories, approximate number of data subjects and records, likely consequences and measures taken. Mark any field that is missing, unclear or recorded in a different system. Where a field is needed for both reports, such as the impact description, check that one source of truth feeds both. The step is done when the gap list is complete and each gap has a named owner and a fix date set by the entity.
Walk the three DORA stages and the GDPR notice
Run the exercise forward in time, drafting the DORA initial notification, the intermediate report and the final report, along with the GDPR breach notice, using the entity's own drafts. Stop at each deadline and check whether the draft is ready, whether late reasons would need to be recorded for the GDPR notice, and whether any report would need to be updated when new facts arrive. The step is done when each draft is saved with its timestamp and the group has noted which report would have been the bottleneck.
Confirm channels and templates with the supervisors
Contact the national competent authority and the data protection authority, or use the entity's existing supervisory relationship, to confirm which submission channels, forms, templates and contact points they currently use for major ICT incident reports and for personal data breach notices. Ask whether an entry point or template change is expected under the pending Digital Omnibus proposal, which the Commission says would not modify existing obligations until adopted. Timings, forms and channels must be confirmed in the entity's own environment and with each authority, not taken from this exercise. The step is done when the written answers are filed, dated, and linked from the incident procedure.
Record the exercise results and update the procedure
Write a short after-action record that lists the timestamps achieved, the owners confirmed, the fields missing, the supervisor answers received and the procedure changes agreed. Assign each change to an owner and schedule a retest of the scenario after the changes are made. Keep the record with the incident response plan so that auditors and supervisors can see the test was run. The step is done when the procedure has been revised, the open actions are tracked, and a retest date is in the calendar.

Questions buyers ask about DORA and GDPR incident reporting

Does one ICT incident always require both a DORA report and a GDPR notice?

No. An incident needs a DORA major incident report only if it is classified as major under the incident classification criteria, and it needs a GDPR notice only if it is a personal data breach. Some incidents trigger both, some trigger only one. The GDPR notice is also not required where the breach is unlikely to result in a risk to individuals (Article 33(1)). The practical step is to run both classification checks at the same time, record the reasoning for each, and agree who signs off. Confirm the mapping with your supervisor and your data protection authority, since neither framework settles every borderline case for you.

What are the DORA and GDPR reporting clocks?

The two clocks start at different points and run on different schedules. Under Article 5 of Delegated Regulation (EU) 2025/301, the DORA initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. The GDPR requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours after the controller becomes aware of the breach (Article 33(1)). A late GDPR notice must give reasons for the delay.

Does a late GDPR breach notice carry a fine, and how large is it?

Yes, a late or missing notice can be fined. Failing to meet Article 33 falls under Article 83(4)(a), with a maximum of EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. This is the lower fine tier, and the actual amount depends on the supervisory authority's assessment of the infringement, including its nature, duration and whether the controller cooperated. A late DORA report is handled by the national competent authority under its supervisory powers, which the Regulation sets out separately. Ask your counsel how both regimes would apply to a single late event, since the two supervisors may act independently.

Is the single reporting entry point already in force?

No. The Commission's Digital Omnibus proposal COM(2025) 837 of 19 November 2025 would route DORA major incident reports and voluntary threat notifications through a single entry point under NIS2, and would create an ENISA-run entry point for incident reports under NIS2, GDPR, DORA and other laws. The Commission states it would not modify existing reporting obligations. As of October 2026, the European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision. Plan for the current DORA and GDPR routes, and track the procedure before changing your process.

How much effort does a dual-reporting process take, and what drives it?

Effort is driven by how many incidents touch personal data, how quickly your team can classify them, and how many reports must be drafted from the same facts. The main cost components are staff time for classification, drafting and sign-off across security, legal, privacy and the business, plus any tooling for incident records. Costs are largely recurring because the process runs for every incident and must be rehearsed. Ask any provider for a written scope listing the reporting roles, the templates covered, the rehearsal plan and what is one-time versus recurring. DeployOpen quotes follow a written scope agreed before work starts.

Can our team run DORA and GDPR incident reporting without outside help?

Many financial entities run it in-house, provided they have documented criteria, named owners and tested timelines. Outside help is most useful for designing the classification workflow, mapping DORA and GDPR fields to one incident record, and running a tabletop exercise against the clocks. The decision depends on your team's existing incident response maturity, the volume of incidents, and how much of the process already exists. DeployOpen plans, implements and documents self-hosted platforms in your own environment, runs security testing and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Confirm the scope with your supervisor and data protection authority before relying on any design.

What neither regime certifies and what the file should hold

Neither regime gives you a certificate to point to. DORA sets no certification scheme, and the GDPR requires no audit, attestation or certificate. Under Article 42 of the GDPR, certification is voluntary and does not reduce the controller's responsibility. So the proof of compliance is the incident file itself: the initial, intermediate and final DORA reports, the GDPR breach notice where one applies, the classification record and the reasoning behind every decision. Supervisors will judge the file, not a badge, which means the file has to show how the entity reached each decision and when.

Build the file as a dated decision log from the first hour. Record who classified the incident as major under the Delegated Regulation (EU) 2024/1772 criteria, when that happened relative to the 4 hour and 24 hour clocks, and which thresholds were met or ruled out. For the GDPR side, record the moment the controller became aware of the breach, the risk assessment, and the reasons for any delay past 72 hours. Where the entity concludes that a personal data breach is unlikely to result in a risk to individuals and so does not notify, the reasoning behind that exception needs its own dated entry, signed off by a named owner. Keep drafts and changes to the reports so the sequence of what was known and when can be reconstructed.

Confirm with your national competent authority and your data protection authority how they expect these records to be kept, retained and produced during an inspection, since neither regime fixes a retention period in the material reviewed here. Also check whether your supervisor expects a particular template or channel for the reports while the proposed single entry point remains a proposal. Test the process with a tabletop exercise so the file can be produced quickly under pressure.

How DeployOpen helps evaluate and implement dual incident reporting

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including the workflows that route one incident into a DORA report and a GDPR breach notice. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Map which incidents touch both ICT services and personal data, and which entity files each report.
Record the classification inputs, clocks and recipients for DORA and GDPR side by side in the written scope.
Confirm with your legal and compliance teams which national authorities and data protection authorities apply to your entities.

How we build

Configure incident records that capture the fields needed for DORA initial, intermediate and final reports and the GDPR notice.
Set up timers and escalation paths that track each clock from the moment of awareness, under your agreed procedure.
Test the workflow with tabletop-style exercises that simulate an incident touching both regimes, then document the results.

How we hand over

Deliver runbooks showing who decides on classification, who drafts each report and who approves submission.
Document the configuration, data flows and access controls so your own engineers can operate and change the workflow.
Provide an evidence pack of test records and configuration baselines for your internal reviewers and independent auditors.

How we support

Offer ongoing support, upgrades and continuous testing of the reporting workflow as a retainer.
Review the workflow when regulatory texts change, including any outcome of the Digital Omnibus proposal, within the agreed scope.
Confirm with your supervisors and counsel any reporting format or single entry point requirement before relying on it.

DORA vs GDPR incident reporting