What should you do if your CRM has a security incident?

With the recent news of Beacon CRM's cyber incident we thought it would be helpful to put this guide together. We would always recommend ensuring you check the latest up to date incident page when it's something like this. If you feel out of your depth, get in touch and we can help you through. We're sorry to say we've been involved in UK charities being victims of cyber attacks before.

This guide is not exclusively for Beacon CRM users or organisations, but all the steps below are relevant.

If your CRM, web or email provider reports a security incident, your first stop should always be their official incident page or statement. This is where you’ll find confirmed facts about what happened and who is affected.

Avoid speculation on social media or third-party news sites. Misinformation spreads quickly, while your plan depends on the exact details the supplier provides. Keep re-checking updates, as information may change as suppliers learn more.

Most UK charities are "data controllers" when using tools like CRMs, websites or email marketing. This means it's your job to understand what has happened to your data and decide how to respond, even if a supplier is looking into the issue too.

Suppliers (such as CRM platforms like Beacon) usually act as "data processors" - they process data for you, under your instructions. If something goes wrong at their end, you still remain responsible for any personal data you put on their systems.

Review what services, user accounts or time periods were involved in the incident. Does it include your own data, or only a subset of users? Make a list of what personal data you actually held on the affected system - for many organisations, this is just names and emails, but it’s critical to check carefully.

Don’t guess based on what the system could store - rely on what you actually uploaded or collected. Keep a note of any users, volunteers or service users whose details could be affected.

Choose one person to coordinate your response and record each decision and action as you go, even if your team is only one or two people. Here are key early steps:

• Check your incident-response or data-breach procedure (if you have one)
• Change passwords, review admin accounts, and enable two-factor authentication on affected systems
• Revoke and regenerate API keys, webhooks or integration credentials if advised
• Check your website forms, connected tools or automations that link with the affected supplier
• Preserve relevant emails, notifications or logs in case the ICO asks for evidence

Pro tip: Even if you’re the only person managing your charity’s systems, writing down your actions creates a useful timeline if you need to report the incident later.

Personal data varies: a mailing list name and address isn’t as sensitive as financial records or safeguarding concerns. Ask yourself what threat or harm could arise if the information was accessed or misused. Focus on real-world risk to the people involved, not just how much data there is. For example, records involving vulnerable clients or children need extra care.

Reporting rules vary. If you believe personal data may have been lost and this could risk people's rights or freedoms, you may need to report to the ICO within 72 hours. Charity regulators, trustees or funders might expect to know, depending on your governance. Only notify affected individuals if there is a genuine risk to them, and always be clear and factual.

Make these as separate, careful decisions. You don't have to do them all at once, and sometimes - after checking - you may not need to report at all.

If you need to communicate about the incident, use plain English. Be upfront about what happened, what you know and what’s still uncertain. State what you’re doing to resolve it and avoid minimising the issue or creating panic. Silence and speculation both damage trust faster than controlled, honest updates.

Your website might send data into your CRM via forms, plugins or automations. Review connected accounts, forms, plugins, CMS users, server logs and all integration credentials for signs of compromise or out-of-date settings. Website security is part of data protection, not a side issue.