Risk Assessment in the Event of a Personal Data Breach
How the risk of a data breach is assessed: the three-tier model, the assessment factors, the severity and likelihood of the adverse effects, the risk matrix and case examples for the classification.
The risk assessment is the central switch point in dealing with a personal data breach. It determines whether the breach merely has to be documented, whether it has to be notified to the supervisory authority, or whether the data subjects additionally have to be informed. This page sets out the three-tier model and the practical approach in three steps.
Key takeaways
- What matters is the risk to the rights and freedoms of the data subjects, not the risk to the controller's own business (fines, reputation).
- Three tiers: no risk (documentation only), risk (notification under Article 33), high risk (notification under Article 33 and communication under Article 34).
- The risk results from the interplay of the severity and the likelihood of occurrence of the possible adverse effects.
- The assessment is made from the perspective of the time at which the breach became known, on the basis of a comprehensible methodology; the result must be documented.
- In case of doubt, classify at the higher level.
1. What the risk assessment determines
The GDPR works with two thresholds. The obligation to notify under Article 33(1) GDPR is dispensed with only where the breach is unlikely to result in a risk. The obligation to communicate under Article 34(1) GDPR arises only where the breach is likely to result in a high risk. This gives rise to three tiers with different legal consequences.
| Risk level | Notification to the supervisory authority (Article 33) | Communication to the data subjects (Article 34) |
|---|---|---|
| No or low risk | no | no |
| Risk | yes | no |
| High risk | yes | yes |
Documentation under Article 33(5) GDPR is mandatory at all three tiers. The assessment itself is a forecast: it is not a matter of certainty, but of the development to be expected following a methodologically comprehensible analysis. It is carried out in three steps.
2. Step 1: Establishing the basis for assessment
First, the factual circumstances relevant to the risk are recorded. They form the basis for the subsequent analysis. The supervisory authorities and the EDPB consistently name the following factors (EDPB, Guidelines 9/2022, paras. 105 et seq.):
- Nature of the breach. The disclosure of data concerning health to unauthorized persons has different consequences from the mere temporary loss of the same data.
- Nature, sensitivity and volume of the data. The more sensitive the data, the higher the risk. Special categories of personal data (Article 9 GDPR) as well as identity document data and financial data are of particular importance. A combination of several types of data is regularly more sensitive than a single element, because it may, for instance, enable identity theft.
- Identifiability of the data subjects. How easily can specific individuals be determined from the data? Appropriate encryption or pseudonymization reduces identifiability.
- Severity of the consequences. Is there a threat of discrimination, identity theft, financial loss, damage to reputation or the disclosure of information subject to professional secrecy?
- Special characteristics of the data subjects. Children and other vulnerable persons may be at greater risk.
- Special characteristics of the controller. A medical institution typically processes more sensitive data than a newsletter provider.
- Number of data subjects affected. A larger number of data subjects generally means more far-reaching consequences; in an individual case, however, even a single person being affected may give rise to a high risk.
3. Step 2: Risk analysis based on severity and likelihood
On this basis, the possible adverse effects for the data subjects are derived and assessed. Physical, material or non-material damage may come into consideration, that is, both pecuniary and non-pecuniary damage. Each possible adverse effect is assessed along two dimensions:
- Severity: how serious is the adverse effect for the data subject if it materializes?
- Likelihood of occurrence: how likely is it that it will materialize?
Mitigating measures that have already taken effect must be taken into account. Where an adverse effect has already materialized, the assessment is limited to its severity in that respect; for consequences that have not yet occurred, both severity and likelihood continue to be assessed. Where there is uncertainty in the assessment, the higher level must be chosen in each case.
4. Step 3: Overall assessment using the risk matrix
In the overall assessment, severity and likelihood of occurrence are brought together and assigned to one of the three risk levels. A finer gradation than no risk, risk and high risk is not required for the application of Articles 33 and 34 GDPR. The following matrix reflects the typical assignment.
| Severity ↓ / Likelihood → | low | limited | substantial | high |
|---|---|---|---|---|
| high | 2 | 3 | 3 | 3 |
| substantial | 2 | 2 | 3 | 3 |
| limited | 1 | 2 | 2 | 3 |
| minor | 1 | 1 | 2 | 2 |
How to read the matrix: 1 = no or low risk (documentation only), 2 = risk (notification under Article 33), 3 = high risk (notification under Article 33 and communication under Article 34). Adverse effects that have already materialized and whose severity is at least limited give rise to a high risk.
5. Which factors tip the classification
In the cases prepared by the supervisory authorities and by the EDPB, the same few factors repeatedly determine whether a breach is merely documented, notified, or additionally communicated to the data subjects (EDPB, Guidelines 01/2021). Anyone classifying an incident should examine these points specifically:
- Is a backup available? Where the data can be restored promptly, the risk arising from a loss of availability drops considerably.
- Exfiltration of data or encryption only? Where data were merely encrypted, the situation is more favorable than where data were additionally exfiltrated.
- State-of-the-art encryption or hashing, key and salt intact? In that case the data are inaccessible to unauthorized persons.
- Are special categories of personal data (Article 9 GDPR) affected? Health, financial or identity document data raise the risk considerably.
- Were the data subjects' contact details disclosed as well? They enable follow-up attacks such as phishing and increase the risk.
- Number of data subjects. A large number of data subjects means more far-reaching consequences; in an individual case, however, a single person may suffice.
- Interruption of operations or of essential services? Delayed treatments or payments aggravate the consequences considerably.
- Vulnerable persons? Data about children or other particularly vulnerable persons increase the risk of harm.
- Trusted recipient? A recipient bound by a duty of confidentiality who erases the data may eliminate the severity of the consequences.
6. Case examples for guidance
The EDPB has assigned an assessment to typical categories of cases. They do not replace the examination of the individual case, but they do provide reliable guidance (EDPB, Guidelines 01/2021; Guidelines 9/2022, Annex B). Any change in the circumstances may lead to a different classification.
| Scenario | Notification (Article 33) | Communication (Article 34) |
|---|---|---|
| Ransomware, data encrypted, up-to-date backup, no exfiltration, few data subjects | no | no |
| Ransomware without an electronic backup, no special categories of data | yes | no |
| Ransomware in a hospital, backup available but treatment delayed | yes | yes |
| Ransomware without a backup and with exfiltration of identity document and financial data | yes | yes |
| Exfiltration of extensive job application data from a website | yes | yes |
| Exfiltration of hashed passwords only (strong algorithm, salt not compromised) | no | no |
| Loss of an encrypted device with a secure key and an existing backup | no | no |
| Theft of an unencrypted laptop containing data on numerous individuals | yes | yes |
| Brief power outage at a call center, data unavailable for a few minutes | no | no |
| Cyberattack, user names and passwords published on the internet | yes | yes |
| Hospital: medical records inaccessible for 30 hours | yes | yes |
| A single letter containing few data sent to the wrong person | no | no |
| Email with names and social security numbers sent to more than 60,000 recipients | yes | yes |
| Email with the visible addresses of many recipients in the To or Cc field | possibly | possibly |
Even in the cases without an obligation to notify, internal documentation remains mandatory. In the case of a misdirected letter, informing the data subjects may also be advisable or necessary, for instance because their cooperation is required for the return or erasure of the data, without this at the same time triggering the obligation to communicate under Article 34 GDPR. In the case of a group email with visible addresses, the classification depends on the number and the sensitivity of the addressees.
7. Three cases in detail
The following examples, based on the EDPB's categories of cases, show how the factors interact (EDPB, Guidelines 01/2021).
Case 1: Misdirected email. Facts: An employee accidentally sends a list of participants containing 15 names and two entries on dietary preferences to the participants instead of to the hotel and immediately requests its deletion. Assessment: A small volume of data, no serious consequences, immediate containment. Consequence: No risk triggering an obligation to notify, internal documentation only. The position is different where an email discloses the names and social security numbers of tens of thousands of individuals: in that case both notification and communication are required.
Case 2: Lost device. Facts: A tablet containing data on children at a day care center is stolen; it is encrypted and password-protected, a backup exists, and the data are additionally erased remotely. Assessment: Encryption and the backup practically exclude any risk. Consequence: Documentation only. Where, by contrast, an unencrypted laptop containing data on numerous customers is stolen, notification and communication are required.
Case 3: Compromised email account (business email compromise). Facts: Using a compromised account, an attacker sets up hidden forwarding rules, intercepts invoices and sends out falsified payment requests; the names and payroll data of employees have also been exfiltrated. Assessment: A breach of confidentiality involving financial and employee data, with a risk of fraud and identity misuse. Consequence: Notification to the supervisory authority and communication to all affected employees, not only to those whose payroll data were disclosed.
8. Special cases
Encryption and pseudonymization. Where the data concerned are encrypted using a state-of-the-art method and the key has not been compromised, the data are inaccessible to unauthorized persons; the risk arising from the breach of confidentiality is reduced to a minimum. This may render communication to the data subjects unnecessary (Article 34(3)(a) GDPR). Availability must nevertheless be kept in mind: where no backup of the encrypted data exists, it is precisely the loss of availability that may give rise to a risk triggering the obligation to notify.
Trusted recipient. Where data are inadvertently sent to a recipient with whom a relationship of trust exists (for instance the wrong internal department, or a regularly engaged service provider bound by a duty of confidentiality), and that recipient complies with a request to erase or return the data, this may eliminate the severity of the consequences. It does not alter the fact that a breach has occurred and must be documented.
Assessing the risk to the data subjects is not the same as the risk assessment carried out in a data protection impact assessment. The impact assessment evaluates a hypothetical event in advance; here the incident has already occurred, so that what matters is solely the risk of the specific consequences.
About the author
About the author
This article was written by Dr. Thomas Helbing, specialist lawyer for IT law in Munich.
Since 2020 and continuously through today (2026), Handelsblatt has recognized Dr. Helbing as one of "Germany's Best Lawyers" in IT law and data protection law.
According to Kanzleimonitor.de (2024 to 2026 editions), he ranks among the leading lawyers for data protection and IT law and is listed among the top 100 lawyers in Germany (2024/25). Kanzleimonitor is considered a particularly meaningful market study because it is based exclusively on personal recommendations from in-house counsel.
Dr. Helbing has many years of advisory experience in data protection and IT law and advises clients of all sizes, from startups through fast-growing SaaS companies and unicorns to international corporate groups.
His professional background covers the full spectrum of IT and technology law practice. He began his career at a major international law firm, then gained in-house experience at a DAX-listed company, and is himself an entrepreneur and founder of several digital ventures. He also has hands-on programming experience, which allows him to understand technical systems, software architectures and digital business models not only from a legal perspective but also from a technical one.
For many years, his clients have included technology companies and SaaS providers, leading German research institutions and a systemically important German bank. His advisory focus lies in particular on GDPR compliance, the data economy, SaaS, AI regulation and IT contract law.
First Steps and Internal Procedure in the Event of a Personal Data Breach
What has to be done immediately after a data breach has been discovered: detection and containment, internal reporting, the preliminary review, from when the breach counts as known and the 72-hour period begins, and the obligations of processors.
Notification to the Supervisory Authority (Article 33 GDPR)
When a personal data breach has to be notified to the supervisory authority, the 72-hour period and how it is calculated, the competent authority, the minimum content of the notification, phased and bundled notification, and the documentation obligation under Article 33(5) GDPR.