Your CRM provider has had a security incident. What now?

Last updated: Thursday 6 August 2026.

A plain-English checklist for UK charities covering the Beacon CRM security incident.

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.

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.

Check your insurance. If you hold cyber cover, most policies require you to notify the insurer within a set window, and late notification can affect the claim. Do this before you spend money on external help, because some policies require you to use their panel.

What is actually at risk

You cannot assess risk without knowing what the data is useful for. Beacon has said there is no evidence card details were compromised, and that is worth knowing. It is also the smallest part of this.

A card is the only thing in that record you can cancel. Names, addresses, giving histories and the fact that somebody supports your organisation cannot be reissued.

The main risk is credibility, not money. A generic scam email is easy to ignore. One that mentions the £15 a month somebody has given since 2019, or the fundraising dinner they attended in March, is not. That is what this data is worth to whoever has it: it makes the next approach believable. The most useful thing you can tell your supporters is that correct details do not mean a message is genuine.

Money can still move without card numbers. Direct Debit mandates, bank details in attachments and Gift Aid declarations are all routine in a charity CRM. A Gift Aid declaration is a full name, a home address and a statement that somebody is a UK taxpayer. Put that alongside donation amounts and you have the raw material for identity fraud, or for a convincing phone call that appears to come from a bank.

For charities, the relationship itself can be the sensitive information. In most breaches the harm sits in the fields. Here, a lot of it sits in the fact of being on the list at all. Consider what it reveals to be in the supporter database of a hospice, an HIV charity, an addiction service, a domestic abuse charity, an LGBTQ+ organisation or a faith group. Nobody had to record a health condition or a sexuality for that data to be revealing. It is revealing by association, and special category data can end up in your hands by implication without anybody ever typing it into a field.

Beneficiaries are the harder case. If your account does case management you may hold support notes, safeguarding records, or an address for somebody who left a dangerous relationship and does not want to be found. That risk is not financial and it is not reversible. You cannot judge it by looking at a list of database fields.

Your organisation is a target too. Criminals know which charities were affected. Impersonation cuts both ways: supporters can be approached in your name, and your finance team can receive a plausible email about changing bank details for a supplier. Worth a word with whoever pays your invoices.

There is no evidence any of this data has been published or misused. That is not the same as an all-clear. Stolen data keeps.

That list is your risk assessment. It is not an abstract exercise. Those are the harms you are weighing when you decide whether this needs reporting and whether people need telling.

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 was Monday 3 August. If you are already past 72 hours, you still report. You explain the delay. Late is recoverable, absent is not. 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.

• Charity Commission for England and Wales
• OSCR (Scotland)
• Charity Commission for Northern Ireland

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.

If you are telling people, what good looks like

The British Deaf Association has published theirs, and it is the strongest example in the sector so far. Read it before you draft anything.

• Publish a page, then email a link to it. An email is a snapshot. A page can be updated as the investigation moves, without you emailing everybody a second time and starting a fresh round of alarm. Put a visible last-updated date on it.
• List the actual categories of information involved. Not “personal data”. The BDA names contact details, membership information, donation, payment and Gift Aid records, event attendance including dietary and accessibility requirements, communication preferences, information about disability, health or Deaf identity, award nominations, and notes or attachments. You can only write a list like that if you have been and looked. That is the point of it.
• Say what you do not know. Nobody can currently confirm which individual records were downloaded or viewed. Saying so plainly, alongside a note that not every category applies to every person, is better than implying certainty in either direction.
• Warn people about phishing specifically. This is the actual risk from this incident. Give them the signs: unexpected contact, pressure to act immediately, a familiar display name over an unfamiliar email address, unexpected links or attachments, requests for passwords or payment details. And the one most templates miss: a message that references a real donation, event or membership is not safer for being accurate.
• Tell people how to check you are really you. A breach notification email is indistinguishable from a phishing email. Tell people to type your web address themselves, or ring a number they already had, rather than using anything in the message.
• Give the reporting routes. Suspicious emails to [email protected], text messages to 7726, their bank if money has moved, Report Fraud in England, Wales and Northern Ireland, and 101 in Scotland.
• Give one route back, and staff it. One address, handling both questions and forwarded suspicious messages.
• Calibrate the ask. The BDA leads with the fact that no immediate action is needed, then gives sensible precautions. Tell people to panic and some will cancel cards and change details they never needed to touch.

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. Then look at the credentials 2FA does not cover. This incident came in through an access key, not a login. Most organisations have API keys and integration tokens nobody has rotated since the day they were created, and often nobody owns them.
• Write down what you would do if this happened again, while it is fresh.