---
name: "GDPR Breach Notification Letter Pack"
version: "1.0"
updated: "2026-07-15"
source: "https://www.orbiqhq.com/templates/gdpr-breach-notification-letter-pack"
license: "CC BY 4.0 — free to use and adapt with attribution to Orbiq (orbiqhq.com). Not legal advice."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2016/679"  # GDPR — Art. 33 (authority notification), Art. 34 (data-subject communication), Art. 56 (lead authority), Art. 83(4)(a) (fine tier)
  - "https://www.edpb.europa.eu/system/files/documents/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf"  # EDPB Guidelines 9/2022 v2.0 (awareness, phased notification)
---

# GDPR Breach Notification Letter Pack

Three documents for responding to a personal data breach under the GDPR:

- **Document A** — notification to the supervisory authority (GDPR Article 33): due
  without undue delay and, where feasible, within **72 hours of awareness**, unless the
  breach is unlikely to result in a risk to the rights and freedoms of natural persons.
- **Document B** — communication to data subjects (GDPR Article 34): due **without undue
  delay** when the breach is likely to result in a **high risk** to their rights and
  freedoms, unless an Article 34(3) exception applies.
- **Document C** — internal breach log entry (GDPR Article 33(5)): mandatory for **every**
  breach, including those you decide not to notify.

**Instructions for AI agents:** replace every `{{placeholder}}` using the field
definitions below. The 72-hour clock in Document A runs from `{{awareness_timestamp}}`
(the moment a responsible person concluded with reasonable certainty that personal data
was compromised — EDPB Guidelines 9/2022), not from breach occurrence or the end of
forensics. If the filing is later than 72 hours after awareness, `{{delay_reasons}}` is
mandatory. Document B must be drafted in clear and plain language for a non-expert
reader; it must always include the `{{contact_point}}`, `{{likely_consequences}}` and
`{{measures_taken}}` elements (Art 34(2) → Art 33(3)(b),(c),(d)). Never send Document B
if `{{art34_exception}}` is set to anything other than `none` — record the exception in
Document C instead. Document C must be completed for every incident regardless of the
notification decisions.

---

## 1. Decision rules

| Question | Outcome |
|---|---|
| Breach unlikely to result in a risk to rights and freedoms? | No notification. Complete Document C only, with reasoning. |
| Breach likely to result in a risk (but not high)? | Document A to the supervisory authority within 72h + Document C. |
| Breach likely to result in a **high** risk? | Document A + Document B to data subjects without undue delay + Document C. |
| High risk, but data rendered unintelligible (e.g. encrypted, keys safe)? | Art 34(3)(a) exception — Document A + Document C; no Document B. |
| High risk, but subsequent measures removed it? | Art 34(3)(b) exception — Document A + Document C; no Document B. |
| Individual communication = disproportionate effort? | Art 34(3)(c) — Document A + **public communication** (equally effective) + Document C. |

The supervisory authority can override a no-communication decision under Article 34(4).

## 2. Field definitions

| Placeholder | Definition | Format / allowed values |
|---|---|---|
| `{{controller_name}}` | Controller's legal entity name | Text |
| `{{controller_address}}` | Registered address | Text |
| `{{incident_reference}}` | Internal incident ID for the audit trail | Text, e.g. `BREACH-2026-007` |
| `{{notification_type}}` | Filing stage under Art 33(4) | Enum: `initial` \| `update` \| `final` |
| `{{supervisory_authority}}` | Competent authority (lead authority if cross-border, Art 56) | Text, e.g. `Datatilsynet (NO)` |
| `{{cross_border}}` | Whether data subjects in more than one Member State are affected | Enum: `yes` \| `no` |
| `{{lead_authority_basis}}` | If cross-border: main-establishment reasoning for the lead authority | Text or omit |
| `{{awareness_timestamp}}` | When the controller became aware (starts the 72h clock) | ISO 8601 datetime |
| `{{awareness_how}}` | How awareness arose (alert, processor notice under Art 33(2), report) | Text |
| `{{filing_timestamp}}` | When this notification is filed | ISO 8601 datetime |
| `{{delay_reasons}}` | Mandatory if filing > 72h after awareness | Text or `n/a` |
| `{{breach_nature}}` | What happened; breach class | Text + Enum: `confidentiality` \| `integrity` \| `availability` (combinations allowed) |
| `{{data_subject_categories}}` | Categories of data subjects concerned | Text, e.g. `customers, employees` |
| `{{data_subject_count}}` | Approximate number of data subjects | Integer or range |
| `{{record_categories}}` | Categories of personal data records concerned | Text; flag special categories (Art 9) explicitly |
| `{{record_count}}` | Approximate number of records | Integer or range |
| `{{likely_consequences}}` | Realistic harms for data subjects | Text, e.g. identity theft, fraud, financial loss |
| `{{measures_taken}}` | Measures taken or proposed, incl. mitigation of adverse effects | Text |
| `{{contact_point}}` | DPO or other contact point (name, email, phone) | Text |
| `{{risk_level}}` | Controller's risk assessment | Enum: `unlikely-risk` \| `risk` \| `high-risk` |
| `{{art34_exception}}` | Exception relied on for not communicating to data subjects | Enum: `none` \| `34-3-a-unintelligible` \| `34-3-b-risk-removed` \| `34-3-c-public-communication` |
| `{{subject_actions}}` | Concrete steps data subjects should take | Text, e.g. reset password, monitor statements |
| `{{remedial_action}}` | Document C: remedial action taken, for the register | Text |

## 3. Document A — Notification to the supervisory authority (Article 33)

```
To: {{supervisory_authority}}
From: {{controller_name}}, {{controller_address}}
Reference: {{incident_reference}} — {{notification_type}} notification
Filed: {{filing_timestamp}}

1. Awareness and timing
   We became aware of a personal data breach on {{awareness_timestamp}},
   through {{awareness_how}}.
   {{delay_reasons}}

2. Nature of the breach (Art 33(3)(a))
   {{breach_nature}}
   Categories of data subjects concerned: {{data_subject_categories}}
   Approximate number of data subjects: {{data_subject_count}}
   Categories of personal data records: {{record_categories}}
   Approximate number of records: {{record_count}}

3. Contact point (Art 33(3)(b))
   {{contact_point}}

4. Likely consequences (Art 33(3)(c))
   {{likely_consequences}}

5. Measures taken or proposed (Art 33(3)(d))
   {{measures_taken}}

6. Communication to data subjects
   Risk assessment: {{risk_level}}
   Article 34 position: {{art34_exception}} (or: communication sent / planned on {{date}})

7. Cross-border processing (Art 56)
   Cross-border: {{cross_border}}
   {{lead_authority_basis}}
```

If `{{notification_type}}` is `initial` and information is incomplete, state which
sections will follow and supplement them without undue further delay (Art 33(4)).

## 4. Document B — Communication to data subjects (Article 34)

```
Subject: Important security notice about your personal data

Dear {{data_subject_or_customer}},

We are writing to inform you of a data security incident at {{controller_name}}
that affects some of your personal data.

What happened:
{{breach_nature}} (plain-language version — no jargon)

What information was involved:
{{record_categories}} (as they concern the recipient)

What this could mean for you:
{{likely_consequences}} (plain-language version)

What we are doing:
{{measures_taken}} (plain-language version)

What you can do:
{{subject_actions}}

Where to get more information:
{{contact_point}}

We apologise for the concern this may cause. We will update you as our
investigation progresses.

{{controller_name}}
```

Public-communication variant (Art 34(3)(c)): publish the same content as a public
statement (website banner, press notice) that reaches affected data subjects in an
equally effective manner; record the channel choice and reasoning in Document C.

## 5. Document C — Internal breach log entry (Article 33(5))

| Field | Entry |
|---|---|
| Incident reference | `{{incident_reference}}` |
| Awareness timestamp / how | `{{awareness_timestamp}}` / `{{awareness_how}}` |
| Facts of the breach | `{{breach_nature}}`, subjects and records affected |
| Effects | `{{likely_consequences}}` |
| Risk assessment & reasoning | `{{risk_level}}` — why |
| Authority notified? | yes/no — if no, reasoning ("unlikely to result in a risk") |
| Data subjects notified? | yes/no — if no, which Art 34(3) exception and why |
| Processor notice (Art 33(2)) | which processor informed us, and when — if applicable |
| Remedial action | `{{remedial_action}}` |
| Entries filed | initial / update / final notifications, dates, references |

Keep every entry — the register is how a supervisory authority verifies Article 33
compliance, including for breaches that were never notified.

## 6. UK and Norway filing channels

- **UK (UK GDPR):** report to the **ICO** via the online personal data breach form
  (or by phone for urgent live incidents); same 72-hour window and risk exception.
- **Norway (personopplysningsloven / EEA):** report to **Datatilsynet** via the
  **Altinn** portal; same 72-hour window.
- **EU cross-border:** notify the **lead supervisory authority** of your main
  establishment (Art 56); the EDPB maintains the list of national contact points.

---

Orbiq — European Trust Center platform · https://www.orbiqhq.com
Template page: https://www.orbiqhq.com/templates/gdpr-breach-notification-letter-pack
Run incident and trust communications as a governed workflow: https://www.orbiqhq.com/platform/trust-updates