A plain-English checklist for UK charities.
Published 3 August 2026
If you use Beacon CRM, you will have heard from them today about a security incident. Their guidance for customers is here, and that page is the source of truth. Read it.
What follows is not a replacement for it. It is an attempt to answer the question a lot of small charities are asking right now, which is: what does any of this actually mean for us, and what do we have to do?
This applies whichever supplier is involved. The pattern is the same every time, and it is not rare. The government’s Cyber Security Breaches Survey 2025/2026 found that 28% of UK charities identified a breach or attack in the previous twelve months.
The bit that catches people out
Your CRM provider is a data processor. You are the data controller. That distinction sounds like paperwork, but it decides who is on the hook.
It means the regulatory obligation is yours, not theirs. Your CRM provider cannot report this to the ICO on your behalf, and they cannot decide for you whether your supporters need to be told. Those are your calls to make about your data.
That is not your supplier being unhelpful. That is how UK GDPR works, and it would be the same with any provider.
Are you affected?
If you held a Beacon account before 4am GMT on Monday 27 July 2026, assume you are in scope. That includes free trial accounts.
If you signed up after that, you almost certainly are not, but check Beacon’s own page rather than taking our word for it.
Do these things first
Revoke your integrations and API keys. Anything connected to your CRM, including form tools, email platforms, payment integrations and Zapier-style connectors, should be revoked and reconnected. Beacon has a guide for this. Do it before anything else.
Appoint one lead contact. One person collates your organisation’s questions and talks to the supplier. Everyone else routes through them. This is genuinely in your interest, not just theirs. Support queues in an incident are long, and five people asking five versions of the same question gets you answered slower.
Find your own policies. Most charities have a Data Breach and Incident Response Policy, a Data Protection Policy, and possibly a Safeguarding Policy. Whatever you wrote in them, you now need to do. If you have never read them, today is the day.
Decide whether to tell the ICO
You need to report a personal data breach to the ICO unless it is unlikely to result in a risk to people’s rights and freedoms. Note the direction of that test. Reporting is the default. Not reporting is the exception you have to justify.
Whether you clear the threshold depends on what you were actually storing. A mailing list of names and email addresses is a different proposition from case notes, safeguarding records, financial details, or anything revealing health, beliefs or vulnerability. Look at what is in your own database, not at what a CRM could theoretically hold.
The ICO’s guidance on assessing risk is written for small organisations and is readable. There is also a self-assessment tool.
On timing: the clock runs from when you became aware, which for most charities is today. The ICO expects reports without undue delay and within 72 hours where feasible. If you are not sure whether you meet the threshold, phone them on 0303 123 1113. They would far rather talk to you early than find out late.
Decide whether to tell your charity regulator
Separate obligation, separate threshold. Serious incident reporting is a charity law duty, not a data protection one, and trustees own it.
Decide whether to tell the individuals
This is a higher bar than telling the ICO. You only have to contact people directly if the breach is likely to result in a high risk to their rights and freedoms.
Plenty of charities will need to report to the ICO and not need to email their entire supporter base. Work through the ICO test before you draft anything. Mass-emailing 8,000 supporters about a breach that does not meet the threshold creates alarm, damages trust and generates a support load you cannot handle.
If you do need to notify people, tell them: what happened, what categories of their data were involved, what the realistic risk is, and what is being done about it. Plain language, no jargon, no minimising.
One practical trap: if you upload affected contacts to Mailchimp or similar, put them in a new audience. Do not drop them into an existing marketing list.
Tell the people inside your organisation
Trustees and board, first and foremost. Staff and volunteers, so they know what to say if a supporter rings. Then consider funders, local authorities and delivery partners, some of whom may have notification clauses in their agreements worth checking.
The NCSC has good guidance on communicating during a cyber incident.
When the dust settles
The uncomfortable lesson here is that your data protection posture is only as strong as your suppliers’, and you carry the regulatory responsibility for their failures. This is a known weak spot across the sector: the same government survey flagged continuing weaknesses in how organisations manage supply chain risk.
Worth doing, once this is dealt with:
- List every third party holding your supporters’ data. Most charities have more than they think.
- Check what your contracts say about breach notification timescales.
- Enforce 2FA on every system, and check it is actually enforced rather than merely available.
- Write down what you would do if this happened again, while it is fresh.
We are not lawyers and this is not legal advice. If you are unsure about your obligations, speak to the ICO or take proper advice.
If you are a charity trying to work through this and would find a second pair of eyes useful, get in touch. Happy to talk it through, client or not.
