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. Soon's standard commitment: without undue delay after becoming aware of a personal-data breach, and in any event within 48 hours. The GDPR sets no fixed deadline for a processor (Art. 33(2) says only "without undue delay"), but the controller has 72 hours from becoming aware, so a processor commitment has to leave them usable runway. 48 hours from awareness leaves the controller a full day and is a window a team of Soon's size can actually meet; 72 would leave them none. Contractual exceptions override the standard. Some customer agreements commit Soon to a shorter window — the GXO Logistics data processing agreement (signed 2026-08-30) requires notice within 24 hours of becoming aware. Check the customer's contract in Drive → Legal at the start of any incident; the shortest applicable window governs.

The clock starts on awareness, which under Article 33 and the EDPB guidance means having a reasonable degree of certainty that a security incident has occurred leading to personal data being compromised — not the completion of a forensic investigation or a risk assessment. Notify on what is known and update as more emerges; do not hold the notice back to make it complete. This wording was corrected on 2026-09-09: the previous version started the clock on confirmation, which invited exactly the delay Article 33 is written to prevent.

TODO(owner): this is the standard to offer going forward. Check it against already-signed customer DPAs — the GXO agreement in particular — because a signed contract promising something shorter binds for that customer and must be recorded here as an exception.

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). The breach register is held in Linear, consistent with incident records generally (Records Retention Policy §3), restricted to the founders. Owner: Olaf Jacobson (ISM). Deliberately not this repository, which is not an appropriate place for personal data.

6. Roles

  • Privacy Owner (Olaf Jacobson) — accountable; assesses, notifies customers, maintains the register.
  • Technical Lead (Thomas) — establishes scope/facts of the breach.
  • Olaf Jacobson (ISM) — 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.