A Data Breach Response Checklist for Charities

Most data breaches at small charities are mundane. A misdirected email containing supporter contact details. An export of beneficiary data left on a personal laptop that turns out to be stolen. A spreadsheet accidentally shared with the wrong sharing setting. None of them require a dramatic response. All of them require a structured one, and the structure must be in place before the breach, because the 72-hour ICO reporting clock does not wait while you write a plan.

The checklist below is the response framework I install with charity teams. It is deliberately simple. The hardest part of breach response is not the technical work; it is making decisions calmly in the first few hours, with incomplete information, on a timetable.

Hour 0 to Hour 2: contain

Stop the harm continuing

Whatever caused the exposure, close it. Revoke the share. Recall the email if possible. Disable the compromised account. Disconnect the affected system from the network. Containment first, investigation second.

Capture what you know

Start a written incident log immediately. Time, who reported, what was reported, what was done, by whom. Every subsequent decision adds to the log. This document is your primary evidence later, both for the ICO and for trustees.

Convene the incident team

A named small group (typically chief executive, data protection lead, IT lead, communications lead). Joined urgently. Meeting cadence agreed (hourly at first, easing as the picture clarifies).

Hour 2 to Hour 12: assess

Establish the scope

What personal data was affected? How many individuals? What categories of data (basic contact, financial, special category, safeguarding)? Was the data encrypted? Can the data be retrieved or is it irrecoverable?

Assess the risk to individuals

The ICO test is whether the breach is likely to result in a risk to rights and freedoms. Factors include the nature of the data, how easily individuals can be identified, the severity of likely consequences, the volume affected, and any special vulnerability of the individuals involved.

Make the reporting decision

Three possible decisions, each documented with rationale:

• Report to the ICO within 72 hours (risk to rights and freedoms is likely).
• Document internally, do not report (no risk, or no personal data involved).
• Report to ICO and notify affected individuals (high risk to rights and freedoms is likely).

Where the decision is finely balanced, report. Late or non-reports that the ICO later judges should have been made attract significantly more scrutiny than over-reports.

Hour 12 to Hour 72: notify and remediate

File the ICO report

The ICO portal accepts initial reports with partial information; you can update as the investigation progresses. The first report should include what is known, the actions taken, the timeline, and any planned mitigations. Filing on Hour 24 with partial information is usually better than filing on Hour 70 with full information.

Notify trustees

The chair and treasurer at minimum within 24 hours of becoming aware. Full board notification depending on severity. Where the incident meets the Charity Commission's serious incident reporting threshold, the trustees are responsible for that separate report.

Notify affected individuals if required

Clear, honest, practical communication. What happened, when, what data was affected, what the charity has done, what the individual can do (changing passwords, checking accounts, contacting their bank). Avoid legal-defensive language; it reads as evasive and damages trust further.

Remediate technically

Patch, change credentials, restore from backups, audit access logs. Where the breach involves a vendor, formal communication with the vendor and review of the data sharing arrangements.

Day 4 to Day 30: stabilise and learn

Communicate with stakeholders

Funders with relevant interest, partner organisations and (where appropriate) the regulator-facing communications. Honest, factual, brief. Speculation in early communications creates more problems than silence.

Run the post-incident review

Within 30 days. Honest assessment of what worked and what did not, by the incident team and by an independent observer where possible. Updates to policies, training and technical controls. Documented and presented to trustees.

Update the response plan

Every breach teaches something. Update the response plan to reflect what was learned. Schedule the next tabletop exercise. Refresh staff training.

What charities most often get wrong

• Treating the discovery hours as IT-only, without convening the wider incident team.
• Delaying ICO notification while seeking complete information.
• Communicating defensively with affected individuals, damaging trust further.
• Failing to notify trustees promptly, leaving them surprised by external coverage.
• Closing the incident without a documented post-incident review and policy update.

Breach response is mostly about doing competent ordinary things on a fast timetable. The dramatic response usually means the calm response was missed earlier.

Pre-breach setup that pays back the first time it is needed

1. A written response plan with named roles, contact details and the 72-hour timetable.
1. A list of systems holding personal data, with owners and access controls.
1. A relationship with an external incident-response or legal contact you can call without procurement delay.
1. An annual tabletop exercise using a realistic scenario.
1. Staff training that covers what counts as a breach and how to report internally within the first hour.

None of these are expensive. All of them compress response time by hours when the incident arrives. Doing the work before the breach is the single most important breach-response decision a charity makes.

Further reading

Data Subject Access Requests: A Survival Guide for Charities | Cyber Security Basics Every Charity Should Have in Place | Charity SEO: The Pages That Actually Rank