A cyber incident affecting Beacon CRM has raised serious concerns for charities that use the platform to manage information about donors, supporters, volunteers and beneficiaries.
Beacon has advised customers to proceed on the assumption that their databases may have been compromised while its investigation continues. This does not necessarily mean that every record has been stolen or misused, but affected charities should take the incident seriously and act promptly.
What happened to Beacon CRM?
According to UK Fundraising, the incident occurred on 29 July 2026, with customers being notified on 3 August 2026.
Beacon’s current understanding is that compromised account credentials were used to gain unauthorised access to its systems. Copies of database backups were reportedly made during the incident.
At the time of writing, Beacon has said there is no evidence that the information has been publicly shared. However, it is possible that information held within customer databases was downloaded.
Beacon says it took immediate steps to secure its systems and prevent further unauthorised access. The service has remained available and the incident did not cause an interruption to the platform.
What information could be affected?
The exact information involved will differ between charities because every organisation uses its CRM differently.
Depending on how Beacon was configured, potentially affected records could include:
- Names and email addresses
- Postal addresses and telephone numbers
- Employers and job titles
- Contact preferences and mailing-list subscriptions
- Correspondence with the charity
- Volunteering and project records
- Event registrations
- Information about donors, supporters or beneficiaries
Beacon does not store payment-card details within the CRM, according to the information currently available. However, other personal information may still be useful to criminals when creating convincing phishing emails, impersonating a charity or attempting identity fraud.
Does this mean Beacon was insecure?
Not necessarily.
Beacon states that it holds ISO 27001:2022 and Cyber Essentials Plus certifications, encrypts sensitive information at rest, supports role-based permissions and provides sign-in options through Microsoft and Google.
However, security certifications do not mean that an organisation can never experience a cyber incident. Compromised credentials can allow an attacker to bypass otherwise effective security controls, particularly where multifactor authentication is absent, incorrectly configured or defeated through phishing.
Security depends on several layers working together, including:
- The supplier’s infrastructure
- The customer’s user accounts
- Password and multifactor authentication controls
- Staff awareness and training
- Access permissions
- Monitoring and logging
- Incident-response procedures
What should affected charities do now?
1. Follow Beacon’s instructions
Affected organisations should review every notification and update issued by Beacon, complete any recommended security checks and identify which types of information may have been exposed.
Charities should avoid relying on rumours or assumptions while the technical investigation continues.
2. Start an incident log
Record the following information:
- When your organisation became aware of the incident
- What Beacon has told you
- The categories of information held in your CRM
- The number and types of people potentially affected
- Actions taken to contain and investigate the incident
- Decisions about notifying regulators and individuals
- Copies of all related communications
The Information Commissioner’s Office recommends that organisations start recording events immediately, even before deciding whether the incident must be reported.
3. Assess the risk to individuals
Consider the possible consequences for donors, employees, volunteers, beneficiaries and other contacts.
The risk may be higher where the CRM includes:
- Information about vulnerable individuals
- Health or safeguarding information
- Financial circumstances
- Confidential case notes
- Details of anonymous donors
- Information about children
- Religious, political or other sensitive information
- Records that could expose someone to distress, discrimination or fraud
A list containing only names and business email addresses may present a lower risk than a database containing safeguarding or beneficiary records. Each charity must assess its own information and circumstances.
4. Consider reporting the incident to the ICO
A charity must report a personal-data breach to the ICO where it is likely to result in a risk to people’s rights and freedoms.
Where reporting is required, this should take place without undue delay and normally within 72 hours of the charity becoming aware of the breach.
The charity does not have to wait until every detail is known. An initial report can be submitted and supplemented as the investigation develops.
Even where the decision is not to report, the incident and the reasoning behind that decision should still be documented.
5. Decide whether affected people must be told
Where a breach is likely to create a high risk to individuals, they must be informed without undue delay.
Any notification should explain in clear language:
- What happened
- What information may be involved
- The likely consequences
- What the charity is doing
- What the recipient should do
- Who they can contact for further information
The purpose of the communication should be to help people protect themselves, rather than simply satisfy a compliance requirement.
6. Secure accounts and connected systems
Charities should review:
- Beacon user accounts
- Administrator access
- Microsoft 365 or Google Workspace accounts
- Password resets
- Multifactor authentication
- API keys and integrations
- Former staff accounts
- Export permissions
- Shared accounts
- Unusual login or data-export activity
Where an email account or Beacon account may have been compromised, secure the associated email account first, reset access, enable multifactor authentication and review account activity.
7. Warn staff about phishing
Attackers may use genuine information from a CRM to make fraudulent messages appear more convincing.
Staff should be suspicious of unexpected requests involving:
- Password resets
- Bank-account changes
- Refunds
- Gift Aid
- Donation details
- Verification codes
- Attached invoices
- Urgent payments
- Links to supporter portals
Charities should also consider warning donors and supporters that criminals may attempt to impersonate the organisation.
The wider lesson for charities
A supplier can have recognised security certifications and still experience an incident. Likewise, a charity can outsource its CRM without outsourcing responsibility for the data inside it.
Charities should know:
- What personal information they hold
- Why they hold it
- Which suppliers process it
- Who has access
- How access is monitored
- How former users are removed
- How quickly the organisation could respond to a breach
- Who would make regulatory and communication decisions
The most important lesson is not that charities should stop using cloud-based CRM systems. Modern platforms can provide significantly better security than spreadsheets, shared passwords and locally managed databases.
The lesson is that every organisation needs layers of protection, clear ownership and a rehearsed incident-response plan.
Need help reviewing your charity’s cyber security?
My Tech Team helps charities and small organisations review their cloud services, Microsoft 365 security, access controls, backups and incident-response procedures.
We can help you understand where your important data is held, reduce unnecessary access and create a practical plan for responding if a supplier or user account is compromised.
Contact My Tech Team to arrange a cyber security and cloud-services review.
Further reading:
No. Customers have been advised to act as though their database may have been compromised while the investigation continues.
This is a precautionary position and does not confirm that every charity’s complete database was accessed or downloaded.
At the time of writing, there is no reported evidence that the affected information has been publicly shared.
However, the investigation remains ongoing, so charities should continue to monitor official updates from Beacon.
Beacon reportedly does not store payment-card information within the CRM.
This makes direct card theft less likely through this particular incident. However, contact details, donation history and relationship information may still be used for phishing, impersonation or fraud.
Beacon users should follow Beacon’s current instructions and ensure that their password is strong and unique.
Any password reused on another service should be changed everywhere it has been used. Multifactor authentication should also be enabled wherever possible.
People whose contact details were stored in a charity’s CRM do not automatically need to change unrelated passwords unless account credentials were among the information held.
There is currently no public indication that every charity must stop using the service.
Beacon has said that the platform is secure and available following its containment actions. However, each charity should follow the latest guidance and make its own risk-based decision.
Immediately moving to another CRM could create additional operational and security risks if it is rushed without proper planning.
Not automatically.
Each charity must assess whether the potential breach is likely to create a risk to people’s rights and freedoms. If it is, it should be reported to the ICO within 72 hours of the charity becoming aware of it.
If the charity concludes that reporting is unnecessary, it must still record the breach and document why that decision was made.
No.
Beacon may have its own regulatory obligations as the service provider and data processor, but each charity remains responsible for assessing the risks relating to the personal information for which it is the data controller.
When a processor experiences a breach, it must inform the controller without undue delay. The controller must then decide whether its own notification to the ICO is required.
Not necessarily.
Individuals must be contacted where the incident is likely to create a high risk to them. A charity may also decide to communicate more widely for transparency, even when the legal threshold is not clearly met.
The decision should be based on the nature of the information, the people affected and the realistic consequences.
Supporters should be cautious about messages that:
- Create urgency or pressure
- Ask for passwords or security codes
- Request changes to bank details
- Ask for unexpected payments
- Contain unfamiliar login links
- Refer to genuine past donations to appear convincing
- Ask for personal information the charity should already know
Anyone uncertain about a message should contact the charity using a telephone number or website address they have found independently.
Yes. Stolen information does not expire, and criminals may wait before using it.
Charities should therefore treat monitoring and staff awareness as ongoing responsibilities, rather than something that ends once the immediate incident has passed.
