Data Breach Response

The first call is short and practical. We establish what you have seen, what systems are involved, whether the access appears to be ongoing, and what personal data those systems hold. From that we set an initial scope and decide what to preserve before anyone starts changing things. If the intrusion is live, containment and evidence capture happen almost together.

Establishing “awareness”

Under GDPR the 72-hour notification window starts when you become aware of a breach with reasonable certainty, not when the investigation finishes. Part of triage is fixing that moment honestly and documenting it, because the regulator will ask when you knew and what you did next.

Containment stops the bleeding: revoking the credentials or sessions in use, isolating affected hosts, closing the exposed service, and blocking the attacker’s route back in. We do this in a way that keeps memory, logs and disk artefacts intact. Pulling the plug on a server can wipe exactly the volatile evidence that tells you whether data left the building, so containment is deliberate, not panicked.

Once access is cut, we hunt for everything the intruder left behind. That means web shells, backdoor accounts, scheduled tasks, altered configuration, and any persistence that would let them walk back in after you think it is over. A breach is not resolved because you changed one password. It is resolved when the foothold and every copy of it is gone.

Recovery brings systems back to a known-good state and confirms they are clean before they return to production. Where data was altered or destroyed we work from verified backups. Where accounts were compromised we reset credentials and rebuild trust in your identity systems. Recovery is also when the notification work reaches its decisions, because by now the scope is understood.

The last phase closes the door that let this happen. If a stolen password got in, that points at multi-factor authentication and password policy. If an unpatched service was the way in, it points at patch cadence and exposure management. We give you a prioritised remediation list tied to the specific failure, not a generic checklist.

Common routes are stolen or reused credentials, an exposed and unpatched service, a phishing email that handed over a session, a misconfigured cloud bucket or database left open, and a vulnerable web application. We work from authentication logs, web server logs, cloud audit trails and endpoint telemetry to place the first unauthorised action and trace it forward.

This distinction changes the risk assessment completely. Being able to read a database is not the same as having copied it out, and the notification decision often turns on which one you can prove. We look for egress evidence: large outbound transfers, staging of data into archives, connections to unusual destinations, and query patterns that look like bulk extraction. Where the logs are silent we say so plainly rather than assuming the best case.

When the evidence is incomplete

Sometimes retention was too short and the answer is genuinely unknowable from what remains. That itself is a finding. A regulator would rather see an honest “we cannot rule out exfiltration because logging did not cover this” than a confident claim the evidence does not support. We help you position that correctly.

Article 33 requires notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. The clock is short and it does not pause for weekends. Getting scoping under way in the first hours is what makes a timely, accurate submission possible.

What the notification has to contain

The submission describes the nature of the breach, including the categories and approximate number of data subjects and records concerned; the likely consequences; and the measures taken or proposed to address it. Where you cannot provide everything at once, the regulation allows information in phases. We supply the categories, record estimates and remediation facts so your DPO can complete the form with confidence.

Where a breach is likely to result in a high risk to individuals, Article 34 requires you to communicate it to them without undue delay, in clear language, with advice on how to protect themselves. The risk assessment behind that decision draws directly on the forensic scope: what data, how sensitive, how many people, and whether it was exposed to a party likely to misuse it. We give you the inputs; your counsel makes the call.

Article 33(5) requires you to document every personal data breach, including the facts, its effects and the remedial action, whether or not it was notifiable. Our report is written to serve that record. If the authority ever asks why you decided a breach was not reportable, you have a dated, evidence-based rationale on file instead of a memory.

An executive summary in plain language and a technical body with the timeline, the entry vector, the affected data, the exfiltration finding, and the evidence behind each conclusion. Every claim is traceable to a log line or artefact, so nothing rests on our word alone.

A structured breakdown of data categories, approximate record and data-subject counts, and the remediation status, mapped to what Article 33 asks for. Your DPO can lift this straight into the submission.

A prioritised list of fixes tied to the actual failure, and a free retest once you have applied them so you can show the hole is genuinely closed.