1. Introduction
In today’s data intensive businesses, organizations handle vast amounts of personal data, making them vulnerable to data breaches. A personal data breach can occur due to cyberattacks, human error, or system failures, potentially leading to financial loss, identity theft, or reputational damage. Responding swiftly and effectively is crucial to minimizing harm and ensuring compliance with regulations like GDPR.
This guide provides a step-by-step approach to managing a data breach, from initial assessment to containment, risk evaluation, and reporting. By following these best practices, organizations can protect affected individuals, maintain trust, and fulfill legal obligations.
2. Data Breach Basics:
2.1 What is a Data Breach?
A data breach happens when personal data is lost, stolen, accessed, or shared without permission. This can be due to hacking, human error, or technical failures.
Examples of a Data Breach:
❌ A hacker steals customer names and payment details from your website.
❌ An employee accidentally sends a customer list to the wrong person.
❌ A laptop containing unencrypted customer data is stolen.
❌ A company’s database is exposed due to weak security settings.
2.2 When is it NOT a Data Breach?
Not every security issue is a data breach. If personal data is not exposed or at risk, it’s not considered a breach.
Examples of incidents that are NOT data breaches:
✅ A laptop with sensitive data is stolen, but it’s encrypted, so no one can read the data.
✅ An employee tries to access restricted data but fails due to security controls.
✅ A website goes offline due to a cyberattack, but no data is accessed or stolen.
✅ An email with customer information is accidentally sent but retrieved before being opened.
2.3 What is the threshold for reporting a data breach under GDPR?
It is important to know the whether the personal data breach is likely to result in a risk to people’s rights and freedoms.
What Does This Mean?
- If the breach could cause harm (e.g., financial loss, identity theft, discrimination, reputational damage, or distress), you must report it to the ICO within 72 hours.
- If the breach is unlikely to cause harm, you don’t need to report it, but you must still document it internally.
Example of a Breach That Meets the Reporting Threshold:
🔴 A hacker steals unencrypted customer payment details → Report it to ICO.
🔴 An employee emails a sensitive medical record to the wrong person → Report it to ICO.
Example of a Breach That Does NOT Meet the Reporting Threshold:
🟢 A lost laptop contained personal data, but it was encrypted → No need to report, but document it.
🟢 An email with minor personal details was sent to the wrong person, but they deleted it immediately → No need to report, but document it.
2.4 What are the key differences between UK GDPR and EU GDPR on Breach Reporting
✅ EU GDPR (for EU countries) – Report the breach to the relevant Data Protection Authority (DPA) in the EU country where your business is based or where the breach affects individuals.
✅ UK GDPR (for the UK) – Report breaches to the your local Data Protection Authority(for example, ICO in the UK) if they meet the risk threshold.
If your business operates in both the UK and the EU, you may need to report breaches to both the ICO (UK) and the relevant EU Data Protection Authority.
3. Has the data breach really happened?
This phase, often referred to as the Initial Assessment Phase, serves as the foundation for the entire data breach response process. The goal here is to determine whether the reported incident is actually a data breach or a false alarm. During this phase, you should:
- Conduct a Preliminary Review: Quickly evaluate the reported incident, looking for clear signs of a breach, such as unauthorized access, data leaks, or system anomalies.
- Verify the Source: Ensure that the source of the report is credible. It could come from employees, automated monitoring tools, or external sources like third-party vendors. Cross-check any external alerts or logs that might confirm unusual activity.
- Gather Evidence: Collect logs, alerts, or system monitoring data to investigate the potential breach. This can include network traffic, access logs, or error reports. For instance, you might find evidence of an external IP address trying to access restricted data or unusual login times.
- Determine the Nature of the Incident: Not all incidents qualify as a data breach. For example, a server crash that results in temporary downtime does not constitute a breach, but an unauthorized user accessing personal data without permission would.
- Example Scenarios:
- Scenario 1: A staff member reports that they accidentally sent an email with sensitive data to the wrong recipient. This could be a breach, but you would need to verify whether the recipient was unauthorized and if any sensitive data was exposed.
- Scenario 2: An alert from a security tool shows failed login attempts from an unfamiliar location. Upon further investigation, it turns out to be a result of a configuration issue, not a breach.
- Scenario 3: A user notices that their login credentials were used from an unfamiliar location. This could suggest a compromised account, but you need to determine if the breach was a result of poor password management, phishing, or a malicious external actor.
- Document Findings: Regardless of the outcome, document all observations, evidence, and decisions made during this phase. If the incident is found to not be a breach, document the reasons for closure and the corrective actions taken. If it is a breach, note all indicators that confirm the breach has occurred and prepare to move to the next phase.
Example of Documentation:
- “Initial report from user X regarding unusual activity on their account. Upon reviewing system logs and access history, it was determined that the activity was a result of a system glitch rather than unauthorized access. Incident closed with no further action required. Logs and findings were documented.”
4. Find Out What has Happened – Pull the Facts Together as Quickly as Possible
The first critical step in handling a data breach is to gather all relevant facts about the incident as soon as possible. Documenting accurate details quickly helps you understand the scope of the breach and begin responding appropriately.
What Happened and Why
- What caused the breach?
- Example 1: “An employee accidentally sent an email with customer data to the wrong recipient due to an incorrect email address.”
- Example 2: “A hacker exploited a vulnerability in our website’s security and gained unauthorized access to user data.”
- Why did it happen?
- Example 1: “The employee was not familiar with the procedure for handling sensitive data and did not double-check the recipient’s address.”
- Example 2: “The security flaw was due to outdated software that had not been patched, which allowed the attacker to bypass our firewall.”
How Many People Were Involved
- Affected Individuals
- Example 1: “Approximately 500 customers’ names, email addresses, and shipping details were exposed.”
- Example 2: “Over 1,000 user accounts were accessed, with usernames, passwords, and payment information compromised.”
- Involved Staff
- Example 1: “The breach involved 2 employees—one who made the mistake and another who noticed the incident but didn’t report it immediately.”
- Example 2: “The breach was caused by an external hacker, but the IT team was involved in responding to the breach.”
Timeline of Events
- Date/Time Breakdown
Record a timeline of key events to track when and how the breach unfolded. This helps you determine if it meets the 72-hour notification requirement under GDPR.- Example 1:
- March 1, 2025, 10:00 AM: Employee accidentally sends email with sensitive data to wrong recipient.
- March 1, 2025, 11:30 AM: Employee notices error but doesn’t report immediately.
- March 2, 2025, 9:00 AM: IT department investigates after receiving an alert about a potential security vulnerability.
- March 2, 2025, 12:00 PM: IT confirms that the email was sent to an external recipient.
- March 3, 2025, 3:00 PM: Notified affected customers via email.
- March 4, 2025, 10:00 AM: Reported breach to ICO within 72 hours.
- Example 2:
- March 4, 2025, 8:00 PM: Hacker exploited outdated software vulnerability and accessed customer database.
- March 5, 2025, 2:00 AM: Security alert triggered, and IT team begins investigating.
- March 5, 2025, 9:00 AM: IT confirms unauthorized access and takes immediate action to secure the system.
- March 5, 2025, 10:00 AM: Data Protection Officer notified and breach report initiated.
- Example 1:
Actions Taken So Far
- Communication Actions
- Example 1: “Notified affected customers via email, advising them to change their passwords and monitor their accounts for suspicious activity.”
- Example 2: “Informed all employees about the breach and initiated additional training on data handling protocols.”