Maintaining Breach Documentation Records

Maintaining Breach Documentation Records

Overview

Article 33(5) of the GDPR requires every controller to document all personal data breaches, regardless of whether the breach triggered supervisory authority notification. The documentation must include "the facts relating to the personal data breach, its effects and the remedial action taken" and must "enable the supervisory authority to verify compliance with this Article." This creates a comprehensive breach register that serves as a primary accountability document under Art. 5(2).

Mandatory Documentation Requirements — Art. 33(5)

Facts Relating to the Breach

Every breach register entry must document:

Effects of the Breach

Remedial Actions Taken

Notification Decision Documentation

Every breach entry must also record the notification decision and rationale:

Register Structure and Maintenance

Single Centralized Register

All breaches must be recorded in a single centralized register maintained by the DPO's office. Stellar Payments Group uses a dedicated module in the OneTrust Privacy Management Platform with the following access controls:

• Write access: DPO, Deputy DPO, Privacy Incident Coordinator
• Read access: CISO, General Counsel, Internal Audit, Board Audit Committee
• No access: Business unit managers, IT operations staff (access to individual breach records provided on a need-to-know basis via separate reports)

All Breaches Documented — Including Non-Notifiable

The register must include every personal data breach, regardless of severity or whether SA/DS notification was triggered. This explicitly includes:

• Misdirected emails containing personal data (even single-recipient incidents)
• Temporary availability breaches resolved from backup
• Unsuccessful exfiltration attempts where personal data was targeted but not accessed
• Breaches at processors that affected the controller's data
• Physical breaches (lost devices, unauthorized office access)

Retention Period

Breach register entries are retained for a minimum of 7 years from the date of breach closure. This accounts for:

• The 5-year statute of limitations for GDPR enforcement actions in most EU member states
• The need to demonstrate patterns (or absence of patterns) to supervisory authorities
• Litigation time limits for data subject compensation claims under Art. 82

After the 7-year retention period, entries are anonymized (data subject counts retained, specific identifiers removed) and maintained indefinitely for trend analysis.

Audit Readiness

Supervisory Authority Access — Art. 33(5)

The breach register must be available to the supervisory authority "on request." Audit readiness requires:

1. Instant availability: The register must be exportable in a structured format (CSV, JSON, PDF) within 24 hours of a supervisory authority request.
2. Completeness verification: Monthly self-audit to verify all reported security incidents were assessed for personal data impact and, where applicable, added to the register.
3. Cross-reference integrity: Each register entry must link to supporting documentation (risk assessment form, SA notification copy, DS notification copy, investigation report, remediation evidence).
4. Trend reporting: The register must support generation of trend reports showing: breach frequency over time, breach types, root cause categories, notification rates, and remediation completion rates.

Annual Breach Register Review

The DPO conducts an annual review of the breach register covering:

1. Completeness: Are all known breaches documented? Cross-reference against the security incident management system.
2. Accuracy: Sample 20% of entries and verify accuracy against source documentation.
3. Timeliness: Were entries created within 72 hours of breach discovery?
4. Remediation closure: Are remediation actions tracked to completion? Flag overdue actions.
5. Pattern identification: Are there recurring breach types or root causes indicating systemic issues?
6. Board reporting: Prepare an annual breach summary report for the Board Audit Committee.

Integration with Other Records

Common Documentation Deficiencies

1. Breaches documented in security incident systems but not in the Art. 33(5) register: The security incident ticket is not a substitute for the breach register entry.
2. Missing notification decision rationale: Recording "not notified" without documenting why the breach was assessed as unlikely to result in risk.
3. Incomplete remediation tracking: Remedial actions listed but never updated to reflect completion status.
4. Delayed documentation: Entries created weeks after the breach, making it difficult to demonstrate timely awareness and response.
5. No processor breach entries: Breaches that occur at processors but affect the controller's data are not recorded in the controller's register.