When to notify a GDPR breach: risk to individuals

When to notify a GDPR breach: the two-step risk test

Under Article 33(1), the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals. Under Article 34(1), the controller must also communicate the breach to the affected people without undue delay where it is likely to result in a high risk to them. Read together, these rules make two separate decisions: whether the authority is told, and whether the people are told. The clock starts when the controller becomes aware of the breach, so the assessment has to be made quickly and recorded as it happens. The answer depends on three things: the damage the breach could cause to individuals, the nature and sensitivity of the data involved, and the safeguards that were in place. Recital 85 lists the harms to consider, including loss of control over data, discrimination, identity theft or fraud, financial loss, damage to reputation and loss of confidentiality of data under professional secrecy. The same type of incident, such as a misdirected email, can therefore lead to different outcomes depending on whether it exposed health records or a contact list. Confirm internally who makes this call, who approves it, and which data categories and volumes your records of processing show for each system. The organization owns this decision and carries the legal exposure for it. An implementation partner can help you design the assessment template, set up the breach register, collect the logs and system facts that feed the assessment, and prepare the written record of the reasoning. The partner does not decide whether to notify and does not file reports on your behalf. Keep the record of both outcomes, notified and not notified, because the reasoning is what a supervisory authority will examine.

Which notification outcome applies to a breach

This table compares the four outcomes a controller can reach after assessing a breach, with the condition that leads to each, what must be produced, and when it fits. Read it as a sequence of questions: first whether the risk is unlikely, then whether the risk is high, then whether direct contact is possible.

Outcome	Condition that leads here	What the controller must produce	When it fits
No notification, documentation only	The breach is unlikely to result in a risk to individuals, for example because the data were encrypted and the key was not compromised	An internal record of the cause, the data affected, the effects and the remedial action, kept whether or not the breach is notifiable	Encrypted data with an uncompromised key, or a short internal incident with no realistic damage to people
Authority notification only	A risk to individuals is likely, but not a high risk, so Article 33 applies and Article 34 does not	A notification to the competent supervisory authority without undue delay and within 72 hours where feasible, with reasons for any delay, plus the internal record	Personal data were exposed with limited potential damage, such as contact details with no sensitive content and no fraud vector
Authority and individuals	The breach is likely to result in a high risk to individuals, and no Article 34(3) exemption applies	An authority notification within 72 hours and a direct communication to each affected person without undue delay, in plain language	Exposure of financial, health or identity data, or data that enable fraud, discrimination or loss of confidentiality
Public communication	Direct contact with each person would involve disproportionate effort	A public communication, such as a published notice, that is equally effective in reaching the affected people, alongside the authority notification	Large numbers of people whose contact details are unavailable or unreliable, where a direct letter cannot be sent in practice
Exemption from individual communication	Data were unintelligible, the high risk is no longer likely after later measures, or the Article 34(3) conditions are met	Evidence supporting the exemption, such as key management records or the remediation timeline, kept on file for review	Encrypted exfiltration with a secure key, or prompt containment that removes the likelihood of harm
Data subjects missed in a third-party group	Some people whose data were stolen were not identified as affected by the controller's own process	A review of all exposed records, including data held for trusted third parties, and direct information to each high-risk group	Breaches involving records of partners or patients, where the CNIL's 2026 decision found a failure to inform people directly
High-risk-only threshold (proposal)	Under the Digital Omnibus proposal, only breaches likely to result in a high risk would be notifiable to the authority	Not applicable today: the current Article 33 threshold still applies, and the proposal is not law as of October 2026	Plan for the current rule and confirm the status of the proposal with counsel before changing procedures

Which kinds of damage to weigh when judging risk

Recital 85 lists the harms a breach can cause if it is not addressed in time. Each harm below is a question to put to the affected population and the systems involved, and the answers drive whether the risk is unlikely or high.

Loss of control over data

Loss of control means people can no longer decide who sees or uses their data. In a systems breach this often looks like exposed customer profiles, exported mailing lists or copies of records that left the environment. Ask whether the affected people could reasonably expect the data to be private, whether they can still limit its use, and whether the data went to an unknown party or to a bounded group. Evidence includes access logs, export records and what the attacker could read.

Discrimination risk

Discrimination becomes a concern when exposed data reveals attributes that could lead to unfair treatment, such as health status, religion, union membership, or credit and employment history. In a systems breach, look for fields that describe people rather than identify them, such as diagnosis codes or scoring outputs. Ask who could use those attributes against the person and in what setting. Evidence includes the data dictionary for the affected tables and the sensitivity of each field.

Identity theft or fraud

Identity theft or fraud is the harm to check first when account identifiers, national numbers, passport details or authentication data leave the environment. In a systems breach, the typical exposure is a combination of name, date of birth, address and a unique number. Ask whether the data could be used to open accounts, pass verification or impersonate the person, and whether credentials or secret answers were included. Evidence includes which identifiers were exposed and whether they are still valid.

Financial loss

Financial loss covers direct theft of money as well as indirect costs to individuals, such as fraudulent charges or payment card reuse. In a systems breach, look for bank account numbers, payment card data, payroll records or account balances. Ask whether the data would let someone move funds or obtain credit, and whether the people affected can take action to stop it. Evidence includes which financial fields were present, whether they were masked, and whether issuers or banks have been alerted.

Unauthorised reversal of pseudonymisation

Pseudonymised data is only safe while the mapping key stays separate. If the attacker obtained both the pseudonymised dataset and the key, or the means to link them, the protection no longer holds. In a systems breach, check whether tokenisation tables, hash salts, lookup services or re-identification keys were in scope. Ask whether the key was compromised, whether the pseudonyms can be linked back to people, and how the key store was protected. Evidence includes key management records and network segmentation between the data and the key.

Damage to reputation

Reputational damage arises when exposed data reveals conduct, relationships or circumstances that the person would not want shared, such as disciplinary files, counselling notes or private messages. In a systems breach, look for free-text fields, case notes, communications and images. Ask what the data reveals about the person and whether publication is likely. Evidence includes content review of the affected records and any sign that the data has been posted or offered for sale.

Confidentiality under professional secrecy

Data protected by professional secrecy, such as medical records held by clinicians or client files held by lawyers, carries an expectation of confidentiality that is higher than ordinary personal data. In a systems breach, check whether the systems hold records covered by a duty of confidence. Ask whether the disclosure breaches that duty and whether the professional body or sector regulator also needs to be told. Evidence includes the classification of the records and the professional rules that apply to them.

Does encryption remove the duty to notify?

Encryption can remove the duty to notify individuals, but only if the data were genuinely unintelligible to whoever obtained them. Article 34(3) exempts the controller from communicating a breach to data subjects where the data were rendered unintelligible, for example by encryption. The EDPB's Guidelines 9/2022 are direct on the point: a confidentiality breach of data encrypted with a state-of-the-art algorithm is still a personal data breach that must be documented and assessed, but if the decryption key was not compromised, the data are in principle unintelligible and the breach is unlikely to adversely affect individuals. The exemption concerns the communication to people, and the supervisory authority notification still turns on the risk assessment, so the presence of encryption does not settle the whole question on its own.

Before relying on the exemption, the reader should confirm several facts with their own security team and should not assume it applies. Establish which algorithm and implementation protected the data and whether it is current and correctly configured for the data at risk. Establish where the keys were held. If the keys sat on the same compromised system, in the same backup or alongside the stolen files, or were reachable through the attacker's access, the data cannot be treated as unintelligible. Check whether any key material was exposed during the incident, including in memory, logs, configuration files or credentials used by the attacker. Record the answers in the breach register, because the EDPB expects the reasoning behind a no-notification decision to be documented.

Pseudonymised data raise a separate question: whether the organization holds other information that would allow re-identification. Pseudonymisation replaces direct identifiers with a token, but the mapping table or any other dataset the organization controls may reverse it. Ask whether the stolen pseudonymised records could be linked back to people using information the organization or an accessible third party holds, and whether the attacker could obtain that information too. EDPB Guidelines 01/2025 on pseudonymisation is the reference for working through this question, and the reader should test it against their actual data flows rather than against the label on the dataset.

How the risk test changes by breach situation

When an attacker or unauthorized party can read personal data in clear text and has copied it, the starting presumption is the strongest. Confidentiality loss of readable records is the case where the risk to individuals is most easily established, and the assessment turns mainly on the sensitivity of the data, the number of people, and whether the data can be misused for fraud, impersonation or discrimination. Recital 85 damages most likely here are loss of control over personal data, identity theft or fraud, financial loss and damage to reputation. Article 34(3) exemptions rarely help because the data were not rendered unintelligible.

Likely damages: Identity theft or fraud, loss of control and financial loss usually drive the outcome when contact details, identifiers or account data are exposed.
Sensitivity matters: Health, financial, login or special category data raise the risk level even when the record count is small (illustrative: a few hundred patient records with diagnoses).
Exemptions are unlikely: Article 34(3) does not apply simply because access controls existed; the data were readable.
Mitigation after the fact: Later measures such as forced password resets may reduce the risk, but only if they make a high risk no longer likely.
Evidence to keep: Data inventory extracts showing fields exposed, access logs, exfiltration indicators and the reasoning for each conclusion.

Check whether the copied dataset has been identified precisely, because an assessment built on an estimated scope is weaker than one built on confirmed fields and record counts.

Why the decision to tell individuals has its own test

Telling the supervisory authority and telling the affected people are separate decisions with different thresholds. Under Article 33(1), the controller notifies the authority unless the breach is unlikely to result in a risk to individuals. Under Article 34(1), the controller communicates the breach to data subjects only where it is likely to result in a high risk to them. A breach can therefore be notifiable to the authority without requiring any direct message to the people whose data were affected. The two assessments need separate written conclusions.

The CNIL's decision of 3 September 2026 against Hôpital Privé de la Loire shows the cost of skipping the second test. The CNIL imposed a fine of EUR 500,000, and one of the failures it cited under Article 34 was that 202,246 people designated as trusted third parties received no direct information, even though their data were also stolen. Before relying on the details of this decision, check the decision text itself, which the EDPB news report on the fine summarizes. Confirm the scope of the finding and the categories of people it covers.

The practical lesson is that every category of affected person must be assessed, not only the primary customers or patients. Staff, referees, emergency contacts, guarantors and other third parties named in a record can face the same damage types, such as identity theft, fraud or loss of confidentiality. For each breach, list every category of data subject present in the affected systems, assess each one for high risk separately, and record the reasoning in the breach register. Ask your incident response provider and your data protection officer to confirm that this inventory comes from the data mapping, not from the customer list alone.

How to document a breach you decide not to report

This sequence produces a dated record that shows why a personal data breach was judged unlikely to result in risk, so the reasoning can be checked later by the supervisory authority, an auditor or the accountable manager.

Log the breach in the internal register
Open an entry in the internal breach register as soon as the breach is identified, whether or not it is notifiable. The entry records the date and time the organization became aware, the person who logged it and a unique reference that links to the investigation file. Done means the register contains a complete entry with an owner and a status of under assessment.
Record the causes and what happened
The incident lead writes a factual account of how the breach occurred, including the root cause if known, the systems, processes or people involved, and the timeline from initial compromise to containment. Where facts are still unknown, the record says so and states when they will be confirmed. Done means the account can be read by someone with no prior knowledge of the incident.
Identify the personal data and individuals affected
Document the categories of personal data involved, the approximate number of records and data subjects where known, and any special categories or data protected by professional secrecy. Note whether the data were encrypted, pseudonymised or otherwise unintelligible, and whether the keys or other means of reversal were exposed. Done means the data inventory for the breach is attached to the entry.
Assess the likely effects on individuals
Describe the damage the breach could cause individuals if not addressed, using the types listed in Recital 85 of the GDPR such as loss of control, identity theft or fraud, financial loss, discrimination, reputational damage and loss of confidentiality. Explain why each possible effect is or is not likely in this case. Done means each effect considered has a written conclusion attached to it.
Record the remedial action taken
List the containment, recovery and mitigation measures, with the owner and completion date for each. Include any measures that reduced the likelihood of harm, such as revoking credentials, rotating keys or obtaining deletion assurances, and note when each measure took effect. Done means every action is linked to the effect it addresses and its status is current.
Write the reasoning for the risk conclusion
Set out in plain language why the team concluded the breach is unlikely to result in a risk to individuals, or why no communication to individuals is needed. If the decision relies on encryption or on later measures, state the specific facts it depends on. If the notification was made late, the record also gives the reasons for the delay. Done means a reviewer can follow the logic from facts to conclusion without further input.
Obtain approval from the accountable person
Send the completed entry to the accountable person named in the response policy, usually a senior manager or the data protection officer where one is designated. The approver confirms the facts, the risk conclusion and the actions, then records the decision and date. Done means the entry shows a signed or logged approval and any open actions have owners.
Keep the record available to the supervisory authority
Store the approved record in a controlled location with restricted edit rights, and set a review point to reopen it if new facts emerge. Confirm that the record can be produced quickly if the supervisory authority asks for it, and that the retention period follows your records policy. Done means the record is retrievable by reference and a reopening trigger is documented.

What the proposed high-risk-only threshold would change

The current rules still apply. The proposed high-risk-only threshold is not law. The GDPR text has not been amended as of October 2026, so the 72-hour deadline in Article 33 and the unlikely-risk exemption still govern every decision your team makes today. The change under discussion comes from the Digital Omnibus proposal, COM(2025) 837, procedure 2025/0360(COD), which is awaiting committee decision in Parliament. Its aim is to notify the supervisory authority only when a breach is likely to result in a high risk to individuals, and to extend the notification deadline from 72 to 96 hours.

The EDPB-EDPS Joint Opinion 2/2026, adopted on 10 February 2026, supports both elements of the proposal. Supporting an approach is not the same as adopting it, and the opinion does not change your obligations. If the proposal passes in its current form, the practical effect would be fewer notifications to authorities for breaches that carry some risk but not a high one, and a longer window before the clock forces a filing. Your response plan would then need a different first-notification test and a different timer. Your documentation duty would not shrink, because the EDPB's expectation that every breach is recorded in an internal register applies whether or not notification is needed.

Until the legislative text is adopted and in force, keep the 72-hour clock and the unlikely-risk test in your incident response procedure, and label any alternative wording as a draft. Check the Legislative Observatory record for procedure 2025/0360(COD) before each review of the plan, and confirm with your legal counsel or your data protection officer when an amendment is adopted, when it enters into force and whether it has transitional provisions. Treat a change in the record as a trigger to update the plan and retrain the people who make notification decisions, not as permission to relax current practice.

Where breach risk decisions usually go wrong

The notification decision is short, but errors creep in at its edges: when the clock starts, who is counted as affected, how encryption is judged, and whether the reasoning is written down. Each card below names one error, the step that avoids it, the owner, and the record that shows the step was taken.

Starting the assessment too late

The 72-hour window under Article 33(1) runs from the point the controller becomes aware of the breach, so a slow start can consume most of it before anyone decides. Open the risk assessment in the first hours, even before the facts are complete. The incident lead should log the time of awareness, the time the assessment started, and any reasons for a later notification. Evidence: a timestamped incident record and a first-hour assessment note.

Counting only the primary data subjects

Assessments often focus on customers while overlooking third parties whose data were also taken, such as referees, relatives or business contacts. The CNIL's 2026 decision on Hôpital Privé de la Loire included an Article 34 failure for exactly this gap. Map every category of person whose data sat in the affected system. The privacy lead should cross-check the data inventory against the extracted records. Evidence: a list of affected groups with record counts per group.

Relying on encryption without checking keys

Encryption removes the need to notify individuals only where the data are unintelligible to the attacker. Under EDPB Guidelines 9/2022, a breach of data encrypted with a state-of-the-art algorithm is still a personal data breach, and the exemption depends on the key remaining uncompromised. Confirm the key was not stolen, exposed or present on the same compromised host. The security engineer should record where keys are stored and who could access them. Evidence: a key custody review tied to the incident timeline.

Failing to document a decision not to notify

A breach that is judged unlikely to result in risk still has to be documented, and the absence of notification is the decision most often challenged later. EDPB guidance expects the record to cover causes, what happened, the personal data affected, the effects and the remedial action. Write the reasoning for a no-notification decision as carefully as a notification. The data protection officer or privacy lead should sign off the record. Evidence: an entry in the internal breach register with the risk rationale and approver.

Not revisiting the decision

The risk picture changes as forensics progresses, for example when data are found on a leak site or when an attacker's access is shown to be wider than first thought. Article 34(3) also recognizes that later measures can remove a high risk. Schedule a reassessment at each material new fact and record the outcome. The incident manager should trigger the review, and the privacy lead should decide whether the authority or individuals must now be informed. Evidence: dated reassessment entries linked to the forensic findings.

Common questions about GDPR breach notification risk

Can our organization make the notification decision itself?

Yes. Under the GDPR the controller decides whether a breach must be notified, and that duty cannot be handed to a vendor or consultant. Your own staff, usually the security lead working with the DPO or privacy counsel, own the assessment and sign-off. An outside partner can prepare the facts, timelines and draft analysis, but the decision and the record of it stay with your organization. Ask any provider to confirm in writing which tasks they perform and which remain with you.

What does the risk assessment need from our security and legal staff?

The assessment needs two kinds of input. Security staff must establish what happened, which systems and data were affected, whether the data were encrypted and whether the keys were exposed, and what containment has been done. Legal or privacy staff must judge the likely damage to individuals, including the damage types the GDPR recitals list, and decide how the outcome maps to the Article 33 and Article 34 thresholds. Both teams should document their reasoning as it happens, because the file is what a supervisory authority will read.

How long does the risk assessment take relative to the 72-hour deadline?

The GDPR runs the clock from the moment the controller becomes aware of the breach, and the notification is due without undue delay and, where feasible, within 72 hours. The assessment must therefore be fast enough to fit inside that window, or the first notification must explain the delay. How quickly your team can reach a decision depends on how well the incident response plan defines roles, how quickly logs and affected datasets can be identified, and whether key contacts are reachable outside office hours. Test these steps before an incident, not during one.

Do we still need a record for a breach we decide not to notify?

Yes. The GDPR requires every personal data breach to be documented, whether or not it is notifiable, and EDPB Guidelines 9/2022 recommend an internal breach register for this purpose. The record should cover the causes, what happened, the personal data affected, the likely effects and the remedial action taken, together with the reasoning behind a decision not to notify. A well-kept register is also what lets you show a regulator later that the decision was reasoned and consistent.

Does encryption always mean we avoid notification?

No. Encryption helps only when the data are rendered unintelligible and the key was not compromised. EDPB Guidelines 9/2022 explain that a confidentiality breach of data encrypted with a state-of-the-art algorithm is still a personal data breach, but in principle the breach is unlikely to adversely affect individuals if the key stayed secure. If the attacker obtained the key, or the encryption was weak or misconfigured, the exemption fails. Engineers should verify key custody and algorithm choice with their own evidence before relying on this argument.

What would change if the proposed high-risk-only rule were adopted?

Today the GDPR requires notification to the authority unless a breach is unlikely to result in a risk to individuals. The Digital Omnibus proposal would limit that duty to breaches likely to result in a high risk and extend the deadline from 72 to 96 hours. The EDPB-EDPS Joint Opinion 2/2026 supports those changes, but they are not law as of October 2026. Until a change is adopted and in force, keep applying the current thresholds and the 72-hour deadline, and monitor the Legislative Observatory procedure for updates.

What can an implementation partner do in support of the risk decision, and what can it not do?

An implementation partner such as DeployOpen can help prepare the evidence the decision depends on. Within a written, fixed scope, that can include logging and detection configuration, reviewing encryption and key management, building the breach register and notification templates, and running tabletop exercises. It cannot make the notification decision for you, sign the assessment as your DPO or counsel, or issue an audit report or certificate, because only independent auditors and certification bodies do that. Confirm the split of responsibilities in the statement of work before work starts.

How DeployOpen prepares breach records and evidence

DeployOpen helps organizations prepare the breach records and technical evidence needed to support the notify or do-not-notify decision for a personal data breach. The organization makes the risk determination and owns the decision, while DeployOpen prepares systems, logs and documentation so the reasoning can be reconstructed and reviewed.

How we scope

Each engagement starts with a written scope that names the systems, data stores and logging sources covered for breach records.
The scope states which breach register fields, encryption and key-management facts and damage assessments are in or out of the work.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We configure the self-hosted platforms in your own environment so that access, security and processing events are logged and retained.
We set up a breach register template that records causes, what happened, personal data affected, effects and remedial action.
We test that the logs and register fields can actually answer the questions a supervisory authority would ask about risk.

How we hand over

You receive the configured register, runbook steps for the risk assessment and the documented evidence trail for each test.
Documentation explains which facts were checked in the environment and which must still be confirmed by your legal and privacy team.
Decisions on notification, and any reports or certifications, remain with your organization and the independent bodies you choose.

How we support

Ongoing support, upgrades and continuous testing of the breach tooling are available as retainers after handover.
Retainers can cover updating the register, re-testing logging after platform changes and reviewing evidence before an annual review.
Ask any provider to confirm in writing which parts of the decision process they own and which they only prepare.

When to notify a GDPR breach: assessing risk to individuals