DORA vs GDPR

DORA or GDPR: why a financial entity usually needs both

If you are an EU financial entity, the question this section answers is which of two regimes governs a given event, and the honest answer is usually both. DORA, Regulation (EU) 2022/2554, is the binding law on digital operational resilience: ICT risk management, major ICT-related incident reporting, digital operational resilience testing and ICT third-party risk, supervised by your national competent authority. The GDPR, Regulation (EU) 2016/679, governs the processing of personal data and is enforced by national supervisory authorities. Because they answer different questions, this is rarely an either-or choice. Neither issues a certificate. DORA sets no certification scheme, and the GDPR requires no audit, attestation or certificate, so your evidence for each goes to a supervisor or data protection authority, not to a badge.

The first decision for any incident, vendor or process is whether it touches personal data. A cloud outage may trigger a DORA major incident assessment with no personal data involved, while a misdirected customer file may trigger a GDPR breach notice and also bear on DORA classification. Run this check in your incident runbook and in your ICT provider reviews, and record the answer, because it determines which clocks start and which recipients you must contact. Confirm with your legal and data protection teams how your classification criteria and personal data flags are recorded in your tooling.

Plan for two sets of obligations running in parallel, with different deadlines and recipients. Your readiness review should confirm that the people who classify incidents can also identify personal data exposure quickly, and that contracts with ICT providers cover both regimes. Ask your counsel to confirm how the proposed single reporting entry point in the Digital Omnibus would affect your workflow, noting that the Commission says it would not modify existing reporting obligations and that the proposal remains under negotiation.

How DORA and the GDPR differ on scope, proof and penalties

This table compares who each text applies to, what it requires, who supervises it, what proof it produces and how fines are set. Read it to see which regime governs which part of an incident or contract, since one event can fall under both. The main takeaway is that DORA is supervised for ICT risk without a certificate, while the GDPR has no audit or certificate requirement and sets fixed fine ceilings.

Dimension	DORA (Regulation (EU) 2022/2554)	GDPR (Regulation (EU) 2016/679)
Who it applies to	The 20 types of financial entity listed in Article 2(1), plus ICT third-party service providers in point (u)	Any controller or processor handling personal data, in EU Member States and in Iceland, Liechtenstein and Norway
What it governs	ICT risk management, ICT-related incident management and reporting, resilience testing, ICT third-party risk and information sharing	Lawful processing of personal data, security of processing (Article 32), breach notification (Articles 33 and 34) and transfers to third countries
Supervisor	National competent authority for each entity type under Article 46, the ECB for significant credit institutions, and ESAs as Lead Overseers for critical ICT providers	Independent national supervisory authorities (Article 51), with the European Data Protection Board resolving disputes
Proof produced	No certification scheme. Supervision under Article 50 is the main form of proof, with one authority-issued attestation: that a threat-led penetration test met requirements (Article 26(7))	No audit, attestation or certificate is required. Article 42 certification is voluntary, valid for at most three years, and does not reduce responsibility
Fine structure	No EU-wide maximum or minimum. Member states set administrative penalties under Article 50(3) that must be effective, proportionate and dissuasive	Article 83 sets maximums of EUR 10 million or 2% of worldwide annual turnover, and EUR 20 million or 4% for the more serious infringements, whichever is higher
Legal status of the text	Regulation, directly applicable without national transposition, applying since 17 January 2025	Regulation, binding in its entirety and directly applicable, applying since 25 May 2018, text not amended as of October 2026

How the DORA incident clocks and the GDPR 72-hour notice interact

A single ICT incident that also exposes personal data can start two notification clocks, and they do not have to start at the same moment. Under DORA Article 5(1), a major ICT-related incident needs an initial notification within 4 hours of classification as major and no later than 24 hours after awareness. An intermediate report follows within 72 hours of the initial notification, and a final report is due no later than one month after the latest intermediate report. The GDPR Article 33(1) clock is simpler: the controller notifies the supervisory authority within 72 hours of becoming aware of a notifiable personal data breach. The DORA clock is tied to classification as major, while the GDPR clock runs from awareness. A team that waits for classification before starting its GDPR assessment can miss the earlier GDPR deadline.

The recipients also differ. DORA reports go to the competent authority for the financial entity, and the GDPR notice goes to the data protection authority. Both may apply to the same incident, so the incident record should show, for each report, the trigger, the time of awareness, the time of classification and the addressee. Confirm with your competent authority and your data protection authority which contact channels and templates they expect, since the supplied material does not set out their formats. The Commission's Digital Omnibus proposal of 19 November 2025 would create a single entry point run by ENISA, but it remains a proposal and does not change current obligations.

Illustrative example only: a payments subsidiary becomes aware of an intrusion on Monday at 09:00 CET. The GDPR 72-hour clock starts then, so the data protection notice is due by Thursday at 09:00. Classification as a major ICT incident is completed on Monday at 15:00, which starts the DORA clock, so the initial report is due within 4 hours, and no later than 24 hours after awareness. The team should prepare the DORA initial report and the GDPR notice in parallel from the first hour, because the DORA deadline is measured from classification while the GDPR deadline is measured from awareness.

Where DORA and GDPR work overlaps in practice

DORA and the GDPR apply to the same firm at the same time, and several of their obligations touch the same events, contracts and data. The cards below mark where those obligations meet, so teams can plan one evidence trail where the rules allow it. No official DORA-to-GDPR mapping is supplied here, so confirm any control-level crosswalk with your supervisor and data protection officer.

Incident detection and classification

An ICT incident that also exposes personal data starts two separate clocks. DORA runs its own major-incident classification and reporting under Article 5(1) of the incident chapter, while the GDPR personal data breach process under Article 33(1) asks for notice to the supervisory authority within 72 hours of becoming aware. Check whether your detection tooling and triage runbook can flag both questions at the same time, and who decides whether the event is a personal data breach.

Provider contracts

DORA Article 30(2) and GDPR Article 28(3) both require written terms with an ICT or data service provider, but they cover different ground. DORA asks for incident assistance at no extra cost or a pre-set cost, while the GDPR asks for binding processor obligations. Map each contract clause to the regulation it satisfies, and confirm with legal counsel whether one agreement can carry both sets of terms without gaps.

Data location and return

Article 30(2) of DORA requires the contract to state where services are provided and data processed, with advance notice of location changes. It also requires data protection and data return on insolvency or termination. Read these alongside GDPR transfer rules in Chapter V. Ask providers for a current list of processing locations, the notice period they commit to, and the exit procedure they will follow.

Rights-request and notice deadlines

Readiness reviews should test the GDPR clocks that sit beside DORA's reporting windows. Under Article 12(3), a rights request must be acted on within one month, extendable by two months. Article 14 information is due within one month where data come from third parties. Run tabletop exercises that pair an incident with an open rights request, so teams see which deadline wins when staff are busy.

Information sharing under Article 45

DORA Article 45 allows financial entities to share cyber threat information within trusted communities, under arrangements that protect sensitive information and follow rules that respect the GDPR. Before joining or running such an exchange, confirm with your DPO what personal data may appear in shared indicators, how it is minimized, and how the exchange rules document their GDPR compliance. Treat the sharing rules as a control to review, not a blanket permission.

Article 30 DORA contract terms versus Article 28 GDPR processor terms

Article 30(2) of DORA sets out what a financial entity's contract with an ICT provider must contain. It covers operational and resilience terms, not only data handling. The clauses are aimed at making sure the entity knows where its ICT services run, can keep control of its data if the relationship ends, and gets help during an ICT incident without an open-ended bill.

Service locations: the contract must state the regions or places where services are provided and where data is processed, and it must require advance notice before those locations change.
Data protection: the provider must agree to protect the data it handles in line with the contract's terms.
Data return: the contract must cover how data is returned if the provider becomes insolvent, or if the agreement ends.
Incident assistance: the provider must help with ICT incidents either at no additional cost or at a cost fixed in advance.
Pricing clarity: the incident support fee should be stated in the contract so that it is not negotiated during a live incident.

When reviewing a draft, confirm with the provider how it will name each location, how it will notify you of changes, and whether the incident assistance cost is set in the contract or left to a later statement of work.

Who assesses each framework and what the assessment produces

This table compares who supervises DORA and the GDPR, and what each produces as proof of compliance. Read it to see that DORA is enforced by supervisors with no certification scheme, while GDPR certification under Article 42 is voluntary and lasts at most three years. Confirm national supervisory practice with your competent authority or data protection authority before setting review cycles.

Question	DORA	GDPR
Who supervises compliance	National competent authority for each financial entity type listed in Article 46, with the ECB for significant credit institutions	Independent national supervisory authorities (Article 51), with the EDPB issuing guidelines and resolving disputes through binding decisions
Oversight of critical providers	ESAs act as Lead Overseers for critical ICT third-party service providers (Articles 31 to 44)	No equivalent provider designation; processors are supervised through the controller and the supervisory authority
Certificate or attestation issued	No certification scheme; the only authority-issued attestation is that a threat-led penetration test met requirements (Article 26(7))	No mandatory audit, attestation or certificate; certification under Article 42 is voluntary
Duration of any recognition	Not applicable, since no certificate is issued	Article 42 certification is issued for at most three years and does not reduce controller or processor responsibility
Enforcement tools	Supervisory powers under Article 50; penalties set by member states, effective, proportionate and dissuasive	Inspections and investigations by supervisory authorities; fines up to EUR 10 million or 2% or EUR 20 million or 4% of turnover, whichever is higher
Supervisory review cycle	Not fixed in the Regulation as supplied; confirm the cycle and examination approach with your competent authority	Not fixed in the Regulation as supplied; confirm complaint and inspection practice with your national authority
What to show a supervisor	Documented ICT risk framework, incident records and reports, register of information and testing evidence	Records of processing, breach register, processor contracts and evidence of security measures under Article 32

How penalties differ and what drives exposure

DORA and the GDPR both carry administrative penalties, but they are set in different places. DORA leaves the amounts to member states, while the GDPR fixes ceilings in the Regulation itself, so the two can apply to the same incident at once.

DORA penalties set nationally

Article 50(3) requires member states to lay down administrative penalties and remedial measures for DORA breaches that are effective, proportionate and dissuasive. DORA itself sets no EU-wide maximum or minimum fine for financial entities. Ask your national competent authority which penalties and remedial measures apply to your entity type, and whether your ICT incident reporting failures fall under the same regime as your ICT risk management failures.

GDPR fine ceilings

Article 83 sets two tiers of maximum administrative fines. The lower tier, EUR 10 million or 2% of total worldwide annual turnover, covers infringements such as Articles 25 to 39, which include security of processing and breach notification. The higher tier, EUR 20 million or 4%, covers breaches of core principles, lawful basis, data subject rights and transfer rules, whichever is higher in each case.

Role of national law

Because DORA amounts depend on national law, two financial entities with the same DORA failure can face different exposure depending on the member state that supervises them. The GDPR's fine ceilings apply uniformly, but the supervisory authority still decides the amount within them. Confirm with counsel how your home supervisor and each relevant data protection authority will treat a single incident that engages both regimes.

Incident handling quality

Late or incomplete reports are a practical source of exposure under both regimes. DORA's initial report is due within 4 hours of classifying an incident as major and no later than 24 hours after awareness, and the GDPR breach notice is due within 72 hours. Test whether your runbook can meet the earliest clock in each regime, and record the reasoning behind each classification decision, since supervisors will ask for it.

Ask for clarity before an incident

Neither regime lets you estimate exposure from the statute alone. Before an incident occurs, ask counsel and your supervisor to confirm how national penalties will be calibrated and whether any proposed single entry point would change who receives each report. Document the answers, because they shape which evidence you must keep ready for a supervisory review.

What the proposed single reporting entry point would change

The Commission's Digital Omnibus proposal of 19 November 2025 would create a single entry point for incident reports under NIS2, the GDPR, DORA and other laws, run by ENISA. For a financial entity, the practical point is that this is a proposal and not current law. The Commission says the proposal would not modify existing reporting obligations, so the DORA major ICT-related incident reports to the financial supervisor and the GDPR personal data breach notice to the data protection authority stay separate duties with their own clocks, recipients and content.

The proposal remains under procedure 2025/0360(COD) in the European Parliament Legislative Observatory, where the file is awaiting committee decision. Until a final text is adopted and applies, plan for two separate notification paths. Confirm with your competent authority and your data protection authority whether they have announced any interim arrangements, and check how your incident response runbook maps each DORA stage and the GDPR 72-hour notice to named owners. Track the procedure's status before changing templates or tooling, because a final text could alter formats or routing even if the underlying duties stay in place.

Reviewing the proposal's text when it is published will show whether the single entry point changes only the submission channel or also the content and timing of what you file. Ask legal counsel to compare any amended text against the current DORA and GDPR articles, and record each change in your incident reporting procedure. Until that review is complete, treat the existing deadlines as binding, since the proposal does not alter them.

Which to do first and how to share evidence

This sequence builds one data map, one incident runbook and one set of provider terms that serve both DORA and the GDPR, so a single incident or contract review produces evidence both regimes can use. Each step ends with a check you can show an examiner or a data protection authority.

Map processes that touch personal data and ICT services
Start with an inventory that crosses two lists: the business processes that process personal data (the GDPR records of processing) and the ICT systems and third-party services that support them (the DORA ICT asset and service inventory). Assign an owner for each entry, typically the process owner with input from ICT risk and the data protection officer. The step is done when every critical or important function shows both its ICT dependencies and its personal data categories, and gaps are logged with owners. Confirm with your data protection officer whether your processing records already cover the ICT services in scope.
Build the incident classification and two-clock runbook
Write one incident procedure that classifies each ICT-related incident and then decides which clocks start. DORA's major incident clock runs in stages: an initial notification within 4 hours of classification as major and no later than 24 hours after awareness, an intermediate report within 72 hours of the initial notification, and a final report no later than one month after the latest intermediate report. The GDPR clock for a personal data breach is 72 hours from becoming aware, and it runs separately. The runbook names the trigger for each clock, the recipient, and the owner of each filing. It is done when a tabletop exercise walks one mixed incident through both clocks and the timeline record is complete.
Align provider contracts with Article 30 and Article 28
Review each ICT service contract against DORA Article 30(2) and GDPR Article 28(3). The DORA side covers stated service and data locations, advance notice of location changes, data protection and return on insolvency or termination, and provider assistance with ICT incidents at no additional cost or a cost agreed in advance. The GDPR side covers a binding written processor contract. Where a provider supports both regimes, one addendum can carry both sets of terms. Keep the signed terms and a gap list in your provider register, which also supports the DORA register of information. The step is done when every in-scope provider has either compliant terms or a dated remediation item with an owner.
Test rights-request and breach notice deadlines
Run readiness tests on the GDPR deadlines that the incident and contract work depends on. Test whether data subject rights requests can be acted on within one month, extendable by two months under Article 12(3), and whether a notifiable breach can reach the supervisory authority within 72 hours under Article 33(1). Test Article 14 information duties for data received from third parties within one month. Use a simulated request and a simulated breach, and record who received each task, when it was done, and where the evidence was stored. The step is done when each test produces a timestamped record and any missed step has a corrective action.
Share evidence across both regimes
Keep one evidence set that both regimes can draw on. Incident logs, timeline records and classification decisions support DORA reports and GDPR breach files. The provider register and signed contract terms support DORA Article 30 reviews and GDPR Article 28 accountability. Store each item once, tag it by regime and article, and restrict access to the people named in the runbook. Where a report to one authority includes information already filed with another, record which filing used which version. Confirm with counsel which items can be shared with each authority and under what confidentiality terms. The step is done when an auditor or supervisor can trace one incident from classification to each filing from a single index.
Prepare evidence for supervisors and assessors
Assemble the evidence pack for each supervisor and for any independent assessor you engage. Neither DORA nor the GDPR provides a certificate of compliance: DORA competent authorities supervise through their Article 50 powers, and a GDPR certification under Article 42 is voluntary and does not reduce your responsibility. DeployOpen can prepare the systems, controls and evidence for these reviews, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles. The step is done when the pack is indexed, dated, and reviewed by the compliance lead and the data protection officer.
Track the proposed single entry point
Assign one owner to monitor the Commission's Digital Omnibus proposal of 19 November 2025, which would create an ENISA-run single entry point for incident reports under NIS2, the GDPR, DORA and other laws. The Commission states that it would not change existing reporting obligations, and the proposal remains under review. Until it is adopted, your runbook continues to use the separate DORA and GDPR clocks. Record the procedure status at each quarterly compliance review and update the runbook only after the legal text is final. The step is done when the owner has a dated status note and a decision on whether the runbook needs a change.

What buyers ask before they hire help with DORA and GDPR

What does DORA and GDPR implementation help cost, and what drives the price up?

The fee depends on the written scope, not on a standard rate, and DeployOpen does not publish a price list. Most engagements are fixed-scope, so the quote follows from the agreed deliverables. The main drivers are the number of ICT services and providers in scope, how many incident paths must be built for DORA reporting and GDPR breach notice, whether the work reuses existing logging and ticketing tools, and how much policy and evidence documentation must be written from scratch. Ask for the quote to list each deliverable separately, to state which items are one-time (gap analysis, contract review, playbooks) and which recur (retainers for upgrades, testing and ongoing support), and to name any third-party costs such as licences or assessor fees that DeployOpen does not control.

How long does DORA and GDPR readiness take?

Duration depends on scope, and no fixed figure applies to every organization. The biggest variables are how many ICT third-party contracts need DORA Article 30 terms and GDPR Article 28 terms added, how mature the current incident process is, and whether the team must agree one playbook that covers DORA's initial, intermediate and final reports alongside the 72-hour GDPR notice. Organizations that already keep a register of ICT services and tested incident runbooks usually have less to build. Ask any provider to put a timeline in the written scope, with the dependencies on your legal, procurement and data protection teams stated, and to show which milestones depend on supervisor or DPO decisions outside the project.

What must our team provide before an engagement starts?

The client supplies the people and the records that the work cannot create alone. Expect to name process owners for ICT risk, incident management, third-party risk and personal data breach response. Provide the current provider contracts and any data processing agreements so that gaps against DORA Article 30(2) and GDPR Article 28(3) can be checked clause by clause. Give access to logs and incident tickets from recent events so that classification and reporting paths can be tested against real records. The Data Protection Officer must be involved early and have a clear decision role in breach notices. Confirm these commitments in the written scope, because delays in any of them move the timeline.

Can we do DORA and GDPR work in-house without an outside partner?

Yes, an in-house team can do this work if it has staff who understand DORA's ICT risk, incident and third-party chapters and the GDPR's controller and processor duties, and who can write and test procedures. The harder part is usually independent testing and keeping the evidence current, not writing the first policy. Outside help adds experienced reviewers for contract gaps, a second view on incident classification, support running tabletop or technical tests, and documentation prepared to be checked by supervisors and auditors. DeployOpen plans, implements, documents and supports these controls inside your own environment, but the decisions on legal interpretation, risk acceptance and supervisory dialogue stay with your organization and its counsel.

Does DORA or GDPR compliance produce a certificate?

No. Neither regulation issues a certificate of compliance. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary, lasts at most three years and does not reduce the controller's or processor's responsibility. DORA sets no certification scheme: national competent authorities supervise compliance, and the only authority-issued attestation the Regulation provides for is the one confirming that a threat-led penetration test met the requirements under Article 26(7). In practice, evidence looks like a register of ICT services, signed contracts with the required clauses, incident logs with classification records, test reports, and records of decisions. DeployOpen prepares that evidence but does not issue audit reports, attestations or certifications.

How will the proposed single reporting entry point change our planning?

The Commission's Digital Omnibus proposal of 19 November 2025 would create an ENISA-run single entry point for incident reports under NIS2, GDPR, DORA and other laws. It remains a proposal and has not been adopted, and the Commission states that it would not modify existing reporting obligations. Until a legal act changes the position, plan for separate DORA reports to the financial supervisor and separate GDPR notices to the data protection authority, each with its own clock and content. Design the incident workflow so the same facts feed both, and assign an owner to track the Digital Omnibus procedure. Ask any provider how its playbooks would be adjusted if the entry point is adopted, and whether that adjustment is covered by the current scope or a later change.

How DeployOpen scopes readiness for DORA and GDPR

DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For DORA and GDPR readiness, we work from a written scope that separates ICT risk, incident reporting and provider contract controls from personal data processing controls, so each regulator's evidence is traceable.

How we scope

Agree in writing which DORA incident stages, provider contract terms and GDPR breach and processor controls the engagement covers
Map which systems in your estate carry ICT services, personal data or both, and record the owner of each
Confirm with your own legal and compliance teams which national competent authority and data protection authority apply to you

How we build

Configure logging and incident workflows so the timing for each DORA report and the 72-hour GDPR notice can be tested
Add the records a supervisor or data protection authority may ask for, such as processing records and provider register entries
Test the controls we build against the scope, and report gaps as written findings for your remediation decisions

How we hand over

Deliver runbooks, configuration documentation and evidence packs that your staff can operate without DeployOpen present
Document the decisions made during the build, including where the two regimes overlap and where they differ
Brief your incident, legal and compliance owners on the handover so the notification steps are clear before go-live

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer, priced from the written scope
Note that DeployOpen prepares systems and evidence for assessment but does not issue audit reports or certifications