Skip to content

Personal Data Breach Notification Procedure

Purpose. Defines how Soon handles personal-data breaches under the GDPR (Art. 33/34) and ISO/IEC 27001:2022 A.5.34. It complements the Incident Response Procedure.

1. Soon's role: processor

Soon is a data processor acting on behalf of its customers (the controllers). This determines who notifies whom:

  • Soon → Customer (controller): Soon must notify the affected customer without undue delay after becoming aware of a personal-data breach (GDPR Art. 33(2)).
  • Customer (controller) → Supervisory authority: the controller notifies their data-protection authority, generally within 72 hours (Art. 33(1)).
  • Customer (controller) → Data subjects: where high risk, the controller notifies affected individuals (Art. 34). Soon supports the controller with information.

Soon does not normally notify the supervisory authority or data subjects directly, but must enable the controller to do so in time — so internal speed matters. TODO(owner): confirm specific notification timelines in customer DPAs.

2. What counts as a personal-data breach

A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Includes confidentiality (exposure), integrity (alteration) and availability (loss) breaches.

3. Procedure

  1. Identify — during incident response, the Privacy Owner determines whether personal data is (or may be) affected, and which customers' data.
  2. Assess risk — likely consequences for data subjects (severity, volume, data types, whether data was encrypted/pseudonymised).
  3. Notify the customer(s) without undue delay, with the information in §4.
  4. Support the controller's onward notifications (authority / data subjects).
  5. Record the breach in the breach register (§5), regardless of whether notification was required.
  6. Remediate & learn — corrective actions via the incident process and Nonconformity & Corrective Action.

4. Information to provide to the customer

  • Nature of the breach; categories and approximate number of data subjects and records.
  • Likely consequences.
  • Measures taken or proposed to address it and mitigate harm.
  • Contact point for more information (Privacy Owner).
  • Timeline of detection and containment.

5. Breach register (record-keeping, Art. 33(5))

All personal-data breaches are logged — date, description, data/subjects affected, risk assessment, customer(s) notified and when, controller's onward actions (if known), remediation. Held in a controlled, access-limited location (not this repo). TODO(owner): confirm register location/owner.

6. Roles

  • Privacy Owner (Olaf) — accountable; assesses, notifies customers, maintains the register.
  • Technical Lead (Thomas) — establishes scope/facts of the breach.
  • ISM (Olaf) — overall incident coordination.

Change log

Version Date Author Comments
0.1 2026-06-25 Andrea Cardinali / ISMS First draft — processor-role notification flow (Art. 33/34), breach register, roles. DPA-specific timelines and register location flagged TODO.