Most enterprise buyers now ask for hard proof that their suppliers know how to handle security incidents. A sales deal can stall when a vendor’s breach‑handling plan looks flimsy, even if the team has completed other compliance certifications. Under the General Data Protection Regulation (GDPR), one of the most important obligations is notifying regulators and individuals when a personal data breach occurs. This GDPR Breach Notification Guide explains what counts as a breach, when and how to report it, and how to build repeatable processes that satisfy auditors and enterprise clients.
What is a “personal data breach”?
A personal data breach is any security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. Under the UK regulator’s guidance, breaches include unauthorised third‑party access, accidental exposure by a processor, sending data to the wrong recipient, losing or having devices stolen, altering data without permission and losing availability of personal data. Crucially, not every security incident is reportable. GDPR requires notification only when the breach is likely to result in a risk to the rights and freedoms of natural persons. Encrypted data with uncompromised keys or minor exposure that poses no real harm may not need external reporting. This distinction helps avoid overwhelming regulators with trivial reports and focuses attention on incidents that could hurt people.
Difference between a personal data breach and a reportable breach
A personal data breach is a factual occurrence: an event that compromises confidentiality, integrity or availability of personal data. A reportable breach is one that meets the GDPR’s risk threshold. The European Data Protection Board (EDPB) explains that a breach should be notified to the supervisory authority unless it is unlikely to result in a risk to individuals. Varonis’ legal analysis notes that many common breaches – such as exposing sensitive personal data or stealing a device with unencrypted data – will cross that threshold. However, where data is encrypted with state‑of‑the‑art algorithms and keys remain secure, notification is generally not required.
Key concepts: controller vs. processor
A controller decides why and how personal data are processed, while a processor acts only on the controller’s instructions. Article 33 of GDPR requires processors to notify controllers of any personal data breach without undue delay. Controllers then determine whether to notify the supervisory authority and affected individuals. In practice, enterprise-facing vendors often act as processors for their clients’ data; understanding these roles clarifies who must make which notifications.
Legal obligations under Articles 33 and 34
Article 33 – notification to the supervisory authority
Article 33 demands that controllers notify the relevant supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a breach. If notification occurs after 72 hours, the controller must explain the delay. The notification must include:
- A description of the breach, including categories and approximate numbers of affected data subjects and records.
- Contact details for the data protection officer or another point of contact.
- An outline of the likely consequences of the breach.
- A description of the measures taken or proposed to address the breach and mitigate its adverse effects.
If the controller cannot provide all information at once, Article 33 allows phased notifications as details emerge. Regardless of whether a breach is reportable, controllers must document the facts, effects and remedial actions so that supervisory authorities can verify compliance.
Article 34 – communication to data subjects
Article 34 requires controllers to inform affected individuals without undue delay when a breach is likely to result in a high risk to their rights and freedoms. The communication must describe the nature of the breach in clear language and include the information listed in Article 33(3) – likely consequences and measures taken or proposed. Notification may not be required when:
- Appropriate technical and organisational measures render data unintelligible (e.g., encryption).
- Subsequent measures eliminate the high risk.
- Individual notification would require disproportionate effort; in such cases, public communication is permitted.
Supervisory authorities can compel notification if they believe the risk remains. Failure to notify can attract fines up to €10 million or 2% of global annual turnover for lesser breaches and €20 million or 4% for serious or repeated violations.
Why breach notification matters for enterprise‑selling companies
Enterprise customers often incorporate stringent breach‑notification clauses into data processing agreements and security addenda. They require vendors to detect incidents quickly, assess risk and provide detailed reports within contracted timeframes. Breach handling is a key part of due diligence; buyers want evidence that their partners can identify, contain and communicate incidents without chaos. A mismanaged breach can expose personal data, disrupt operations and derail sales cycles. According to IBM’s 2025 Cost of a Data Breach Report, the global average breach cost fell to USD 4.44 million due to faster containment, but costs in the United States rose beyond USD 10 million due to higher regulatory penalties. The report warns that ungoverned AI systems contributed to breach costs and that 97% of organisations experiencing AI‑related breaches lacked proper access controls. For enterprise vendors, failing to control data exposures not only risks GDPR fines but can also trigger contract penalties, lost business and reputational damage.
When is notification required?
Threshold for notifying the supervisory authority
Under Article 33, controllers must notify the supervisory authority within 72 hours unless the breach is unlikely to result in a risk to individuals. The EDPB guidelines stress that controllers should have technical and organisational measures to immediately establish whether a breach has occurred and to inform authorities promptly. A controller becomes aware of a breach when there is a reasonable degree of certainty that personal data has been compromised. This means that initial investigations can take time, but once a company knows with reasonable certainty, the 72‑hour clock starts.
Factors indicating risk include the nature and volume of personal data, number of individuals affected, sensitivity of the data and the potential for identity theft, discrimination or financial harm. Varonis notes that loss of availability due to ransomware is considered a breach and is reportable when it significantly impacts individuals’ access to their data. Conversely, if data is fully encrypted and keys remain secure, reporting may not be necessary. Even when external notification isn’t required, Article 33(5) obliges controllers to document the incident.
Threshold for notifying data subjects
Article 34 requires notifying individuals only when the breach is likely to result in high risk to their rights and freedoms. Examples of high‑risk situations include:
- Exposure of financial identifiers (e.g., credit card numbers) that could lead to fraud.
- Breaches involving special categories of data, such as health records or biometric identifiers.
- Large‑scale exposure of contact data for vulnerable individuals, such as children or victims of abuse.
- Loss of availability that prevents individuals from accessing essential services (e.g., inability to access health records or salary information).
A minor breach affecting a small number of records or involving encrypted data may be documented internally without contacting individuals. However, the analysis must be documented to show why it was considered low risk.
Documentation requirements
Even when no external notification is required, controllers must record facts, effects and remedial actions. These records support audits, insurance claims and contractual obligations. They also form part of the accountability principle under GDPR and may be requested by supervisory authorities during investigations. Maintaining incident logs and risk assessments ensures that decisions about notification are defensible.
Step‑by‑Step Breach Notification Process
For busy teams selling to enterprise clients, the following steps provide a practical framework. They integrate GDPR requirements with broader security and compliance best practices.
Step 1: Detection & initial assessment
Modern security monitoring, intrusion detection and data loss prevention tools should alert the security team to anomalies. NIST’s 2024 guide on data confidentiality emphasises the need to detect losses of data confidentiality and respond quickly. Assign an incident response team comprising IT/security, legal, communications and an executive sponsor. Their first tasks are to contain the incident: isolate affected systems, preserve logs, reset credentials and ensure evidence is collected for investigation and remediation.
Step 2: Scope & impact analysis
Next, determine what data was involved. Catalogue the personal data categories affected (identifiers, financial information, health data), estimate the number of individuals impacted and assess whether the incident affects availability, integrity or confidentiality. Consider the likelihood of identity theft, discrimination or other harm. Engage legal counsel and the data protection officer to interpret the risk to rights and freedoms. For enterprise vendors, coordinate with clients to assess shared data and confirm contract obligations.
Step 3: Decide whether notification is required
Apply the GDPR’s risk threshold. Ask whether the breach is likely to result in a risk to individuals. Use a checklist:
- Sensitive data? Does the breach involve financial, health or other sensitive categories?
- Volume and scale? How many individuals are affected? Is it a small batch of test data or millions of customer records?
- Vulnerable individuals? Are children, patients or other vulnerable groups affected?
- State of data? Were the records protected by strong encryption? If so, was the key compromised?
- Potential harm? Could the breach lead to identity theft, financial loss or other significant harm?
If the risk threshold is met, prepare notifications to the supervisory authority (Article 33) and potentially to data subjects (Article 34). If not, document the rationale for not notifying.
Step 4: Notify the supervisory authority
Prepare a clear, factual report to the supervisory authority. Include the nature of the breach, categories and approximate numbers of affected individuals and records, contact details of the data protection officer or point of contact, likely consequences and measures taken or proposed. Submit the report within 72 hours of becoming aware of the breach. If some details are missing, provide available information and note that a follow‑up will supply further details. Maintain copies of all communications for audit purposes.
Step 5: Notify affected individuals
If the breach poses a high risk, communicate with data subjects without undue delay. Use clear and plain language; avoid technical jargon and explain what happened, what information was involved, the potential consequences and the steps being taken to mitigate harm. Provide contact details of the data protection officer or a support channel and advise individuals on how to protect themselves (e.g., monitoring credit reports, changing passwords). Notifications should be direct (email, SMS or mail), unless this requires disproportionate effort; in that case, a public announcement may be acceptable.
Step 6: Internal documentation & post‑incident review
Regardless of notification decisions, document every breach. Article 33(5) requires recording the facts, effects and remedial actions. Conduct a root‑cause analysis to identify control failures—whether technical (e.g., unpatched systems), procedural (e.g., misconfigured permissions) or human (e.g., social engineering). Update policies, procedures and technical controls accordingly. For enterprise vendors, update contractual commitments and service‑level agreements (SLAs) with clients if new measures are added.
Step 7: Communication & stakeholder management
In enterprise settings, breach communications go beyond regulators and individuals. Notify affected clients, board members, insurance providers and, if relevant, stock exchanges. Provide consistent messaging across teams: legal, public relations, customer success and sales should work from the same facts to avoid misinformation. Transparent communication helps maintain client trust and reduces reputational harm.
Step 8: Preventive steps & continuous improvement
A strong breach notification process sits on top of a proactive security programme. Regularly test incident response plans through tabletop exercises. Implement continuous monitoring of access, vulnerability management and vendor risk. Perform periodic risk assessments and Data Protection Impact Assessments (DPIAs). Keep the data protection officer or equivalent accessible and empowered. This iterative approach aligns with Konfirmity’s philosophy: start with security and arrive at compliance. After participating in more than 6,000 audits, Konfirmity’s experts find that well‑designed controls reduce the time needed to prepare for SOC 2 or ISO 27001 audits to 4–5 months, compared with 9–12 months when organisations self‑manage, saving hundreds of internal hours.
CTA: Book a demo
Real‑world examples and lessons
Example 1: Ransomware at a service provider – reportable breach
In June 2025, SimonMed Imaging, one of the largest medical imaging providers in the United States, discovered that attackers had exfiltrated data between January 21 and February 5. The breach involved names, addresses, birth dates, medical record numbers, diagnostic information and insurance details. Approximately 1.27 million individuals were affected. SimonMed reset credentials, enforced multifactor authentication, tightened endpoint monitoring, limited vendor access, reported the breach to authorities and offered credit and identity protection services. Because the breach involved sensitive health data and posed a high risk to individuals, it required notification under Article 33 and Article 34. For enterprise‑selling teams, the case underscores that ransomware attacks can quickly become reportable breaches, especially when large volumes of sensitive data are involved.
Example 2: Minor exposure of encrypted data – documentation only
A SaaS provider discovered that an employee accidentally emailed a list of anonymised, fully encrypted user IDs to a personal account. The encryption keys were never exposed. After an internal investigation confirmed that the data remained unreadable and there was no additional risk, the controller documented the incident and concluded that no external notification was required. This example illustrates how strong encryption and swift containment can prevent an incident from becoming a reportable breach. Nevertheless, the incident still needed to be logged under Article 33(5) to demonstrate due diligence during audits.
Example 3: Vendor breach impacting an enterprise client – how Discord responded
In October 2025, communications platform Discord reported a breach involving its customer support vendor 5CA. The attack did not compromise Discord’s internal systems but exposed data of about 70,000 users who had interacted with support. Leaked information included government ID images, names, usernames, email addresses, limited billing data, support conversations and IP addresses. Discord immediately revoked the vendor’s access, launched an internal investigation, engaged a digital forensics firm, notified law enforcement and data protection authorities and directly contacted affected users. This response highlights how supply‑chain breaches can spill over into customer data. For enterprise vendors, the case emphasises the importance of monitoring third‑party access, auditing vendors and having clear breach clauses in contracts.
Templates and checklists for busy teams
Template A: Notification to the supervisory authority (Article 33)
Use the following fields when drafting notifications:
Template B: Notification to data subjects (Article 34)
Key elements to include:
- Plain language description of what happened, when it occurred and what personal data were involved. Avoid technical jargon.
- Likely consequences of the breach for individuals (e.g., risk of fraud, phishing or identity theft).
- Measures taken to mitigate harm and what further actions are planned.
- Actions individuals should take to protect themselves, such as changing passwords, monitoring account statements or placing fraud alerts.
- Contact details of the data protection officer or support team to address questions.
Internal checklist
- Recognise a breach: Ensure staff are trained to report any suspected incident immediately.
- Activate incident response: Assemble the cross‑functional team and contain the breach.
- Assess risk: Evaluate data categories, volume and potential harm; involve legal and DPO.
- Decide on notification: Use thresholds to determine if notification is required; document decisions.
- Prepare notifications: Draft messages for authorities and individuals; use the templates above.
- Notify stakeholders: Inform enterprise clients, insurers, board members and other stakeholders.
- Record everything: Maintain a breach log with timeline, decisions, communications and remediation steps.
- Review and improve: After closing the incident, perform a post‑mortem and update controls.
Special considerations for enterprise‑client selling companies
1) Vendor and third‑party risk
When acting as a processor or sub‑processor, you must adhere to the breach‑notification clauses in your client contracts. These often require stricter timelines or specific reporting formats beyond GDPR’s 72‑hour window. Contracts may include audit rights, service‑level agreements and penalties for delayed reporting. Implement vendor‑risk management processes to assess your own suppliers’ security practices and ensure they notify you promptly if they suffer a breach.
2) Multi‑jurisdiction compliance
Companies serving enterprise clients outside the EU may need to comply with other privacy laws. For example, the HIPAA Breach Notification Rule in the United States requires reporting health data breaches to the Department of Health and Human Services and to affected individuals within 60 days. State laws may impose even shorter deadlines. Similarly, the UK’s Data Protection Act mirrors GDPR’s 72‑hour rule but includes additional obligations for communications providers. A coordinated incident response plan should map these obligations across jurisdictions and ensure timely notifications.
3) Supply‑chain breaches and shared responsibility
Supply‑chain attacks, such as the Discord/5CA incident, show that a vendor’s weakness can expose an entire client base. Enterprise customers expect their vendors to monitor third‑party access, enforce least‑privilege principles and conduct regular security assessments. Contracts should clarify who notifies whom in the event of a vendor breach, and vendors should maintain clear procedures for revoking access and notifying clients quickly.
4) Data subject rights in enterprise contexts
When serving enterprise customers, the volume of data subjects may be large. Fulfil data subject rights (access, rectification, erasure) efficiently by designing systems to retrieve, update or delete records quickly. During a breach, be prepared to handle high volumes of data subject inquiries and to provide clear, consistent information.
5) Competitive advantage through compliance
A mature breach‑notification process can differentiate you in enterprise sales. Buyers increasingly request detailed security questionnaires, SOC 2 or ISO 27001 reports and demonstration of incident‑response capabilities. Konfirmity’s experience shows that vendors with continuous monitoring and documented controls pass due‑diligence faster and close deals sooner. Effective breach handling is not a check‑the‑box exercise; it builds long‑term trust and reduces financial risk.
Best practices and lessons learned
- Embed breach notification into your incident response plan. Ensure roles, responsibilities and decision criteria are documented and rehearsed.
- Perform regular tabletop exercises. Simulated breaches expose gaps in communication and decision‑making. Use scenarios relevant to your industry and clients.
- Maintain comprehensive logs and evidence. Collect system logs, audit trails and access records to support investigations and demonstrate compliance.
- Implement strong security measures. Encryption, segmentation, multifactor authentication and vulnerability management reduce the likelihood of a breach reaching the reportable threshold. Under GDPR, insufficient technical and organisational measures were among the top reasons for fines.
- Identify and empower a data protection officer. The DPO coordinates compliance, advises on risk assessments and serves as the contact point for authorities and individuals.
- Integrate breach notification into vendor management. Assess suppliers’ incident‑response capabilities and include contractual terms requiring timely notification and cooperation.
- Leverage human‑led managed services. Konfirmity’s approach couples experienced security professionals with automated tooling to manage controls year‑round. This reduces internal effort—around 75 hours per year for a managed programme versus 550–600 hours when self‑managed—and delivers higher audit pass rates.
CTA: Book a demo
Conclusion
GDPR’s breach‑notification provisions are not just legal formalities; they protect individuals and build trust with enterprise clients. A well‑designed GDPR Breach Notification Guide enables teams to act swiftly when incidents occur, avoid rushed decisions and provide regulators and customers with clear, factual information. Preparation is crucial: implement detection and containment controls, train teams, maintain templates and logs and practise your response through exercises. Investing in a human‑led, managed security programme, like Konfirmity’s, reduces internal workload and ensures that controls operate year‑round. In a market where privacy expectations and penalties are rising, security that works under pressure is a competitive advantage. Start with robust controls, document your processes and let compliance follow.
Frequently asked questions
1) What is the difference between a personal data breach and a reportable breach under GDPR?
A personal data breach is any incident that compromises the confidentiality, integrity or availability of personal data. A breach becomes reportable when it is likely to result in a risk to individuals’ rights and freedoms. Encrypted data with intact keys or trivial incidents may not meet this threshold.
2) When does the 72‑hour notification timer start?
The timer starts when the controller has a reasonable degree of certainty that personal data has been compromised. Initial investigations may take time, but once awareness exists, the organisation must notify the supervisory authority without undue delay and, where feasible, within 72 hours.
3) Do we always have to notify data subjects if a breach occurs?
No. Article 34 requires notifying data subjects only when the breach is likely to result in a high risk to their rights and freedoms. If encryption or other measures render data unintelligible or subsequent measures eliminate the high risk, individual notification may not be necessary. However, the controller must always document the decision.
4) What happens if we miss the 72‑hour deadline?
Delayed notification must be justified to the supervisory authority. Unjustified delays can attract administrative fines up to €10 million or 2% of global turnover. Regulators consider the nature, gravity and duration of the infringement when determining penalties.
5) How do we decide whether a breach is likely to result in a risk to the rights and freedoms of natural persons?
Assess the sensitivity of the data, the scale of the breach, the vulnerability of the individuals involved and the potential consequences (e.g., identity theft, discrimination, financial loss). Recital 87 emphasises that organisations should implement measures to identify breaches quickly and assess risks. If in doubt, consult your data protection officer and legal counsel.
6) What should we include in our breach‑notification letter to the supervisory authority?
Include the nature of the breach, categories and approximate numbers of affected data subjects and records, contact details for the DPO, likely consequences and measures taken or proposed. If information is not available immediately, provide it in phases.
7) Can we notify in phases?
Yes. Article 33(4) allows phased notifications when not all information is available. Provide initial details as soon as possible and follow up with complete information without undue further delay.
8) Does encryption always exempt us from reporting?
Not necessarily. If personal data are encrypted with strong algorithms and the key remains secure, the breach is unlikely to pose a risk and may not require notification. However, if encryption keys are compromised or if metadata (e.g., account structures or pseudonyms) could still identify individuals, reporting may still be necessary. Always document the risk assessment.
9) How does GDPR apply to vendors servicing enterprise clients outside the EU?
GDPR applies to any organisation that processes personal data of individuals in the EU, regardless of where the organisation is based. Vendors serving global clients must map data flows and understand which jurisdictions’ laws apply. For example, a U.S. healthcare provider may need to comply with both HIPAA’s 60‑day breach notification rule and GDPR’s 72‑hour requirement when processing EU patients’ data. Multi‑jurisdiction plans should align the strictest requirements and clarify in contracts who is responsible for notifying authorities and individuals in each region.
10) What documentation must be maintained even if no notification is required?
Article 33(5) obliges controllers to document any personal data breaches, including facts, effects and remedial actions. Maintain incident logs, risk assessments, decision records and communications. These records support accountability, audits and contract obligations and may be requested by supervisory authorities.
.svg)
.svg)
.svg)