This workflow is relevant when a suspected security incident may involve personal data and the organization needs to decide whether Article 33 or Article 34 notification is required.
The workflow covers detection, triage, the awareness clock, controller and processor roles, authority notification, data subject communication, evidence, and post-incident records.
Structured answer sets in this page tree.
Cited legal and guidance references.
This EU GDPR workflow turns a suspected into a documented Article 33 and Article 34 decision. It starts with breach recognition and containment, then records when the controller became aware, the risk assessment, role handoffs, notification content, communication to affected people when required, and the final breach file.
Open the workflow when monitoring, support, a processor, a third party, a user report, or an internal team flags an incident that may involve personal data. The first triage question is not whether the incident is embarrassing or severe; it is whether there has been a breach of security involving personal data.
Classify the event as a suspected confidentiality, integrity, availability, or combined breach. GDPR Article 4(12) covers accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The EDPB also distinguishes personal data breaches from security incidents that do not involve personal data.
Representative examples include a customer file sent to the wrong recipient as a confidentiality breach, unauthorised alteration of account or health information as an integrity breach, and permanent loss or a ransomware outage that makes personal data unavailable as an availability breach. A temporary outage can still be a breach when the lack of access can harm people. Classification and notification still depend on the actual facts, protections, recovery time, and likely consequences.
Record the point when the controller has a reasonable degree of certainty that a security incident has occurred and personal data has been compromised. That is the awareness point for the Article 33 notification clock. A short initial investigation can happen before awareness, but it should begin as soon as possible and should not become an open-ended forensic delay.
If a processor discovers a while processing on behalf of a controller, the processor notifies the controller without undue delay. The controller then assesses risk and decides whether to notify the supervisory authority or affected data subjects. Joint controllers should already have an arrangement that allocates who leads Article 33 and Article 34 duties.
The authority notification threshold and the data subject communication threshold are different. Notify the competent supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Communicate to affected data subjects when the breach is likely to result in a high risk to their rights and freedoms.
Assess the real breach facts, not only the generic DPIA scenario. Consider the breach type, sensitivity and volume of data, ease of identifying people, severity and permanence of consequences, affected vulnerable groups, the controller's context, number of affected people, encryption or other protections, backup availability, and whether the data is now in the hands of an unknown or malicious actor.
When the breach is likely to result in high risk, communicate to affected data subjects without undue delay. The communication should be dedicated to the breach, clear, plain, and practical. It should not be hidden inside a newsletter, general product update, or generic security statement.
The communication should describe the nature of the breach, provide the DPO or other contact point, describe likely consequences, and explain measures taken or proposed to address the breach and mitigate adverse effects. Choose channels that are likely to reach affected people and avoid using a channel that was itself compromised by the breach.
Article 34(3) removes the direct-communication duty only if effective technical or organisational protection made the affected data unintelligible to unauthorised people, later measures ensure the high risk is no longer likely to materialise, or individual contact would involve disproportionate effort and an equally effective public communication or similar measure is used. Record the facts supporting the exception. A supervisory authority may still require communication if it considers the Article 34 conditions met.
Close the workflow only after the breach record explains the facts, effects, remedial action, notification decisions, and reassessment triggers. GDPR Article 33(5) requires controllers to document personal data breaches so the supervisory authority can verify compliance with Article 33.
The post-incident review should not rewrite the notification decision to fit the final root cause. Preserve the timeline from first alert through awareness, risk assessment, notification, data subject communication, containment, recovery, and corrective actions. If later facts change the risk assessment, update the record and any authority or data subject follow-up.
Sorena can help turn a suspected personal data breach into cited decisions, owner assignments, notification drafts, evidence requests, and reusable post-incident records.
Ask questions tied to cited sources about Article 33, Article 34, controller and processor roles, awareness timing, and breach records using the cited sources on this page.
Review your breach triage, notification thresholds, authority routing, data subject communication, evidence gaps, and post-incident workflow with Sorena.
"notify the lead DPA or, at a minimum, the local DPA"
"data breach notification obligation"
"document its reasoning for the decisions taken"
"Security of Personal Data Processing"
"document any personal data breaches"