# Personal Data Breach Assessment: [Breach reference and short name]

> Assessment and decision record for a personal data breach under
> Articles 33 and 34 of the General Data Protection Regulation
> (Regulation (EU) 2016/679, GDPR, applicable since 25 May 2018) and
> the European Data Protection Board (EDPB) Guidelines 9/2022 on
> personal data breach notification under GDPR, version 2.0 adopted on
> 28 March 2023. It covers triage, the Article 4(12) breach test, the
> risk assessment for individuals, the decision to notify the
> supervisory authority (Article 33) and to communicate with data
> subjects (Article 34), draft notification texts, other notification
> regimes, and the entry in the breach log required by Article 33(5).
> UK GDPR and United States examples are included as dated pointers.
> Replace every `[bracketed]` value and every row marked *Example*.
> Check the consolidated GDPR text, current EDPB guidance and your
> supervisory authority's notification form before use. This is a
> documentation format, not legal advice; check the current official
> text and consult a qualified professional.

<!--
Guidance: How to use this template
- Open this record as soon as anyone suspects a breach of security that
  touches personal data, before the facts are clear. The clock under
  Article 33(1) runs from awareness, not from the end of the
  investigation.
- Fill sections 1 to 4 fast and roughly, then refine. A notification
  can be made in phases (Article 33(4)); a late notification needs
  reasons for the delay.
- Every breach gets a breach log entry (section 10), including those
  you decide not to notify. The record of why you did not notify is
  what a supervisory authority will ask for.
- The worked example is fictional: Quillmere Learning Ltd, an online
  course provider established in one EU Member State with learners in
  four, whose cloud storage bucket of learner exports was left publicly
  readable. Delete it before use.
- Related documents: Incident Response Plan
  (`compliance/incident-response-plan`), Record of Processing
  Activities (`compliance/gdpr-ropa`), DPIA (`compliance/dpia`), Data
  Processing Agreement (`legal-lite/dpa`), Privacy Policy
  (`legal-lite/privacy-policy`), Risk Methodology
  (`compliance/risk-methodology`), Data Subject Request Procedure
  (`compliance/data-subject-request-procedure`), DORA Major Incident
  Report (`compliance/dora-major-incident-report`).
-->

## Document control

<!-- Guidance: One record per breach. Keep the awareness timestamp here and in section 1 identical; it drives every deadline. -->

| Field | Value |
|---|---|
| Document ID | [PDB-YYYY-NNN] |
| Version | [0.1] |
| Status | [Triage / Assessing / Notified / Communicated / Closed / Not a personal data breach] |
| Owner | [@privacy-lead] |
| Approvers/reviewers | [@dpo], [@ciso], [@legal], [@business-owner] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential, legally privileged where applicable] |
| Controller | [Legal entity, address] |
| Role of the organisation | [Controller / Joint controller / Processor] |
| Data protection officer | [@dpo], [contact] |
| Linked incident ID | [INC-NNN in the incident response tooling] |
| Awareness date and time | [YYYY-MM-DD HH:MM, time zone] |
| Article 33 deadline (awareness + 72 hours) | [YYYY-MM-DD HH:MM, time zone] |
| Lead or competent supervisory authority | [Authority name] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Data protection officer | [@dpo] | [Advice recorded in section 5] | YYYY-MM-DD |
| Accountable executive | [@exec] | [Notify / Do not notify / Notify in phases] | YYYY-MM-DD |
| Legal counsel | [@legal] | [Reviewed notification texts] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@privacy-lead] | Triage record opened |
| 0.2 | YYYY-MM-DD | [@privacy-lead] | Risk assessment and notification decision |
| 1.0 | YYYY-MM-DD | [@privacy-lead] | Closed with lessons learned |

## Contents

<!-- Guidance: Sections 1 to 5 are the decision, sections 6 to 9 are the notifications, sections 10 and 11 close the record. -->

1. Detection, awareness and timeline
2. Breach description
3. Containment and recovery
4. Risk assessment for individuals
5. Notification decision
6. Notification to the supervisory authority (Article 33)
7. Communication to data subjects (Article 34)
8. Processors, joint controllers and recipients
9. Other notification regimes
10. Breach log entry (Article 33(5))
11. Lessons learned and actions
12. Glossary and references

## 1. Detection, awareness and timeline

<!-- Guidance: Questions to answer: who reported what, when, and at what moment did the controller have a reasonable degree of certainty that a security incident compromised personal data? Pitfall: dating awareness from the end of the investigation, or from the moment the report reached the right team, to gain time. -->

The EDPB guidelines treat a controller as aware when it has a
reasonable degree of certainty that a security incident has led to
personal data being compromised. A short initial investigation to
establish that certainty is expected, and it should start promptly.
Record the reasoning for the chosen awareness time, because it is the
start of the 72-hour window in Article 33(1).

| Field | Value |
|---|---|
| How detected | [Monitoring alert / staff report / processor notice / external researcher / data subject complaint / media] |
| First report received | [YYYY-MM-DD HH:MM] |
| Awareness established | [YYYY-MM-DD HH:MM] |
| Reasoning for awareness time | [What was confirmed, by whom] |
| Article 33 deadline | [Awareness + 72 hours] |
| Initial notification sent | [YYYY-MM-DD HH:MM / not required] |
| Time from awareness to notification | [hours and minutes] |

### 1.1 Timeline

| Time (UTC) | Event | Source | Recorded by |
|---|---|---|---|
| 2026-03-02 09:40 *(Example)* | External researcher emails security@ about a publicly listable storage bucket | Mailbox | [@soc-analyst] |
| 2026-03-02 11:05 *(Example)* | Bucket permissions confirmed public; contents listed | Cloud console, access log | [@cloud-engineer] |
| 2026-03-02 15:10 *(Example)* | Sample of files confirmed to hold learner records; awareness established | File review | [@privacy-lead] |
| 2026-03-02 15:25 *(Example)* | Public access removed, bucket versioning and logs preserved | Change record CHG-0412 | [@cloud-engineer] |
| 2026-03-04 11:00 *(Example)* | Initial notification to the lead supervisory authority | Authority portal receipt | [@dpo] |
| 2026-03-11 16:00 *(Example)* | Follow-up notification with log analysis results | Authority portal receipt | [@dpo] |

In the example, awareness was established 5 hours 30 minutes after the
first report, the Article 33 deadline was 2026-03-05 15:10 UTC, and the
initial notification went out 43 hours 50 minutes after awareness,
inside the window. The follow-up notification came 9 days and 50
minutes after awareness, as a phased notification under Article 33(4).

## 2. Breach description

<!-- Guidance: Apply the definition in Article 4(12) first: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. If no personal data is involved, close the record as "not a personal data breach" and keep it. Pitfall: treating unavailability as "no breach"; a loss of availability is a breach type too. -->

### 2.1 Breach test

| Question | Answer |
|---|---|
| Was there a breach of security (confidentiality, integrity or availability safeguards failed)? | [Yes / No, reasoning] |
| Is personal data affected? | [Yes / No] |
| Breach type (one or more) | [Confidentiality / Integrity / Availability] |
| Cause category | [Misconfiguration / Malicious attack / Lost or stolen device / Misdirected communication / Insider misuse / System failure / Processor incident] |
| Ongoing or contained? | [Ongoing / Contained at YYYY-MM-DD HH:MM] |

The three breach types follow the information security model used by
the EDPB: a confidentiality breach is unauthorised or accidental
disclosure of or access to personal data, an integrity breach is
unauthorised or accidental alteration, and an availability breach is
accidental or unauthorised loss of access to, or destruction of,
personal data. One event can be all three.

### 2.2 Data and data subjects

| Group ID | Data subjects | Data categories | Special category or criminal data? | Number of people | Number of records |
|---|---|---|---|---|---|
| DSG-01 *(Example)* | Learners without study adjustment notes, all courses | Name, email, country, course enrolments, progress, completion dates | No | 17,250 | 17,250 learner rows |
| DSG-02 *(Example)* | Learners who requested study adjustments | As DSG-01, plus disability accommodation notes | Yes, health data (Article 9) | 1,150 | 1,150 learner rows and notes |
| [DSG-NN] | [group] | [categories] | [Yes / No] | [n] | [n] |
| **Total** *(Example)* | | | | **18,400** | **18,400** |

Record where the data subjects live (Member State or country), because
it decides which authorities may need to hear from you (section 5.3) and
which other laws may apply (section 9). In the example the learners
live in four Member States.

### 2.3 Systems, parties and source

| Item | Detail |
|---|---|
| Systems and locations | [Application, storage, region] |
| Processing activity in the ROPA | [PA-NNN in `compliance/gdpr-ropa`] |
| Processors and sub-processors involved | [Names, DPA references] |
| Third parties who received or accessed the data | [Known / unknown recipients] |
| Evidence preserved | [Logs, images, tickets, with hash and location] |

## 3. Containment and recovery

<!-- Guidance: Containment is the first duty, and it also changes the risk. Record every action with its time so section 4 can weigh it. Pitfall: deleting logs or rebuilding systems before evidence is preserved. -->

| Action ID | Action | Effect on risk | Owner | Done at |
|---|---|---|---|---|
| ACT-01 *(Example)* | Removed public read access from the bucket and enabled the account-level public access block | Stops further access | [@cloud-engineer] | 2026-03-02 15:25 |
| ACT-02 *(Example)* | Exported and preserved 90 days of storage access logs | Allows scoping of who downloaded files | [@soc-analyst] | 2026-03-02 17:00 |
| ACT-03 *(Example)* | Asked the researcher to confirm deletion of any downloaded copies, and received written confirmation | Reduces likelihood for the files the researcher opened | [@privacy-lead] | 2026-03-03 10:30 |
| ACT-04 *(Example)* | Monitored paste sites and the learner support inbox for signs of misuse | Early warning of harm | [@soc-analyst] | Ongoing to 2026-04-02 |
| [ACT-NN] | [action] | [effect] | [@owner] | YYYY-MM-DD HH:MM |

Questions to answer before section 4:

- Can the data still be accessed, altered or destroyed by anyone
  unauthorised?
- Is there evidence the data was copied, and by whom?
- Can lost data be restored from a backup, and how complete is the
  restore?
- Were the data encrypted, and was the key also exposed?

## 4. Risk assessment for individuals

<!-- Guidance: Assess the risk to the people concerned, not to the organisation. Combine the severity of possible consequences with their likelihood. The EDPB recommends weighing the criteria in 4.1; if in doubt, err on the side of caution and notify. Pitfall: scoring the whole breach once when groups of data subjects face very different risks. -->

### 4.1 Factors

| Factor (EDPB criteria) | Questions | Finding |
|---|---|---|
| Type of breach | Confidentiality, integrity or availability? Which consequences does each allow? | [finding] |
| Nature, sensitivity and volume of data | Special category data, financial data, identity documents, credentials, location, children's data? How much per person? | [finding] |
| Ease of identification | Can individuals be identified directly or easily from the data, alone or combined with public data? | [finding] |
| Severity of consequences | Identity fraud, financial loss, discrimination, physical harm, distress, humiliation, loss of confidentiality of professional secrets? Are effects reversible? | [finding] |
| Special characteristics of individuals | Children, patients, employees, other vulnerable people? | [finding] |
| Special characteristics of the controller | Does the controller's role (for example health or education) raise expectations or risk? | [finding] |
| Number of affected individuals | How many people, and could one person suffer severe harm even if few are affected? | [finding] |

### 4.2 Scoring method

The scale below is an internal method written for this template, not a
regulatory threshold. Replace it with your organisation's method in
`compliance/risk-methodology` if one exists, and document the reasoning
in words, not only the score.

| Score | Severity of consequences | Likelihood of consequences |
|---|---|---|
| 1 | Minor inconvenience, easily overcome | Very unlikely to materialise |
| 2 | Significant inconvenience, overcome with some effort | Possible |
| 3 | Serious consequences, overcome with serious difficulty | Likely |
| 4 | Significant or irreversible consequences | Very likely or already materialised |

Risk level = severity x likelihood: 1 to 3 is "unlikely to result in a
risk", 4 to 8 is "risk", 9 to 16 is "high risk". Treat these bands as a
prompt for judgement, not a substitute for it.

### 4.3 Assessment by group

| Group | Severity | Likelihood | Score | Level | Reasoning |
|---|---|---|---|---|---|
| DSG-01 *(Example)* | 2 | 2 | 4 | Risk | Contact and course data enable targeted phishing; logs show listing by three unknown addresses but no bulk download of these files |
| DSG-02 *(Example)* | 4 | 3 | 12 | High risk | Health information about named learners; one unknown address downloaded the accommodation notes folder |
| [DSG-NN] | [1-4] | [1-4] | [score] | [level] | [reasoning] |

Overall result: [Unlikely to result in a risk / Risk / High risk for
groups [list]]. In the example, the breach must be notified to the
supervisory authority (risk for all learners), and DSG-02 meets the
high-risk test for communication to data subjects.

## 5. Notification decision

<!-- Guidance: Record the decision, who made it, and the DPO's advice. If you decide not to notify, write the reasons as if an authority will read them, because it may. Pitfall: deciding against communication to individuals on the basis of encryption without confirming the key was not compromised. -->

```mermaid
flowchart TD
  A["Security incident reported"] --> B{"Personal data affected?"}
  B -- "No" --> Z["Close: not a personal data breach, keep record"]
  B -- "Yes" --> C["Contain, preserve evidence, set awareness time"]
  C --> D{"Unlikely to result in a risk to individuals?"}
  D -- "Yes" --> L["Record in breach log only (Article 33(5))"]
  D -- "No" --> E["Notify supervisory authority within 72 hours (Article 33)"]
  E --> F{"Likely high risk to individuals?"}
  F -- "No" --> L2["Record in breach log"]
  F -- "Yes" --> G{"Article 34(3) condition applies?"}
  G -- "No" --> H["Communicate to data subjects without undue delay"]
  G -- "Disproportionate effort" --> P["Public communication or equally effective measure"]
  G -- "Encryption or follow-up measures" --> L3["Record why communication is not required"]
  H --> L2
  P --> L2
  L3 --> L2
```

### 5.1 Supervisory authority (Article 33)

| Question | Answer |
|---|---|
| Is the breach unlikely to result in a risk to the rights and freedoms of natural persons? | [Yes / No, with reference to section 4] |
| Decision | [Notify / Do not notify] |
| If notifying after 72 hours, reasons for the delay | [reasons] |
| Will information be provided in phases? | [Yes, expected follow-up date / No] |

### 5.2 Data subjects (Article 34)

| Question | Answer |
|---|---|
| Is the breach likely to result in a high risk to the rights and freedoms of natural persons? | [Yes / No, for which groups] |
| Article 34(3)(a): were the data unintelligible to unauthorised persons, for example by state-of-the-art encryption with an uncompromised key? | [Yes / No, evidence] |
| Article 34(3)(b): did measures taken after the breach make the high risk no longer likely to materialise? | [Yes / No, evidence] |
| Article 34(3)(c): would individual contact involve disproportionate effort, so a public communication or similarly effective measure is used instead? | [Yes / No, method] |
| Decision | [Communicate directly / Public communication / Not required, reason] |

The supervisory authority can require communication to data subjects
if it considers the high risk likely, or can decide that one of the
Article 34(3) conditions is met (Article 34(4)). Keep the decision open
to revision as facts change.

### 5.3 Which authority

| Situation | Who to notify |
|---|---|
| Controller established in the EU, cross-border processing | The lead supervisory authority under the one-stop-shop (Article 56) |
| Controller established in the EU, local processing only | The competent supervisory authority of that Member State |
| Controller not established in the EU but subject to the GDPR under Article 3(2) | Every supervisory authority of a Member State where affected data subjects reside: EDPB Guidelines 9/2022 v2.0 paragraph 73 says the presence of an Article 27 representative does not trigger the one-stop-shop |

### 5.4 DPO advice

[Record the DPO's advice, whether it was followed, and if not, why.]

## 6. Notification to the supervisory authority (Article 33)

<!-- Guidance: Use the authority's own form or portal; this section is your draft and your record of what was sent. Article 33(3) sets the minimum content; give what you know now and say what will follow. Pitfall: waiting for complete facts and missing the deadline. -->

| Article 33(3) element | Content sent |
|---|---|
| (a) Nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned | [Text] |
| (b) Name and contact details of the DPO or another contact point | [Text] |
| (c) Likely consequences of the breach | [Text] |
| (d) Measures taken or proposed to address the breach and mitigate its possible adverse effects | [Text] |

### 6.1 Draft initial notification text

*Example*: On 2 March 2026 at 09:40 UTC, Quillmere Learning Ltd received
a report from an external security researcher that a cloud storage
location holding exports of learner records was publicly readable. We
confirmed at 15:10 UTC that the location held personal data and removed
public access at 15:25 UTC. About 18,400 learners in four Member States
are concerned, with 18,400 records. For 1,150 of them the files include
notes on disability-related study adjustments (health data). Access
logs show the location was listed by three unidentified network
addresses and that one of them downloaded the folder holding the
adjustment notes. Likely consequences are targeted phishing for all
learners and distress, discrimination or loss of confidentiality of
health information for the 1,150 learners concerned. We have preserved
logs, blocked public access across the account, obtained deletion
confirmation from the researcher and will write directly to the 1,150
learners. Contact point: [DPO name, email, phone]. We will provide the
results of the full log analysis by 13 March 2026.

### 6.2 Phased and follow-up notifications

| Notification | Date and time | Reference | New information |
|---|---|---|---|
| Initial *(Example)* | 2026-03-04 11:00 | [Authority case number] | Facts known at that point |
| Follow-up 1 *(Example)* | 2026-03-11 16:00 | [Same case number] | Log analysis: no further downloads; total confirmed |
| [Follow-up N] | YYYY-MM-DD HH:MM | [reference] | [information] |

## 7. Communication to data subjects (Article 34)

<!-- Guidance: Article 34(2) requires clear and plain language and at least the information in Article 33(3)(b), (c) and (d). Send a dedicated message, not a paragraph inside a newsletter. Pitfall: legal language that hides what happened and what the person should do. -->

| Element | Content |
|---|---|
| Nature of the breach in plain language | [Text] |
| DPO or contact point | [Text] |
| Likely consequences | [Text] |
| Measures taken or proposed, including steps the person can take | [Text] |
| Channel | [Email / letter / in-app message / public notice under Article 34(3)(c)] |
| Languages | [Languages of the affected people] |
| Sent on | YYYY-MM-DD, [number] recipients, [number] bounced and how they were followed up |

### 7.1 Draft message

*Example*:

Subject: Important information about your study adjustment records

Dear [Learner name],

We are writing to tell you about a security problem that affected some
of your information held by Quillmere Learning. On 2 March 2026 we
learned that a storage area holding copies of learner records had been
set up incorrectly and could be read from the internet. We closed it
the same day. The files included your name, email address, your
courses and the notes about the study adjustments you asked us to
provide. We know that an unidentified person downloaded these files.

This could mean that someone who should not know about your health
needs now does, or that you receive emails pretending to be from us.
We will never ask for your password by email. If you receive a message
that looks like ours and asks for personal details, please forward it
to [address] and do not reply.

We have fixed the setting that caused the problem, checked every other
storage area for the same error and told the data protection
supervisory authority. If you have questions or concerns, contact our
data protection officer at [contact]. You also have the right to lodge
a complaint with a supervisory authority.

[Name, role]

## 8. Processors, joint controllers and recipients

<!-- Guidance: A processor must notify the controller without undue delay after becoming aware of a breach (Article 33(2)); the DPA should set the practical deadline and content. Joint controllers should already have agreed in their Article 26 arrangement who notifies. Pitfall: the controller's 72 hours start only when the controller is aware, but a slow processor is still the controller's problem. -->

| Party | Role | Notified us at | Our notice to them | Contract clause | Follow-up |
|---|---|---|---|---|---|
| [Cloud provider] *(Example)* | Processor | Not involved; misconfiguration was ours | Not required | DPA clause [n] | None |
| [Learning platform vendor] | [Processor / Joint controller] | YYYY-MM-DD HH:MM | [date] | [clause] | [action] |

If this organisation is the processor, record when you told the
controller, what you told them, and which support you offered, then
stop: the notification decisions in sections 5 to 7 belong to the
controller.

## 9. Other notification regimes

<!-- Guidance: One incident can trigger several regimes with different clocks, recipients and thresholds. List each that may apply and confirm with counsel. Dates below were checked when the template was written; laws change. Pitfall: assuming the GDPR notification satisfies sector or contractual duties. -->

| Regime | Trigger and recipient (summary) | Clock (summary) | Applies? |
|---|---|---|---|
| EU NIS2, Directive (EU) 2022/2555, Article 23 | Significant incident at an essential or important entity, to the CSIRT or competent authority | Early warning within 24 hours, notification within 72 hours of awareness, final report no later than one month after the incident notification | [Yes / No] |
| EU DORA, Regulation (EU) 2022/2554 | Major ICT-related incident at a financial entity, to the competent authority | See `compliance/dora-major-incident-report` | [Yes / No] |
| UK GDPR and Data Protection Act 2018 | Personal data breach, to the Information Commissioner's Office (ICO) and, if high risk, to individuals | Without undue delay and no later than 72 hours after awareness (ICO guide, page last updated 20 August 2025) | [Yes / No] |
| UK PECR | Breach at a provider of public electronic communications services, to the ICO | ICO reports the Data (Use and Access) Act 2025 moves this from 24 to 72 hours; check commencement | [Yes / No] |
| US state breach notification laws | Breach of defined personal information of state residents, to individuals and in some states to the attorney general or regulators | Varies by state; every US state has such a law | [States concerned] |
| US HIPAA Breach Notification Rule, 45 CFR 164.400 to 164.414 | Breach of unsecured protected health information by a covered entity or business associate | Check the current rule text on the HHS and eCFR sites | [Yes / No] |
| Contracts, insurance, card schemes | Customer contracts, cyber insurance policy, payment card rules | As per contract or policy | [List] |

Proposed EU changes to watch: the Commission's Digital Omnibus proposal
of November 2025 would, as reported, move Article 33 to a high-risk
threshold, a 96-hour deadline and a single entry point for incident
reporting. It was still a proposal when this template was written;
check its status before relying on it.

## 10. Breach log entry (Article 33(5))

<!-- Guidance: The controller must document every personal data breach: the facts, its effects and the remedial action taken, so the supervisory authority can verify compliance. Keep this row in the central breach log as well as in this record. Pitfall: logging only notified breaches. -->

| Field | Entry |
|---|---|
| Breach ID | PDB-2026-007 *(Example)* |
| Facts | Learner export bucket publicly readable between [date of misconfiguration] and 2026-03-02 15:25 UTC; 18,400 learners, 1,150 with health data |
| Effects | One unidentified download of health-data folder; no misuse observed by 2026-04-02 |
| Remedial action | ACT-01 to ACT-04; account-wide public access block; configuration check in CI (see section 11) |
| Risk level | Risk (DSG-01), high risk (DSG-02) |
| Notified to authority | Yes, 2026-03-04 11:00 UTC, 43 hours 50 minutes after awareness |
| Communicated to data subjects | Yes, DSG-02 only, 2026-03-05 |
| Reason for any non-notification | DSG-01 not contacted individually: risk, not high risk |
| Decision makers | [@dpo] advice, [@exec] decision |
| Closed | YYYY-MM-DD |

## 11. Lessons learned and actions

<!-- Guidance: Hold a review within a few weeks of closure. Feed actions into the risk register and, where the processing changes, the DPIA. -->

| Action ID | Finding | Action | Owner | Due | Status |
|---|---|---|---|---|---|
| LL-01 *(Example)* | Exports were placed in a bucket created by hand outside infrastructure as code | Create storage only through reviewed templates with public access blocked | [@platform-lead] | YYYY-MM-DD | Open |
| LL-02 *(Example)* | Accommodation notes were included in a general export with no business need | Remove special category fields from routine exports; update the DPIA | [@data-owner] | YYYY-MM-DD | Open |
| LL-03 *(Example)* | Awareness took 5 hours 30 minutes, because the security mailbox was not monitored before 11:00 | Route security@ to the on-call rota | [@soc-lead] | YYYY-MM-DD | Done |
| [LL-NN] | [finding] | [action] | [@owner] | YYYY-MM-DD | [status] |

## 12. Glossary and references

<!-- Guidance: Keep references dated; check each before a live breach, because guidance and forms change. -->

### 12.1 Glossary

| Term | Meaning in this template |
|---|---|
| Personal data breach | A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (Article 4(12), paraphrased) |
| Awareness | The point at which the controller has a reasonable degree of certainty that a security incident has compromised personal data |
| Lead supervisory authority | The authority of the main establishment that leads on cross-border processing |
| Phased notification | Providing the Article 33(3) information in stages without further undue delay (Article 33(4)) |
| Breach log | The documentation of all breaches required by Article 33(5) |

### 12.2 References

| Reference | Version or date | Use |
|---|---|---|
| Regulation (EU) 2016/679 (GDPR), Articles 4(12), 33, 34, 55, 56, 3(2), 27 | Applies from 25 May 2018; check the consolidated text on EUR-Lex | Legal basis |
| EDPB Guidelines 9/2022 on personal data breach notification under GDPR | Version 2.0, adopted 28 March 2023 (version 1.0 of 10 October 2022 updated WP250 rev.01) | Awareness, phases, risk factors, non-EU controllers |
| ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches | Referenced by the EDPB guidelines | Optional severity method |
| ICO, Personal data breaches: a guide | Page updates listed to 20 August 2025 | UK example |
| Directive (EU) 2022/2555 (NIS2), Article 23 | Check national transposition | Parallel incident reporting |
| US HHS, HIPAA Breach Notification Rule | 45 CFR 164.400 to 164.414 | US health example |
| European Commission, Digital Omnibus proposal | November 2025, proposal only | Pending change to Article 33 |

Links: EDPB guidelines
https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en ;
GDPR on EUR-Lex https://eur-lex.europa.eu/eli/reg/2016/679/oj ; ICO
guide
https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/ ;
HHS breach notification
https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html ;
ENISA methodology https://www.enisa.europa.eu/publications/dbn-severity

## Standard and licence note

Based on Regulation (EU) 2016/679 (GDPR) as published in the Official
Journal of the European Union, and on EDPB Guidelines 9/2022 on
personal data breach notification under GDPR, version 2.0 adopted on
28 March 2023. EU legislative texts and EDPB guidelines are public;
article numbers are cited and obligations are summarised in original
wording, and no guideline text is reproduced. The UK and US rows are
dated pointers, not complete summaries of those laws. The scoring
scale, worked example, organisation, people and figures are fictional
and written for this template. Check the consolidated GDPR text, the
current EDPB guidance, your supervisory authority's form and any
legislative changes (including the Digital Omnibus proposal) before
use. This is a documentation format, not legal advice; consult a
qualified professional. Template licence: MIT.