Practical incident response

Data breach response playbook

Stay calm and collect the facts

What to do when your organisation—or a provider you rely on—may have suffered a data breach. Start with the facts, protect people, and keep a record of every decision.

Open Incident Watch

If an attack is still in progress, treat this as an emergency.

Use trusted incident-response support and the UK government's reporting route. If money has been stolen, contact your bank immediately. Do not rely on this general checklist instead of professional advice.

Report a UK cyber incident

Act now

These actions apply whether the first warning came from your own systems, a customer, a researcher or a supplier.

Appoint one incident lead

Give one person authority to coordinate technical, legal, operational and communications work. Move sensitive discussions to a trusted channel if normal email or messaging may be affected.

Start the incident record

Record when you first became aware, who reported it, known facts, decisions, owners and times. Keep facts separate from assumptions. The UK GDPR reporting clock may already be running.

Preserve evidence

Protect relevant logs, alerts, emails, system images and supplier notices before they expire or are overwritten. Do not wipe, rebuild or delete affected systems until an incident specialist confirms it is safe.

Contain without losing control

Isolate affected systems where safe, revoke exposed sessions and tokens, block confirmed malicious access, and protect clean backups. Use a known-clean device for sensitive account changes.

Establish what is affected

Identify the systems, people, personal data, business services and suppliers involved. Check whether data may have been viewed, changed, destroyed or made unavailable.

Bring in the right help

Notify senior leadership, your data protection lead, insurer, legal adviser and incident-response provider as appropriate. Check policy and contract conditions before taking actions that could affect cover or evidence.

Response timeline

Work in parallel where you can. The order is a guide, not permission to delay urgent containment or reporting.

First 15 minutes

Confirm there is an incident and appoint the lead.
Start a timestamped record and note when awareness began.
Protect trusted communications and emergency contact details.

First hour

Preserve evidence and contain affected access or systems safely.
Identify critical services, personal data and likely affected people.
Notify internal specialists, insurers and external responders as required.

First 24 hours

Build a working timeline, impact assessment and recovery priority list.
Decide which regulators, customers, controllers or other parties may need notice.
Prepare accurate holding lines without speculation or blame.

Within 72 hours

If the UK GDPR threshold is met, notify the ICO without undue delay and, where feasible, within 72 hours of awareness.
If information is incomplete, report what is known and provide updates later rather than waiting for a final investigation.
Record the reasoning whether you report or not. Tell affected people without undue delay where the risk to them is high.

Recovery and review

Restore from known-clean systems and backups, then monitor for recurrence.
Confirm temporary containment has become durable remediation.
Review root causes, supplier controls, response decisions and lessons with named owners and deadlines.

When a provider suffered the breach

A provider announcement starts your assessment. It does not finish it.

Protect your organisation

Confirm the notice through a trusted provider channel.
Identify affected services, integrations, data flows and onward suppliers.
Revoke or rotate exposed credentials, keys and tokens from a known-clean system.
Restrict affected connections and activate continuity arrangements where proportionate.
Review contracts, data processing agreements, service commitments and insurance conditions.
Begin your own risk assessment; do not wait for the provider's final report.

Ask the provider—in writing

What happened, and when did you first become aware?
Are our services, accounts, systems or data confirmed or potentially affected?
Which categories and approximate volumes of personal data and people are involved?
Was data viewed, copied, changed, destroyed or made unavailable?
Which accounts, credentials, tokens, integrations or onward suppliers are affected?
What containment is complete, what remains at risk, and what should we do now?
What evidence will you preserve, and when will you provide the next written update?

Know your role. A processor must tell its controller about a personal data breach without undue delay. A controller remains responsible for assessing risk and deciding whether the ICO and affected people must be notified.

UK data-protection and incident reporting

Not every security incident is a personal data breach, and not every personal data breach must be reported to the ICO. Every breach must still be assessed and recorded.

Notify the ICO when required

If a personal data breach is likely to create a risk to people's rights and freedoms, notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware. Further information can follow in phases.

Tell affected people when risk is high

Where the breach is likely to create a high risk for people, tell them without undue delay. Explain what happened, likely consequences, what you are doing and practical steps they can take.

Do not wait for certainty. Record when your organisation became aware, make a reasoned initial assessment and update it as facts change. Other rules or contracts may require earlier notifications.

ICO breach reporting guidance ICO self-assessment NCSC incident guidance

Keep one incident record

Use a shared, controlled record and restrict access because it may contain sensitive information. If you would rather not build one from scratch, Incident Watch keeps a timestamped, tamper-evident record alongside the 72-hour clock — on every plan, including free.

When the incident happened, was detected and became known to your organisation
How it was discovered and the systems, locations, suppliers and accounts involved
Categories and approximate numbers of affected people and personal-data records
Known and possible consequences for people and business services
Evidence preserved, containment taken and recovery actions planned
Decisions, owners, approvals and the evidence supporting each decision
Notifications made, contact details used and copies of what was communicated
Reasons for any delay and reasons for reporting or deciding not to report

Store only what the response needs, limit access, and apply an appropriate retention period. Avoid copying exposed personal data into general chat, ticketing or email systems merely for convenience.

Somewhere to keep it: Incident Watch

This page tells you what to do. Incident Watch is where you do it — a live watch for one breach, built around the incident rather than a domain, because a breach usually involves more than one organisation and the person managing it is often not the one who was breached.

A 72-hour countdown from the date you record becoming aware
A tamper-evident record — entries are chained, so a later change to an earlier one can be detected
The organisations involved, each with their role in this incident
Public coverage collected for you, dated, so you see what is new

Free on every plan — one live incident at a time, and you keep access to everything you record whatever plan you are on. Publicly published news and statements only; it is not a substitute for your provider's notifications or your own regulatory assessment.

Open an incident — free

Before you close the incident

□ Confirm recovery from known-clean systems and backups.
□ Monitor for recurrence and follow-on fraud or phishing.
□ Close temporary access and emergency exceptions.
□ Update affected people and authorities when facts change.
□ Assign every corrective action an owner and deadline.
□ Test the revised response plan and supplier controls.