Most notification mistakes come from a rushed, undocumented judgement about whether a security incident puts people at risk. Under the GDPR the controller must decide, usually within 72 hours, whether a personal data breach is unlikely to result in a risk (record only), likely to result in a risk (notify the supervisory authority) or likely to result in a high risk (also tell the people affected). This template gives a repeatable assessment record for that decision: facts, breach type, a severity score based on the ENISA methodology, the EDPB risk factors, the decision and its reasoning. It is for DPOs, privacy leads and incident managers, and sits between the security triage in the Incident Severity Classification Matrix Template and the notification steps in the Data Breach Notification Checklist.
How to use this template
- Who completes it: the privacy lead or DPO, with the incident manager supplying facts. One record per incident; update it as facts change rather than starting again.
- When to start: as soon as there is a reasonable degree of certainty that a security incident has compromised personal data. The EDPB treats that point as when the controller becomes "aware", and it starts the 72-hour clock in Article 33(1).
- Placeholders: replace [Organisation], [DPO], [Supervisory Authority] and similar fields. Keep the scoring tables as they are so assessments stay comparable over time.
- Scope: written for EU GDPR and UK GDPR. Other regimes (for example US state laws, HIPAA, sector rules) have their own triggers; record them in section 9 and see the Breach Notification Laws by Country Guide.
- Retention: keep every completed record, notified or not. Article 33(5) requires documentation of all personal data breaches, and the EDPB recommends recording the reasoning, including why a breach was judged unlikely to result in risk.
1. Purpose
This assessment records how [Organisation] decides whether a personal data breach must be notified to [Supervisory Authority] under Article 33 GDPR and communicated to data subjects under Article 34 GDPR, and documents the facts, effects and remedial action as required by Article 33(5).
2. Incident reference and timeline
| Field | Entry |
|---|---|
| Incident ID / security ticket | [ID] |
| Date and time incident detected | [YYYY-MM-DD hh:mm, time zone] |
| Date and time [Organisation] became aware (reasonable certainty personal data compromised) | [YYYY-MM-DD hh:mm]. Basis: [what evidence established awareness] |
| 72-hour deadline | [awareness time plus 72 hours] |
| If a processor reported it: date processor became aware, date it notified us | [dates; processor name] |
| Role of [Organisation] | [Controller / Joint controller / Processor]. If processor: notify the controller without undue delay and stop here except for section 8. |
| Assessor and reviewer | [Name, role] / [DPO] |
3. Facts of the incident
- What happened: [plain description: cause, entry point, systems, whether the cause is accidental or deliberate].
- Data categories involved: [for example contact details, account credentials, financial data, health data, children's data, location data, identity documents].
- Data subject categories: [customers, staff, patients, children, other vulnerable groups].
- Approximate numbers: [data subjects] / [records]. State whether figures are confirmed or estimated.
- Protection in place: [encryption, and whether keys were also exposed; pseudonymisation, and whether the mapping table was also exposed].
- Recipients: [known and trusted recipient / known recipient / unknown or public / criminal actor].
- Current status: [contained / ongoing; data retrieved or deleted, with evidence].
- Unknowns: [what is not yet established and how it will be found out]. If logs or forensics are missing, record it and assume the worse case until evidence says otherwise.
4. Breach type
Tick all that apply. The EDPB classifies breaches by the security property affected, and a single incident often hits more than one.
| Type | Definition (EDPB Guidelines 9/2022) | Applies? |
|---|---|---|
| Confidentiality | Unauthorised or accidental disclosure of, or access to, personal data | [Yes / No] |
| Integrity | Unauthorised or accidental alteration of personal data | [Yes / No] |
| Availability | Accidental or unauthorised loss of access to, or destruction of, personal data. Permanent loss always qualifies; temporary loss can | [Yes / No; duration] |
5. Severity score
This section adapts the ENISA and Greek and German data protection authority methodology for personal data breach severity (2013). Severity = DPC x EI + CB.
5.1 Data processing context (DPC)
| Data category | Basic score | Examples |
|---|---|---|
| Simple | 1 | Name, contact details, education, family details |
| Behavioural | 2 | Location, traffic data, habits and preferences |
| Financial | 3 | Income, transactions, account or card data |
| Sensitive | 4 | Health, special category data, criminal offence data |
Adjust the basic score up or down for context (for example, contact details of a person in a protection programme score higher; publicly available financial data scores lower), keeping it between 1 and 4. Where several categories are involved, use the highest adjusted score. DPC: [score]. Reason for any adjustment: [text].
5.2 Ease of identification (EI)
| Level | Multiplier | Meaning |
|---|---|---|
| Negligible | 0.25 | Extremely hard to link the data to a specific person |
| Limited | 0.5 | Identification possible only with significant extra data |
| Significant | 0.75 | Identification possible with some additional information |
| Maximum | 1 | Data directly identifies the person |
EI: [multiplier]. Reason: [text].
5.3 Circumstances of the breach (CB)
| Element | 0 | +0.25 | +0.5 | Score |
|---|---|---|---|---|
| Loss of confidentiality | No evidence of unlawful processing | Known recipients | Unknown recipients | [ ] |
| Loss of integrity | No misuse identified | Possible misuse, data recoverable | Possible misuse, data not recoverable | [ ] |
| Loss of availability | Easily recoverable | Temporary loss | Permanent loss | [ ] |
| Malicious intent | Not malicious | n/a | Intentional breach | [ ] |
CB: [sum, 0 to 2].
5.4 Result
| Severity score | Level | Starting presumption for this template |
|---|---|---|
| Below 2 | Low | Record only, unless section 6 factors raise the risk |
| 2 to below 3 | Medium | Likely risk: notify the supervisory authority |
| 3 to below 4 | High | Likely high risk: notify the authority and consider data subjects |
| 4 or above | Very high | Notify the authority and data subjects unless an Article 34(3) condition applies |
Score: [DPC] x [EI] + [CB] = [result]. Level: [ ]. Flags (reported alongside, not added to the score): more than 100 data subjects [Yes / No]; data unintelligible, for example strongly encrypted with key not compromised [Yes / No].
The levels and presumptions in the third column are [Organisation]'s internal mapping, not thresholds set by the GDPR or ENISA. The score supports, and never replaces, the legal judgement in section 7.
6. Risk factors to individuals
Answer each factor from EDPB Guidelines 9/2022 and record how it moves the assessment.
| Factor | Questions | Effect on risk |
|---|---|---|
| Type of breach | Confidentiality, integrity, availability or a combination (section 4)? | [raises / neutral / lowers] |
| Nature, sensitivity and volume of data | Special category, criminal, financial, credentials, identity documents? Combination enabling fraud? | [ ] |
| Ease of identification | Directly identifying, or pseudonymised with key safe (section 5.2)? | [ ] |
| Severity of consequences | Which recital 75 harms are plausible: identity theft or fraud, financial loss, discrimination, reputational damage, distress, loss of professional secrecy, physical harm? | [ ] |
| Special characteristics of individuals | Children, patients, vulnerable people, people at risk of harm if located? | [ ] |
| Special characteristics of the controller | Does the controller's role imply sensitivity, for example a medical, legal or social care provider? | [ ] |
| Number of individuals affected | How many, and is the figure confirmed? | [ ] |
Likelihood of harm: [unlikely / possible / likely]. Severity of harm: [minimal / significant / serious]. The ICO stresses that each case is assessed on its own facts, weighing both severity and likelihood.
7. Notification decision
| Decision | Legal basis | Selected |
|---|---|---|
| Unlikely to result in a risk: record only | Article 33(1) exception; Article 33(5) record | [ ] |
| Likely to result in a risk: notify [Supervisory Authority] without undue delay and where feasible within 72 hours | Article 33(1) | [ ] |
| Likely to result in a high risk: also communicate to data subjects without undue delay | Article 34(1) | [ ] |
Reasoning: [two to five sentences tying the facts, score and factors to the decision].
Article 34(3) conditions (if high risk but data subjects not told):
- (a) appropriate measures made the data unintelligible to unauthorised persons, such as encryption: [Yes / No, evidence].
- (b) subsequent measures mean the high risk is no longer likely to materialise: [Yes / No, evidence].
- (c) individual communication would involve disproportionate effort, so a public communication or equally effective measure is used: [Yes / No, method].
Cross-border: lead supervisory authority [name]. If [Organisation] is not established in the EEA but is subject to Article 3(2), the EDPB says an EU representative does not trigger the one-stop-shop, so notify every authority where affected data subjects reside: [list].
Approved by: [DPO / decision owner], [date and time].
8. Notification content and phases
Article 33(3) sets the minimum content. Where full facts are not yet available, notify in phases without further undue delay (Article 33(4)) and explain any delay past 72 hours.
| Article 33(3) item | Entry | Sent (date) |
|---|---|---|
| (a) Nature of the breach, categories and approximate numbers of data subjects and records | [ ] | [ ] |
| (b) Name and contact details of the DPO or other contact point | [ ] | [ ] |
| (c) Likely consequences | [ ] | [ ] |
| (d) Measures taken or proposed, including mitigation | [ ] | [ ] |
Communication to data subjects (Article 34(2)) must describe the nature of the breach in clear and plain language and include items (b) to (d). The ICO also recommends practical advice, such as resetting passwords. Use the Customer Breach Notification Letter Template.
9. Other obligations
- Other laws and regulators: [sector regulators, NIS2 or other cyber incident reporting, US state laws, HIPAA, financial regulators], with their own clocks.
- Contracts: [customer or controller notification clauses, insurer notification].
- Law enforcement: [report reference if applicable].
10. Remedial action and review
- Containment and mitigation done: [credentials reset, access revoked, data recalled or deleted, monitoring offered].
- Control changes: [what will change and owner, linked to the Article 32 risk assessment it tested].
- Reassessment triggers: re-score if new facts emerge about data, numbers, recipients or misuse; record each version with date.
- Closure: [date], signed off by [DPO].
Implementation guidance
- Calibrate before you need it: score five past incidents with the template and agree the outcomes with the DPO and legal team. Run it through the Data Breach Tabletop Exercise so the 72-hour clock is practised.
- Do not let the score decide alone: the ENISA formula is a working tool. A low score with vulnerable data subjects or a credible fraud path should still go to the authority.
- Decide on awareness, not certainty: do not wait for a complete forensic picture before starting the clock; notify in phases instead. Keep a timestamped log in the Incident Log and Decision Record Template.
- Treat encryption claims carefully: the unintelligible data flag and Article 34(3)(a) only hold if the keys were not exposed and the algorithm and implementation were sound; record the evidence.
- Include machine access paths: leaked API keys, service account tokens and integration credentials that can read personal data are personal data breaches when data was accessed. Scope by what the credential could read and what logs show it read.
- Feed lessons back: link each record to the control it tested in the GDPR Article 32 Security of Processing Guide evidence pack, and track trends: number of assessments, share notified, median hours from awareness to decision.
- Know the cost of getting it wrong: failure to notify falls under Article 83(4), with fines up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher; the ICO gives the UK equivalent as up to £8.7 million or 2%.
Sources: GDPR Articles 33, 34 and 83 and recital 75 (gdpr-info.eu); EDPB: Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0 adopted 28 March 2023; ENISA: Recommendations for a methodology of the assessment of severity of personal data breaches; ICO: Personal data breaches, a guide.
This template summarises GDPR breach assessment duties as of November 2026 and is not legal advice. Related NHI Mgmt Group resources: Data Breach Notification Checklist · Incident Severity Classification Matrix Template · Customer Breach Notification Letter Template · GDPR Compliance Guide for Security Teams