A data breach rarely arrives as a neat, confirmed event. It may begin with an unusual login, a misdirected file, a supplier alert, or evidence that an AI system has exposed information beyond its intended audience. Knowing how to respond to a data breach means turning uncertainty into a controlled operational process - quickly enough to reduce harm, but carefully enough to preserve evidence and meet applicable obligations.
For organisations operating across borders, the first 72 hours require more than an IT fix. They require coordinated decisions between technical operations, privacy leadership, legal stakeholders, security, communications and senior management. The quality of that coordination often determines whether an incident remains contained or becomes a wider business, regulatory and customer issue.
Establish control before assigning blame
The first priority is to activate a defined incident response process. Do not allow the affected business unit, IT team or supplier to manage the event in isolation. Appoint an incident lead with authority to convene the relevant teams, set a decision timetable and maintain a single record of actions, findings and approvals.
The initial team should confirm what has happened, what is still happening and who has responsibility for each workstream. At this stage, certainty is limited. Avoid premature statements such as “no personal data was affected” until the evidence supports that conclusion. Equally, avoid treating every security alert as a reportable personal data breach. A security incident becomes a privacy issue where it involves accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
Create an incident log from the outset. Record the time the issue was detected, the source of the alert, systems and suppliers involved, containment actions taken, people assigned, evidence collected and key decisions. This record is not administrative overhead. It gives executives a reliable view of the situation and supports accountability when notification decisions are later reviewed.
Contain the incident without destroying evidence
Containment should reduce further exposure while preserving the information needed to understand the incident. That may involve disabling compromised accounts, revoking tokens and sessions, isolating affected devices, restricting data transfers, pausing a workflow or instructing a processor to stop a particular activity.
The right action depends on the nature of the event. Shutting down a customer-facing platform may be necessary in some circumstances, but it can also interrupt critical services and complicate investigation. Where possible, use proportionate controls first: restrict access, segment the affected environment and strengthen monitoring while technical specialists determine the scope.
Do not overwrite logs, rebuild servers or delete suspicious files before appropriate forensic evidence has been captured. Preserve audit trails, authentication records, system configurations, relevant communications and copies of the affected datasets where safe to do so. If a cloud provider, managed service provider or software vendor is involved, obtain a clear incident contact, request relevant evidence promptly and document its statements rather than relying on informal updates.
Assess the data, people and jurisdictions affected
A meaningful assessment goes beyond counting records. Determine which categories of personal data are involved, whose data is affected, whether the information was encrypted or otherwise protected, who may have gained access, and whether the exposure has been contained.
Higher-risk cases often involve credentials, financial information, government identifiers, location data, health information, children’s data, confidential employee records or information that could facilitate fraud, discrimination or physical harm. A breach involving basic contact details can still create material risk when combined with phishing, account takeover or a sensitive business context.
Cross-border organisations must also map the relevant roles and locations. Identify the controller or controllers, any joint controllers, processors, sub-processors and relevant representatives. Establish where affected individuals are located, where data was processed, and which supervisory authorities or national regimes may be engaged. A single incident may trigger different assessment and notification requirements across the UK, EU, Switzerland, Thailand and other operating markets.
This is also the point to examine whether the incident touches an AI system. Check whether training data, prompts, outputs, model-access logs or system registry records contain personal data. An exposed prompt history, overly broad retrieval permissions or an AI vendor’s compromised environment can create both privacy and AI governance issues. The response should connect the incident to the organisation’s AI system inventory, risk classification and vendor oversight records rather than treating it as an isolated technical defect.
Make notification decisions on evidence, not assumptions
Notification timing is often short, particularly under GDPR and UK GDPR frameworks. However, the clock should drive disciplined fact-finding, not speculation. The incident team needs a documented assessment of the likely risk to affected individuals, the mitigation already in place and the reasons for its notification decision.
Where notification to a supervisory authority is required, submit the available information within the applicable timeframe and provide supplementary details when the investigation develops. A well-managed initial notification distinguishes confirmed facts from information still under investigation. It should explain the nature of the breach, categories and approximate volume of data and individuals involved, likely consequences, mitigation measures and the relevant contact point.
Communication with affected individuals requires a separate judgement. It should be clear, direct and useful, explaining what happened, what data may be involved, practical steps the individual can take and how to obtain support. Generic wording that merely protects the organisation’s reputation is unlikely to help people assess their own exposure.
Decisions should be validated by the organisation’s privacy leadership and relevant legal stakeholders, particularly where multiple jurisdictions, contractual obligations or sector-specific rules apply. The objective is not to produce an overly cautious notification for every event, but to reach a defensible decision using an evidence-based process.
Keep executives informed without creating noise
Boards and executive teams need concise, decision-ready reporting. They do not need a running technical transcript. The incident lead should provide an agreed cadence covering the incident status, known scope, affected operations, regulatory decision points, customer or supplier implications, actions underway, unresolved risks and decisions required from leadership.
A practical executive update separates facts, assumptions and next steps. For example, it may confirm that access to a compromised account has been revoked, state that log analysis is ongoing to establish whether data was downloaded, and identify a deadline for a notification decision. This structure prevents provisional findings being presented as settled conclusions.
Communications teams should be brought in early where external messaging may be needed, but messaging should follow verified facts. Customer account teams, procurement and human resources may also need controlled briefings depending on the people and contracts affected. Everyone communicating externally should work from an approved position to prevent inconsistent disclosures.
Recover services and remove the underlying weakness
Recovery is not simply restoring a system from backup. Before returning to normal operations, establish how the incident occurred and whether the original weakness remains. Review identity controls, privileged access, patching, data retention, access permissions, monitoring coverage, supplier controls and staff processes.
For incidents involving a processor or cloud service, test whether contractual incident procedures worked in practice. Did the supplier provide timely information? Could it identify affected data and environments? Were responsibilities for containment, notification support and remediation clear? A breach often exposes gaps in vendor governance that were invisible during procurement.
Where the incident involved an AI tool, examine whether approved use cases, data handling rules, role-based access and vendor controls were sufficiently defined. Remediation may require updating an AI impact assessment, altering system configuration, restricting certain data inputs or reassessing the vendor’s security and governance position.
Turn the incident into a stronger operating control
A post-incident review should begin once immediate containment and notification work is stable. It should not be a blame exercise. Its purpose is to identify which controls failed, which teams lacked information, where escalation slowed down and what would make the next response more reliable.
Translate findings into assigned actions with owners, dates and evidence of completion. Improvements may include a revised breach playbook, clearer processor notification clauses, better data mapping, tabletop exercises, more detailed logging or a refreshed incident communications protocol. If the organisation operates internationally, ensure that local representative arrangements and escalation paths are tested rather than assumed.
Formiti supports this execution through a three-team model that brings Legal Team, Privacy Team and Technical Operations expertise into one coordinated response structure. For organisations managing obligations across more than 120 countries and 100 regulatory frameworks, that integrated approach helps ensure breach response is connected to ongoing privacy, vendor and AI governance controls.
The best time to decide who can declare an incident, contact a processor, assess risk and brief the board is before a breach occurs. A tested response plan does not eliminate uncertainty, but it gives the organisation a disciplined way to act when every hour matters.