By now, most people working in or around the charity sector will have heard something about the Beacon CRM cyber incident. Over the past week I’ve had several conversations with charity leaders who are trying to work out what it means for them, whether they’re a Beacon customer or not. I wanted to set out, in plain English, what we actually know, how attacks like this typically unfold, and what your responsibilities are as a data controller regardless of which supplier was involved.
I want to be clear from the outset that this isn’t about pointing fingers at Beacon. They provide a well regarded platform used by well over a thousand charities, and by all accounts they’ve responded properly: bringing in external cyber-security specialists, notifying customers, and being upfront that people should assume the worst about what data may have been affected. Any organisation can find itself in this position. What matters now is what charities do next.
The Beacon CRM breach is also a useful reminder that charities remain responsible for the personal data they collect, even when that data is stored by a third-party technology provider.
What happened in the Beacon CRM cyber incident
Beacon became aware of the incident on 29 July and notified customers on 3 August. The current understanding is that compromised login credentials, not a sophisticated technical exploit, were used to gain access to Beacon’s systems, and that copies of database backups were made. Beacon has said customers should assume that all the data held on the platform, including attachments, may have been taken. The company has stated that no payment card details are stored on the platform, which is a genuine piece of good news. But names, addresses, email addresses, phone numbers, dates of birth and donation records could all be affected depending on what each charity holds.
This is the kind of incident often described as a supply chain or third-party cyber attack. The target wasn’t any individual charity’s own systems, it was a shared platform that many charities rely on. That’s an important distinction, and also exactly why it matters so much.
How do CRM and supply chain cyber attacks happen?
Most breaches involving a shared platform like a CRM don’t start with some clever piece of malware. They start with stolen or guessed credentials, often ones that have leaked from a completely unrelated breach years earlier and get reused because someone has the same password in two places. Once an attacker is in, they don’t need to be flashy. They quietly copy what they can, often full database backups, and leave. It can be days or weeks before anyone notices anything unusual, and that’s exactly what seems to have happened here.
The lesson isn’t really about Beacon’s security specifically. It’s about the fact that your organisation’s data can be put at risk by weak credentials (e.g. passwords) anywhere in your supply chain, and multi factor authentication on every system that holds personal data should be considered completely non negotiable at this point.
Your responsibilities as a data controller
This is the part I really want charity CEOs and trustees to take on board. If your charity uses Beacon, or any similar platform, to hold data about your supporters, donors, beneficiaries or staff, you are very likely the data controller for that information under UK GDPR. Beacon is a processor acting on your behalf. That distinction matters because the legal responsibility for deciding whether this is reportable, and for communicating with the people affected, sits with you, not with your supplier.
Practically, that means a few things need to happen fairly quickly if you haven’t already started:
- Work out what data of yours was actually held on Beacon and what categories of personal data might be affected. You can’t make a proper risk assessment without knowing this.
- Decide whether this meets the threshold for reporting to the Information Commissioner’s Office. The general rule is that a personal data breach should be reported unless it’s unlikely to result in a risk to people’s rights and freedoms. Given the nature of what may have been exposed, you then need to assess whether the breach is likely to result in a risk to people’s rights and freedoms. If it is, it should be reported to the ICO as soon as possible and, where feasible, within 72 hours of becoming aware of the breach, so don’t delay that decision.
- Think about whether this needs reporting to the Charity Commission as a serious incident. You should also consider whether the incident needs to be reported to the Charity Commission as a serious incident. The Commission has specifically published guidance for charities affected by the Beacon cyber security incident.
- Consider your duty of care to the people whose data may have been exposed. Even where the risk is judged to be lower, being upfront and clear with supporters about what’s happened tends to go a lot further than staying quiet and hoping it blows over.
- Finally, make sure decisions and the reasoning behind them are properly recorded. If this is ever queried later, you want to be able to show that your trustees and leadership team took it seriously and acted promptly.
What should charities that don’t use Beacon do?
Don’t switch off just because this particular platform isn’t yours. Use this as the trigger to ask a slightly uncomfortable question internally: if our CRM, donor database or cloud platform were breached tomorrow, would we actually know what data was on there, and would we know what to do in the first 24 hours? Most organisations we speak to can’t answer that with real confidence, and that’s a gap worth closing before you’re forced to close it under pressure. The wider issue is third-party cyber risk. Every cloud platform, CRM and technology supplier that holds personal data becomes part of your organisation’s risk picture.
Where we can help
We’ve spent a long time working alongside charities and not for profits on exactly this kind of thing, from data protection compliance to incident response. If you’d like to talk through what this means for your organisation specifically, whether you use Beacon or not, we’re offering a complimentary call with one of our data compliance specialists. No sales pitch, just a straightforward conversation about your risk and what sensible next steps look like. Get in touch to find out more.
Understand your cybersecurity posture
Download our cybersecurity brochure to see how ramsac supports your organisation across the six core elements of cyber resilience: Govern, Identify, Protect, Detect, Respond and Recover. Discover how our services work together to reduce risk, strengthen security and help your business stay resilient.
FAQs: Beacon CRM breach
Beacon became aware of unauthorised access on 29 July 2026 and notified customers on 3 August. Current reporting indicates that compromised credentials were used to access its systems and that copies of database backups were made. Charities using Beacon have been advised to work on the assumption that data stored on the platform may have been downloaded.
Not automatically. Each charity needs to assess the personal data it held in Beacon and the likely risk to the people affected. Where a personal data breach is likely to result in a risk to individuals’ rights and freedoms, it should be reported to the ICO as soon as possible and, where feasible, within 72 hours of becoming aware of it.
In a typical arrangement, the charity will be the data controller because it decides why and how personal information about supporters, donors, beneficiaries or employees is used. A CRM provider will commonly act as a data processor on the charity’s behalf. The precise roles should always be confirmed against the actual contractual and data-processing arrangements.
A charity should assess whether the incident meets the Charity Commission’s serious incident reporting criteria. The Commission has specifically issued guidance for charities affected by the Beacon cyber security incident and says serious incidents should be reported promptly.
The main lesson is that cybersecurity does not stop at your organisation’s own network. Charities should understand what personal information suppliers hold, require appropriate security controls such as multi-factor authentication, review supplier risk regularly and have a clear incident response process ready before a breach occurs.
