This article accompanies Hour 7: Data Breach Response in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event A: Full-Day Regulatory Privacy Training.

A personal data breach response is often described as a 72-hour exercise. That is understandable, because GDPR and UK GDPR notification duties make timing important. But the clock is only part of the work. A good response also needs disciplined triage, evidence, role clarity, proportionate judgement and calm communication.

The practical question is not only "do we report this?" It is whether the organisation can explain what happened, how it assessed risk, why it notified or did not notify, and what it changed afterwards.

This article is general guidance, not legal advice. Breach decisions are fact-sensitive, particularly where regulatory exposure or individual impact may be significant.

Breach response starts before the breach

The strongest breach responses are rarely improvised in the first hour. They are built from incident routes that staff can find and contracts that require processors to notify promptly.

Under GDPR and UK GDPR, a personal data breach is a security incident affecting the confidentiality, integrity or availability of personal data. It is not limited to cyber intrusion. It may involve a lost device, an email sent to the wrong recipient, ransomware, accidental deletion, unauthorised access, misdirected post, incorrect portal permissions or compromised credentials.

Not every security incident is a personal data breach, and not every personal data breach is notifiable. But every potential breach needs a route that can capture facts, assess risk and preserve the audit trail.

Triage without story-building

Early breach response needs speed, but it also needs discipline. The first job is to stabilise the situation and separate confirmed facts from assumptions.

At triage stage, the organisation should identify what happened, when it was detected, who detected it, what personal data may be involved, whether the issue is still live, what systems or recipients are affected, what containment is needed, and what evidence must be preserved.

This is where organisations often get into difficulty. A confident early story can be tempting: "no data was accessed", "only one person was affected", "the file was encrypted", or "the recipient deleted it". Any of those may turn out to be true. The point is to record what is known, what is unknown and what is being checked.

A breach record should be allowed to say "unknown". It should not say "no risk" simply because the facts are still inconveniently thin.

Containment should run alongside evidence preservation. A system owner may need to disable access, withdraw a link, reset credentials, isolate a device, request deletion from an unintended recipient, restore from backup or pause an affected workflow. Security may need logs, forensic images, email traces or vendor evidence. Legal and DPO input may be needed before external contact is made.

Technical evidence to preserve before it disappears

The privacy assessment is only as strong as the technical evidence behind it. In many incidents, useful logs roll over, admin views change, links are deleted, permissions are corrected, mailboxes are cleaned up, and vendor portals overwrite earlier status information. That means evidence preservation should be treated as an early breach-response action, not as something to tidy up later.

The exact evidence will depend on the system, but common examples include M365 or Google Workspace audit logs, mail headers, message trace records, file-sharing audit logs, SharePoint or OneDrive access histories, cloud storage permissions, CRM or case-management access records, VPN and identity-provider logs, MFA events, privileged-admin activity, SIEM or EDR alerts, firewall or proxy logs, endpoint status, backup and restore records, encryption evidence, device-management records, DLP alerts, vendor support tickets and processor incident updates.

For ransomware, business email compromise and intrusion incidents, the organisation should also ask what evidence exists about initial access, lateral movement, privilege escalation, mailbox rules, suspicious forwarding, data staging, unusual downloads, command-and-control indicators, exfiltration evidence and affected accounts. The privacy team does not need to perform the forensic investigation, but it does need enough reliable output from that investigation to assess confidentiality, integrity and availability risk.

Containment evidence and notification evidence are related, but they are not the same. Containment evidence shows what was done to stop or reduce the incident: disabling accounts, revoking links, rotating keys, restoring systems, removing malicious rules, patching a vulnerability or isolating a device. Notification evidence shows why the organisation reached its regulatory decision: what personal data was involved, who may have been affected, what risk remained after containment, whether technical protections reduced the risk, and whether affected individuals needed to take action.

That distinction matters because a well-contained incident may still be notifiable, and a quickly notified incident may still need better containment evidence. The breach file should preserve both.

A practical response timeline

The exact timeline will depend on the incident, but the discipline should be clear.

Stage Practical focus Evidence to preserve
First hours Detect, contain, preserve evidence, open the breach log, assign owner and assess whether personal data may be involved. Detection time, reporter, initial facts, containment actions, systems affected, logs requested.
0 to 24 hours Establish a working fact base, identify controller / processor roles, affected data and individuals, likely consequences and immediate mitigation. Data categories, approximate volumes, role map, decision notes, security findings, vendor updates.
24 to 48 hours Assess notification threshold, prepare phased notification if needed, draft affected-individual communication if high risk is likely. Risk assessment, DPO / legal advice, regulator draft, individual communication draft, board update.
48 to 72 hours Notify the relevant supervisory authority where required, explain any gaps, and schedule further updates. Submitted notification, reasons for any delay or missing information, update timetable, contact point.
After notification Continue investigation, update regulator and individuals where needed, complete remedial actions and run lessons learned. Final incident report, remedial action evidence, learning review, policy / control updates.

The 72-hour period should not be treated as permission to wait. The legal requirement is to notify without undue delay where notification is required, and where feasible not later than 72 hours after becoming aware. Article 33 allows phased information where needed, but not slow investigation.

Incident pattern matters

Different incident types create different evidence questions. A single generic breach form can miss those differences, so the first assessment should name the incident pattern clearly enough for security, legal and privacy colleagues to test the right facts.

Incident pattern Technical and privacy questions to test
Misdirected email or file What was sent, to whom, whether it was opened, whether recall or deletion evidence exists, whether the recipient is trusted, and whether the content creates risk even if the recipient cooperates.
Exposed folder or permission error Which files were exposed, for how long, who could access them, whether any access or downloads occurred, whether indexing or sharing links widened exposure, and whether permissions are now corrected.
Ransomware or intrusion Whether personal data was accessed, encrypted, exfiltrated, altered or made unavailable; what logs support that view; whether backups are reliable; and whether confidentiality risk remains even after restoration.
Lost or stolen device What data was held locally, whether the device was encrypted, whether remote wipe succeeded, whether credentials were exposed, and whether access tokens or sessions were revoked.
Processor or cloud-vendor incident When the processor became aware, when the controller was notified, what systems and data are affected, what subprocessors are involved, what evidence the processor can supply, and who communicates with regulators or individuals.
Accidental deletion or availability incident Whether personal data was unavailable long enough to create risk, whether backup restoration is complete, whether integrity has been affected, and whether the disruption could affect care, finance, legal rights or access to essential services.

This patterning helps avoid two common mistakes: treating every incident as a cyber incident when the real issue is role, data or communication evidence; or treating an incident as "only technical" when it has already created risk to individuals.

The 72-hour clock is important, but it is not magic

One of the most common breach myths is that the clock starts the moment anyone in the organisation has a vague suspicion. Another is that the organisation can wait until it has completed a full forensic investigation. Neither is a safe working assumption.

The regulator guidance points towards awareness once the controller has a reasonable degree of certainty that a security incident has occurred and compromised personal data. That is a practical threshold. It does not require perfect knowledge, but it does require enough certainty to move from "possible incident" to "personal data breach".

The breach log should therefore show when the issue was first reported, when it was escalated, when personal data involvement was confirmed or reasonably established, and what was done in the meantime. If notification is made after 72 hours, the organisation should be able to explain why. If notification is made within 72 hours with incomplete information, the notification should say what remains under investigation and when further information is expected.

For ransomware, business email compromise, misconfigured access, cloud permission errors and processor incidents, the first facts may be incomplete. That does not suspend the need to assess notification.

Controller and processor roles

Controller and processor role mapping should happen early. The controller carries the primary obligation to notify the supervisory authority where the threshold is met. A processor must notify the controller without undue delay after becoming aware of a personal data breach. In practice, that means the processor contract, support route and incident procedure matter before any incident occurs.

Where an organisation is the controller, it should not assume that a supplier's notification satisfies its own regulatory duties. The controller still needs to assess the breach, decide whether notification is required, communicate with affected individuals where the Article 34 threshold is met, and maintain the record.

Where an organisation acts as processor, it should respect the controller's decision-making role unless the contract or emergency facts require specified action. The processor should provide prompt, usable information on what happened, what data and systems are involved, what containment has been done, and when updates will follow.

Complex supply chains need particular care. The response route should make it clear who is gathering information, who is making the notification decision, and who is authorised to contact the regulator.

Notification to the regulator

The notification threshold is not "all incidents" and not "only incidents where harm has already happened". Under GDPR and UK GDPR, notification to the supervisory authority is required unless the personal data breach is unlikely to result in a risk to individuals' rights and freedoms.

That assessment should consider the nature and sensitivity of the data, affected individuals, whether children or vulnerable people are involved, possible harm, and whether technical controls such as strong encryption meaningfully reduce the risk.

Context matters. A list of names may be low risk in one setting and high risk in another. An availability incident may be low risk for a newsletter system but serious in a health, care, safeguarding, financial or legal context. A ransomware incident may raise confidentiality questions as well as availability questions, especially where intrusion or exfiltration is possible.

Availability-only incidents should not be dismissed too quickly. Temporary loss of access to personal data may be low risk in an administrative system, but high risk where the data is needed for clinical care, safeguarding, payroll, finance, housing, emergency support, legal deadlines or access to essential services. The assessment should test the practical consequence of the unavailability, the length of disruption, whether records were restored accurately, and whether manual workarounds created further confidentiality or integrity risk.

If notification is made, the regulator will expect a clear account of the breach, affected individuals and records where possible, DPO or contact details, likely consequences, measures taken or proposed, and mitigation. If the organisation does not yet know everything, it should say so and provide phased updates.

For UK-facing matters, the relevant route will often be the ICO breach reporting route. For Irish and EU matters, the DPC route, cross-border processing and lead supervisory authority questions may be relevant. The DPC also requires use of its breach notification form.

Communication with affected individuals

Communication with affected individuals is a separate decision. The threshold is higher than supervisory authority notification: communication is required where the breach is likely to result in a high risk to individuals' rights and freedoms.

The purpose is not reputational management. It is to help people protect themselves where they need to do so. The communication should explain the nature of the breach, who to contact, likely consequences, what the organisation has done or will do, and what the individual can do.

The organisation should avoid language that is soothing but unhelpful. "We take your privacy seriously" does not tell someone whether their health data, identity document, payroll information or account access was involved. Equally, speculation may later need to be corrected.

Timing matters here as well. If immediate individual action is needed to reduce harm, individual communication may need to move quickly, even while the wider investigation continues. Legal, DPO, security and communications colleagues should work together so the message is accurate, plain English and aligned with the evidence.

Evidence log: what should survive the incident

Article 33 documentation duties make evidence central. The organisation should document the facts relating to the breach, its effects and the remedial action taken. That applies whether or not the breach is notified.

A practical breach evidence log should include the initial report, detection and awareness timeline, incident owner, affected systems, personal data categories, affected individual categories and estimated numbers, containment actions, security evidence, processor or vendor updates, risk assessment, notification decision, DPO and legal advice, regulator contact, individual communication, remedial actions, final closure decision and lessons learned.

The log should show decision quality rather than just activity. If the organisation decided not to notify, it should explain why the breach was unlikely to result in a risk. If it notified but did not communicate with individuals, it should explain why the high-risk threshold was not met. If it communicated with individuals, it should preserve the message, timing, audience and evidence for the advice given.

That discipline is useful beyond the immediate breach. It supports board reporting, audit, insurance, complaints, DSAR disputes and future regulator engagement. Where breach handling overlaps with complaints or access rights, XpertDPO's note on ICO complaints and DSAR disputes may be useful context.

DPO, legal, security and board roles

Breach response works best when roles are defined before pressure arrives.

Security should lead technical containment and investigation. Legal should advise on privilege, litigation risk, contractual obligations, law enforcement, sector notifications and legal positioning. The DPO should advise on data protection obligations, risk to individuals, notification and communication considerations, and regulator contact. Communications or customer teams may need to prepare external wording. Senior leadership should make sure the response has authority, resources and pace.

The DPO should not be used as a general owner for every breach decision. The controller remains accountable. The DPO advises, monitors and challenges, and may act as a regulator contact point, but operational ownership should sit with the organisation.

Board and executive reporting should avoid both panic and false comfort. Senior stakeholders need a short, accurate position: what happened, what is known, what remains under investigation, whether notification has been made or is being assessed, what immediate actions have been taken, what residual risks remain, and what decisions are needed.

For organisations that need independent assurance around breach handling, Board / Legal Privacy Assurance can help turn a messy incident record into a clearer judgement trail for senior oversight.

Regulator contact should be calm and evidenced

Regulator contact is not a performance. It is a formal accountability interaction. The organisation should be accurate, cooperative and careful about the boundary between facts, current assessment and further investigation.

Good regulator communication has a straightforward shape: identify the controller and contact point, explain what happened, state when the organisation became aware, describe affected data and individuals, set out containment and mitigation, and explain what further information will follow.

Where the incident is still moving, the organisation should avoid absolute statements unless the evidence supports them. It is better to say that a point is under investigation and give an update timetable than to make a premature assurance that later collapses.

The same principle applies to regulator follow-up. If the ICO, DPC or another supervisory authority asks for more information, the response should be coordinated, evidenced and consistent with the breach log. XpertDPO's articles on DPC and EDPB annual reports and EDPB annual report and DPO services give wider regulator-facing context.

Where an organisation needs help preparing or responding to a supervisory authority position, Regulator Response Support may be relevant. For in-house DPO teams, DPO Support can provide an external review point without displacing internal ownership.

Learning review and future controls

The final breach report should not be ceremonial. It should identify root causes, control gaps, lessons learned and action owners. It should also ask whether the incident changes previous risk assessments, DPIAs, supplier reviews, access controls, retention decisions, training, monitoring or contracts.

Some breaches reveal a local error. Others reveal a weak process: excessive access, unclear retention, over-broad sharing, insufficient logging, poor processor reporting, fragile workarounds, weak staff guidance or an old DPIA that no longer describes reality. Where the incident points back to a processing design issue, a DPIA or DPIA review may be needed. XpertDPO's DPIA Support can help where a breach exposes a wider design or governance problem.

The learning review should also test whether the organisation could answer the same questions more quickly next time: owner, evidence log, processor escalation, notification approval, individual communication, senior updates and remedial action tracking.

The best breach response leaves a clear record of responsible judgement while the facts were still developing.

This article is intended to support the learning covered in Hour 7: Data Breach Response in our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, including the related learning materials and course activity, rather than for reading this article on its own. You can return to the course here: CPD Event A: Full-Day Regulatory Privacy Training.

Sources