A personal data breach can involve loss, unauthorised disclosure, alteration or loss of access, not just hacking. Start a factual incident log, contain the problem and assess the risk to people. A notifiable breach must be reported to the ICO without undue delay and within 72 hours of awareness.
Do not wait for a complete investigation before considering reporting. Record the awareness time, information affected, recipients and likely consequences. High risk to individuals can trigger a separate obligation to inform them without undue delay. Keep the reasons for reporting or not reporting and update the assessment as facts emerge.
Establish what happened and who is coordinating
Create an incident record as soon as a suspected breach is reported. Capture the discovery time, systems involved, known recipients and immediate actions. Separate confirmed facts from assumptions. A lost device, corrupted records or an unavailable case system can affect people even when there is no evidence of an external attacker. Give the incident a named coordinator who can obtain decisions from technical, operational and management staff.
Contain the problem without destroying useful evidence. Revoke an exposed sharing link, suspend a compromised account or isolate an affected device as appropriate to the situation. Preserve relevant logs and messages using a controlled process. Avoid asking staff to circulate the exposed spreadsheet widely to explain the problem; share the minimum incident information needed for each person's role and retain the original evidence securely.
Assess harm to people, not only business disruption
Identify what the information reveals, how many people may be affected and what recipients could do with it. A short list containing sensitive case details may create more serious harm than a larger list of ordinary business contact addresses. Consider loss of confidentiality, discrimination, financial misuse, distress and interruption of an essential service. Record uncertainty explicitly and set a time for reassessment as the investigation develops.
The ICO guidance explains the reporting threshold and the requirement to notify a reportable breach without undue delay and within seventy-two hours of awareness. High risk can require informing affected people without undue delay as well. [1] These are separate decisions. Do not wait for a complete forensic report before evaluating either obligation, and keep a reasoned record where notification is not considered necessary.
Prepare communications that people can use
An initial report should distinguish established facts, likely consequences, containment and outstanding investigation. If details are incomplete, explain that and organise updates. Use a clear internal approval route with a deputy so that a weekend or holiday does not leave nobody authorised to act. Check other reporting or contractual duties separately; notifying the ICO does not automatically notify a client, insurer or another regulator.
Where individuals need information, explain the nature of the incident and practical steps relevant to the actual risk. Avoid generic instructions that create unnecessary alarm or ask people to provide more sensitive information through an insecure channel. Give them a contact route capable of handling questions. Keep a record of the audience and delivery method, especially where some contact details may themselves be unreliable after the incident.
Check supplier involvement and recover safely
Ask a processor for a factual chronology, affected datasets and containment evidence. The supplier's view that an incident is minor does not replace the controller's assessment. Preserve the contract and incident notifications, and establish who will provide updates. Review Data processing contracts with suppliers if assistance obligations are unclear and Access controls for client records when excessive permissions or sharing links contributed to the exposure.
Recovery should include a check that information is accurate, available and appropriately restricted before normal operations resume. Resetting a password does not resolve every persistence mechanism or unauthorised sharing route. Keep temporary workarounds under review so that an emergency spreadsheet does not become an uncontrolled permanent system. Record what has been restored and what remains uncertain for service teams answering customer questions.
Use Data processing agreement review with an incident timeline and a concise list of decisions needed urgently. After containment, identify specific corrective actions, owners and completion evidence. Replace instructions such as improve training with a defined change: a recipient confirmation step, narrower default permissions or a tested escalation route. Review whether the change would have prevented this incident without obstructing legitimate work unnecessarily.
Keep recovery decisions separate from notification decisions
Restoring an account's security does not by itself establish that information was never accessed. Preserve available access logs and record what the investigation can and cannot demonstrate. If a mailbox was compromised, identify potentially affected messages and attachments rather than assuming the password reset closed every consequence of the event.
Maintain a decision timeline with the facts available at each stage. This helps explain why an initial assessment changed when new evidence arrived. Give staff an approved contact for customer questions and update the response as the facts develop. Avoid asking an individual employee to reconstruct a complex incident from memory after technical logs have expired or external support has finished its investigation.
Illustrative scenario
An employee sends a spreadsheet to the wrong customer. The business asks the recipient to contain and delete it, preserves the email evidence and checks what the spreadsheet reveals. Confirmation of deletion is relevant, but the risk assessment also considers sensitivity, recipients and possible harm before deciding notifications.
Preparation checklist
- Record awareness time and establish an incident owner.
- Contain access while preserving relevant evidence.
- Assess people affected and potential consequences.
- Document notification decisions, actions and follow-up improvements.
Frequently asked questions
Does every suspected breach need an ICO report?
Reporting depends on the applicable risk threshold and facts. Every incident still needs prompt assessment and a record of the decision, including the reasons for not reporting.
Can we wait until the investigation finishes?
Do not let investigation delay assessment of reporting deadlines. Use the available facts, identify uncertainties and provide further information through the appropriate process when necessary.
Is a recipient's deletion confirmation enough?
It is relevant evidence, but assess sensitivity, possible access and consequences as well. A reassurance does not automatically establish that there was no risk to affected people.
Who should contact affected customers?
Use an agreed incident communications owner with accurate facts and suitable approval. The message should explain the relevant risk and useful protective steps through a secure, accessible contact route.
Official sources
Sources checked: 8 September 2026. Check the linked guidance for subsequent changes.
General information only. The appropriate action depends on your circumstances and the applicable jurisdiction.
Report a correction