Whether you are a Data Protection Officer, an SME owner, or the club secretary with access to member records, you may find yourself dealing with a personal data breach. Knowing what to do — and when to do it — is essential.
This guide outlines a straightforward, compliance-focused approach to data breach response, rooted in UK GDPR principles. It avoids unnecessary complexity but ensures that your organisation can respond lawfully and effectively if a breach occurs.
What Counts as a Personal Data Breach?
Under Article 4(12) of the UK GDPR, a personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
This includes:
- Sending an email to the wrong person
- Losing an unencrypted USB stick
- Exposure of records due to a cyber incident
- Accidental deletion of key customer data
- Systems being accessed unlawfully through phishing
It does not need to involve hacking or criminal intent. A simple error can qualify — if it compromises the confidentiality, integrity, or availability of personal data.
Roles and Responsibilities in a Breach
Every organisation that processes personal data — whether as a controller or processor — must have a clear response structure for breach incidents.
Typical roles include:
- Incident lead: Often the DPO or equivalent, overseeing the breach response
- IT lead: Handling any technical diagnosis or containment measures
- Communications lead: Coordinating contact with affected data subjects, regulators, or stakeholders
- Data owner(s): Those responsible for the records affected
- Record-keeper: Maintaining logs to meet documentation obligations
The business continuity plan should cross-reference this structure, particularly where a data breach forms part of a broader cyber incident or major disruption.
Internal Breach Detection and Triage
Quick identification is critical. Many breaches are detected internally — by staff noticing something odd or systems behaving unusually. Others are reported by third parties, including data subjects.
Organisations should establish:
- A single, clearly communicated breach reporting route
- A triage process to assess the seriousness of the incident
- Criteria for escalation — including legal, operational, and reputational risks
Initial containment might involve revoking access, contacting IT support, or recovering files from backups. In more complex cases, it may require forensic analysis or third-party input.
Notifying the ICO and Data Subjects: When and How
Under the UK GDPR, you must notify the Information Commissioner’s Office (ICO) within 72 hours of becoming aware of a notifiable breach, unless it is unlikely to result in a risk to individuals’ rights and freedoms.
You must also inform affected data subjects where the risk is high — especially if the breach could lead to identity theft, financial loss, or distress.
Notification must include:
- A description of the breach
- The likely consequences
- Steps taken or proposed to deal with the breach
- Contact details for further information
If you decide not to notify the ICO or affected individuals, you must document that decision and your reasoning. This may be reviewed later, particularly if complaints arise.
Documentation and the Burden of Proof
Article 33(5) of the UK GDPR requires organisations to document every personal data breach, regardless of whether it is reportable. The ICO expects to see:
- A description of what happened
- When and how it was discovered
- Actions taken at each stage
- Decision-making rationale (especially around notification)
- Any steps taken to prevent recurrence
This is part of the accountability principle. You must be able to demonstrate compliance, not just assert it.
For smaller organisations, a simple breach log or spreadsheet — with date, summary, outcome, and learning — may suffice. Larger organisations may need formal reports and internal audit trails.
Post-Breach Reviews and Recurrence Prevention
Once the breach has been contained and reported (if required), the focus turns to learning. Even minor incidents should prompt a review.
Key questions include:
- Was the breach preventable?
- Were policies followed — and are they fit for purpose?
- Was staff training sufficient?
- Did the incident response work as intended?
- Is a change in technical or organisational measures needed?
This is where data protection overlaps with risk management and business continuity. A breach is not just a legal issue — it is an operational one. Learning from it helps to improve systems, reduce repeat risk, and build organisational resilience.
How This Fits Within Your Wider Continuity Strategy
A personal data breach may be a standalone event — or part of a wider continuity crisis. Cyber attacks, system outages, or disasters affecting your IT infrastructure may all lead to data loss or exposure.
For this reason, your business continuity plan and disaster recovery plan should both reference the breach response process. Scenarios in tabletop exercises should include data breach events. The organisation’s ability to communicate clearly, maintain legal compliance, and preserve trust during a breach is a key indicator of operational maturity.