GDPR breach assessment and DORA incident reporting: where the workflows intersect

One event can create two regulatory workflows

An outage, malicious intrusion or data-loss event can be relevant to both digital operational resilience and personal-data protection. DORA asks an in-scope financial entity to manage and classify ICT-related incidents and report those classified as major. GDPR requires a controller to assess a personal data breach and, unless the breach is unlikely to result in a risk to people’s rights and freedoms, notify the competent supervisory authority without undue delay and where feasible within 72 hours after awareness. These are related facts but separate decisions.

The operating mistake is usually one of two extremes. Teams either create isolated cases and repeatedly reconcile the same incident facts, or they force both frameworks into one status and lose the different reasoning. A better design uses one operational incident as shared context, then opens distinct DORA and GDPR assessments with their own scope, criteria, deadlines, decision owners, submissions and audit history.

Establish the shared factual record

Shared facts can include when the event was detected, when the organisation became aware, systems and services affected, data confidentiality, integrity or availability impacts, geographic reach, third-party involvement, containment, recovery and current uncertainty. Those facts should be versioned because early estimates frequently change. Each regulatory assessment should reference the same fact version or record which facts were used, preventing later updates from obscuring the basis of an earlier decision.

• Incident identity, detection source and awareness timeline
• Affected services, systems, providers and business processes
• Known or suspected personal-data categories and data-subject groups
• Operational impact, duration, geography and recovery status
• Containment actions, investigation evidence and remaining uncertainty

Run the GDPR assessment on its own legal test

GDPR Article 4 defines a personal data breach in terms of a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. Article 33 governs notification to the supervisory authority, while Article 34 addresses communication to affected data subjects where the breach is likely to result in a high risk, subject to the regulation’s conditions. The assessment therefore needs privacy-specific facts and a reasoned evaluation of risk to natural persons, not only operational severity.

The European Data Protection Board’s breach-notification guidance provides additional interpretive support. Operational records should capture whether personal data was involved, the type of breach, categories and approximate numbers where available, likely consequences, measures taken or proposed, the notification decision and reasons for any delay. Even where notification is not required, Article 33(5) requires controllers to document personal data breaches so that the supervisory authority can verify compliance.

Run the DORA classification against DORA criteria

DORA classification examines criteria specified in Article 18 and Commission Delegated Regulation (EU) 2024/1772, including the relevance of clients or financial counterparts affected, duration and service downtime, geographical spread, data losses, critical services affected and economic impact. A privacy breach can contribute facts to those criteria, but the existence of personal data does not by itself decide whether the ICT-related incident is major under DORA. Equally, a DORA major classification does not automatically decide the GDPR risk test.

Once the incident is classified as major, the DORA reporting stages and time limits apply under the relevant acts. The operational record should calculate those deadlines independently from the GDPR 72-hour period. Both may use an awareness timestamp, but the DORA initial-report timing also relates to the time of classification as major. Preserving both the awareness and classification events avoids treating the clocks as interchangeable.

Coordinate without creating a single approval

A coordinated response can share an incident commander, investigation workstream and evidence room while routing regulatory decisions to the appropriate authorities inside the organisation. Privacy, security, operational resilience, legal, communications and business teams may all contribute. The system should show who owns each contribution and who is authorised to approve each external notification. A joint meeting can support coordination; it should not erase the separate rationale and sign-off.

Submission content also requires controlled reuse. Facts such as service duration or containment action can be referenced across reports after validation. Audience-specific fields, legal reasoning and personal-data details should remain appropriately scoped. This reduces inconsistency while preventing a broad operational audience from receiving privacy information solely because the same event also has a DORA case.

An illustrative dual-assessment record

Illustrative incident INC-204 records an unauthorised access event and payment-service disruption. Privacy assessment PBA-031 identifies affected personal-data categories, evaluates risk to individuals and records decision GDPR-DEC-09. DORA classification CLS-204-03 evaluates operational impact and records decision DORA-DEC-12. Each decision opens its own reporting task and deadline. Shared evidence EVD-019 supports the factual timeline, while access restrictions keep privacy-specific material within the authorised team. These identifiers are representative product data, not a real incident or customer outcome.

The resulting history can answer both common and framework-specific questions. Investigators can see the incident facts and changes once. The data protection officer can review the Article 33 reasoning and breach documentation. Operational-resilience owners can inspect the DORA classification and report stages. Management can see outstanding actions without assuming the two notifications have the same status. Auditors can identify which person approved each conclusion and which evidence version supported it.

Design controls before the next incident

1. Define one intake path that can identify operational and personal-data relevance.
2. Maintain separate DORA and GDPR assessment templates with current source references.
3. Assign decision authority and deputies before reporting clocks start.
4. Test deadline calculations, late-classification scenarios and unavailable information.
5. Restrict privacy facts while sharing validated operational facts deliberately.
6. Run exercises through submission, receipt, remediation and closure—not only detection.

Connect incident learning to processing records, security and DPIAs

An incident can reveal that a record of processing activities is incomplete, a technical or organisational measure is not operating as expected, or a data protection impact assessment no longer reflects the actual risk. GDPR Articles 30, 32 and 35 provide distinct obligations around processing records, security of processing and DPIAs. The post-incident workflow should be able to link the breach assessment to those records and assign review, while preserving the fact that an incident does not automatically prove every connected control or DPIA inadequate.

For example, a newly identified data recipient may require the processing record to be reviewed; a failed restoration process may require review of the Article 32 measures; a material change in processing or risk may prompt the privacy team to reassess the DPIA. Each resulting action needs an owner and closure decision. Connecting the records helps avoid losing lessons learned after notification, but the authorised privacy practitioner must decide the correct response for the organisation’s circumstances.

Management reporting should distinguish operational recovery, regulatory notification and remediation. An incident may be technically resolved while a final DORA report, GDPR documentation or longer-term control action remains open. A single green status can therefore be misleading. Separate but connected states let leaders see the remaining obligations without asking teams to merge different tests, deadlines or accountabilities into one oversimplified outcome.