Personal Data Breach Assessment Template (GDPR Art. 33 and 34)
Breach triage, awareness and 72-hour clock, risk to individuals, Art. 33/34 notification decision, authority and data subject texts, breach log entry
Як використовувати: Use it when a security incident may involve personal data and you must decide within 72 hours whether to notify the supervisory authority and the people affected. Fill the awareness time, the data subject groups and the risk assessment first, then the notification decision. The main pitfall is waiting for complete facts instead of notifying in phases, or logging only the breaches you notify.
Перегляд
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.
Document control
| 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
- Detection, awareness and timeline
- Breach description
- Containment and recovery
- Risk assessment for individuals
- Notification decision
- Notification to the supervisory authority (Article 33)
- Communication to data subjects (Article 34)
- Processors, joint controllers and recipients
- Other notification regimes
- Breach log entry (Article 33(5))
- Lessons learned and actions
- Glossary and references
1. Detection, awareness and timeline
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
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
| 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
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
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)
| 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)
| 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
| 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
| 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))
| 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
| 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
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.
Схожі шаблони
Data Residency and Sovereignty Assessment Template (GDPR Chapter V)
Data tiers, flow map, jurisdiction matrix, Chapter V mechanisms, TIAs, PIPL and DPDP examples, Data Act Art. 32, key custody, sovereign cloud scoring, decision
ISO та комплаєнсAML Business-Wide Risk Assessment Template (ML/TF/PF)
Enterprise-wide ML/TF/PF and sanctions evasion risk assessment: method, inputs, inherent risk by area, control ratings, residual risk, appetite, actions
ISO та комплаєнсCCPA Risk Assessment and Cybersecurity Audit Template
CCPA risk assessment and cybersecurity audit record: 7150 screening, 7152 report, ADMT, 45-day updates, Agency submission, audit scope, report and certification