GDPR Articles 33 & 34

Breach Notification, Communication, and Operationalisation — A Scholarly Analysis

Data Protection LawCompliance Framework

Thesis: A Risk-Calibrated Breach Governance Regime

The Core Framework

GDPR Articles 33 and 34 create a risk-calibrated breach governance regime. The duties are not triggered by every security incident, but by a "personal data breach" — a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

Two Distinct Obligations

Article 33

Notification to the supervisory authority

Article 34

Communication to affected data subjects

Each article carries distinct thresholds, timelines, and content requirements — together forming a coherent accountability architecture.

Article 33: Notification to the Supervisory Authority

1

72-Hour Deadline

The controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach — unless the breach is unlikely to result in a risk to natural persons' rights and freedoms. Late notification must include reasons for delay.

2

Processor Duty

A processor must notify the controller without undue delay after becoming aware of a breach. This is not the same as the controller's 72-hour regulatory deadline, but processor delay can imperil the controller's compliance.

3

Documentation

Article 33 requires documentation of all personal data breaches — including facts, effects, and remedial action — enabling supervisory authority verification.

Required Notification Content (where possible)

Nature of Breach

Type and circumstances of the security incident

Affected Subjects & Records

Categories and approximate numbers of both data subjects and personal data records

DPO / Contact Details

Data Protection Officer or designated contact-point information

Likely Consequences

Probable effects of the breach on individuals and the organisation

Measures Taken

Steps taken or proposed to address the breach and mitigate adverse effects

Article 34: Communication to Data Subjects

When It Applies

Article 34 applies where the breach is likely to result in a high risk to natural persons' rights and freedoms. Communication must be made without undue delay and in clear and plain language.

Required Communication Content

  • The nature of the breach
  • DPO or contact-point details
  • Likely consequences of the breach
  • Measures taken or proposed to address the breach

Exemptions: When Communication Is Unnecessary

Effective Encryption

The controller implemented appropriate technical and organisational protection measures — such as encryption — rendering the data unintelligible to unauthorised persons.

Subsequent Mitigation

The controller took subsequent measures ensuring the high risk is no longer likely to materialise.

Disproportionate Effort

Direct communication would involve disproportionate effort — in which case public communication or similarly effective measures are required.

Examples: When Notification Is Appropriate

🏥 Ransomware Encrypting Patient Records

Ransomware encrypts patient records and exfiltration is suspected. Article 33 notification is likely because health data, confidentiality risk, and availability loss may affect rights and freedoms. Article 34 may also apply if high risk exists.

💼 Payroll Spreadsheet Emailed Externally

A payroll spreadsheet containing salary, bank details, national identifiers, or disciplinary information is emailed to an external recipient. Article 33 is likely; Article 34 may be required if financial fraud, embarrassment, discrimination, or identity misuse is plausible.

☁️ Customer Database Copied from Misconfigured Cloud Bucket

A customer database is copied from a misconfigured cloud storage bucket. Article 33 is likely; Article 34 depends on data sensitivity, exploitability, affected population, and mitigation measures taken.

Examples: When Notification May Not Be Appropriate

🔒 Encrypted Laptop Lost

Encrypted laptop lost, with strong encryption, secure key management, and no evidence of key compromise. Article 33 may be unnecessary if risk is unlikely; Article 34 is generally unnecessary if data is unintelligible.

📧 Email to Trusted Unintended Recipient

Email sent to a trusted unintended recipient who confirms deletion and did not access or disclose sensitive content. Notification may be unnecessary, depending on evidence and context.

⏱️ Temporary Unavailability Restored from Backups

Temporary unavailability of non-critical personal data restored from backups with no adverse impact. Article 33 may be unnecessary if rights-and-freedoms risk is unlikely.

GDPR Articles Intersecting with Articles 33 & 34

A comprehensive understanding of breach notification requires familiarity with the broader GDPR framework. The following articles intersect directly with Articles 33 and 34.

Governance & Security

  • Article 24: Controller responsibility and governance
  • Article 25: Data protection by design and by default
  • Article 28: Processor contracts and breach notification duties
  • Article 30: Records of processing activities
  • Article 32: Security of processing — confidentiality, integrity, availability, resilience, restoration, and testing
  • Articles 35–36: DPIAs and prior consultation
  • Articles 37–39: DPO designation, independence, and tasks

Enforcement & Liability

  • Articles 44–49: International transfers implicated by cross-border incidents
  • Articles 55–56: Competent and lead supervisory authority
  • Articles 58 & 83: Corrective powers and administrative fines
  • Article 82: Compensation and liability
  • Articles 9 & 10: Special category and criminal offence data — increasing risk severity
  • Articles 15–22: Data subject rights, which may be impaired by breach effects

Twenty Cross-Cutting Technical Controls

Effective operationalisation of Articles 33 and 34 demands a robust set of technical and organisational controls spanning policy, detection, protection, and assurance.

01

Enterprise Breach Response Policy

Mapped explicitly to Articles 33 and 34 obligations

02

24/7 Incident Intake & Triage

Always-on mechanism for receiving and classifying incidents

03

Legal Hold & Forensic Preservation

Procedures to preserve evidence integrity from the outset

04

Processor Breach-Notification Clauses

Contractual provisions with strict timelines for processor reporting

05

Central Breach Register

Satisfying Article 33(5) documentation requirements

06

Risk Assessment Methodology

Structured approach to rights-and-freedoms impact evaluation

Data Classification & Tagging

Sensitivity labelling across all data assets

Encryption at Rest & in Transit

With strong key management practices

IAM & Least Privilege

Identity and access management with minimal access rights

PAM & Session Recording

Privileged access management with full audit trails

SIEM with Alert Enrichment

Security information and event management

DLP Controls

For email, endpoints, SaaS, and cloud environments

Cloud Security Posture Mgmt

Continuous misconfiguration detection

EDR

Endpoint detection and response capabilities

Vulnerability & Patch Mgmt

Systematic identification and remediation of weaknesses

Backup, Restoration & Resilience

Tested recovery capabilities

Immutable Audit Logging

Tamper-proof records of all system activity

Automated Asset & Data Discovery

Continuous inventory of data assets and processing activities

Communication Templates

Pre-approved templates for regulators and data subjects

Post-Incident Corrective Tracking

Remediation tracking and assurance testing to closure

Operationalising Articles 33 & 34: Identification & Triage

Large organisations operationalise breach governance through a structured, multi-stage operating model. The first two stages — identification and initial triage — are critical to starting the Article 33 clock correctly.

Detection Channels

SOC, DLP, cloud misconfiguration, IAM anomaly, and endpoint alerts

User reports, vendor notifications, and customer complaints

Whistleblowing channels and internal audit findings

Penetration tests and regulatory correspondence

Breach Intake Mandatory Fields

  • Date and time detected
  • Reporting source
  • System or process affected
  • Data categories and suspected data subjects
  • Geography and processor/controller role
  • Immediate containment steps taken

Initial Triage Classification

Non-Security Event

No further breach process required

Security Incident

No personal data involved — log and monitor

Personal Data Breach

Confirmed — Article 33 clock starts immediately

Potential Breach

Pending investigation — preserve evidence and escalate

Operationalising: Containment, Escalation & Assessment

Containment

Disable accounts, revoke tokens, isolate endpoints, remove public access, suspend workflows, preserve logs, freeze evidence, notify processors

Legal & Governance Escalation

Notify privacy legal, DPO, CISO, incident commander, communications, risk, and business owner. Determine controller role and lead supervisory authority

Assessment

Determine breach type, assess affected data and people, evaluate likely consequences, and identify mitigating factors

Breach Types

Confidentiality

Unauthorised disclosure or access

Integrity

Unauthorised alteration of data

Availability

Accidental or unlawful destruction or loss

Mixed

Combination of two or more breach types

Mitigating Factors to Assess

  • Encryption, tokenisation, or pseudonymisation
  • Rapid deletion by recipient
  • No evidence of access
  • Limited data fields or short exposure window
  • Strong access logs and backups restored quickly

Likely Consequences to Assess

  • Identity theft, fraud, physical harm, or distress
  • Reputational damage, discrimination, or loss of control
  • Service denial or professional disadvantage

Article 33 & 34 Decisions and Exclusion Rationale

Article 33 Decision Framework

Notify Unless Risk Is Unlikely

Submit initial notification if facts are incomplete; follow with phased updates as the investigation progresses.

Record All Decisions

Document reasons for any decision not to notify, and reasons for any notification beyond 72 hours.

Article 34 Decision Framework

Communicate Where High Risk Is Likely

Avoid communication only where a recognised exemption applies: effective encryption, subsequent mitigation, or disproportionate effort.

Disproportionate Effort Assessment

Consider whether contact details are unavailable, the number affected, and cost — but do not treat cost alone as decisive. Use public notices, account banners, or in-product messaging where direct notice is disproportionate.

Grounds for Excluding Notification or Communication

No personal data involved, or no breach of security

Risk to rights and freedoms is unlikely

Data was strongly encrypted and keys were not compromised

Data was anonymised

Recipient was trusted, bound by confidentiality, and confirmed deletion

Exposure was internal, access-controlled, logged, and not misused

Availability loss had no material rights-and-freedoms impact

Subsequent mitigation removed likely high risk before individual notification became necessary

Completion, Closure & Compliance Monitoring

Completion Checklist

  • Submit final regulatory update
  • Complete data subject notifications
  • Close containment actions
  • Complete root-cause analysis
  • Update breach register
  • Update ROPA, DPIA, vendor risk file, and security risk register
  • Track remediation to closure
  • Present lessons learned to governance committees

Ongoing Compliance Monitoring

SLA & Timeliness

Monitor 72-hour SLA compliance and processor notification timeliness

Accuracy & Severity

Monitor accuracy of breach severity scoring and overdue remediation

Repeat Incidents

Monitor repeat incidents and unreported near misses

Testing & Audit

Sample test non-notification decisions, run breach simulations, and audit evidence quality

Board Reporting

Report metrics to the board or risk committee regularly

Key Artefacts & Automating ROPA Population

Key Artefacts Supporting ROPA

System inventory, application catalogue, and data discovery scans

Data classification labels, data flow maps, and API catalogues

Vendor inventory, processor and sub-processor register, and contract lifecycle records

DPIAs, legitimate interest assessments, and transfer impact assessments

Cloud asset inventories, IAM role maps, and logging schemas

Retention schedules, business process maps, data lineage metadata, security incident records, and privacy notices

Automation Approaches

Use data discovery tools to scan databases, SaaS platforms, object stores, and file shares; map fields to GDPR categories

Connect CMDB records and integrate procurement systems to identify processors and link contract metadata to Article 28 obligations

Pull cloud metadata from AWS, Azure, and Google Cloud; use API gateways to infer data flows

Use IAM data for internal recipient categories and DLP telemetry to detect actual data movement

Use ticketing workflows to trigger ROPA updates after new systems or vendors go live

Use DPIA tools, retention tooling, transfer assessment tools, and business capability maps to populate remaining ROPA fields

Breach Identification Sources

Conclusion

Articles 33 and 34 are not merely notification rules; they are accountability mechanisms. Advanced compliance requires an integrated operating model combining legal judgement, security telemetry, processor governance, data mapping, risk assessment, communications discipline, and auditable evidence.

Legal Judgement

Risk-calibrated decisions on notification and communication thresholds

Security Telemetry

Continuous detection and evidence collection across all channels

Processor Governance

Contractual controls and timely notification from the supply chain

Data Mapping

Accurate ROPA and data flow records enabling rapid impact assessment

Auditable Evidence

Documented, repeatable decisions that withstand regulatory scrutiny

Datari Home