One SaaS Breach Can Become Hundreds of Data Incidents

A cyberattack against Beacon, a CRM platform used widely across the UK charity sector, is a useful reminder of a security risk businesses often overlook:

What happened?

Beacon became aware of the incident on 29 July 2026. Its investigation found evidence that copies of database backups had been created and were likely downloaded by an unauthorised third party.

Beacon advised customers with accounts created before 27 July to assume that information stored in the platform, including attachments, may have been downloaded. The potentially exposed information varies by customer and may include:

• Names, addresses, email addresses and telephone numbers
• Dates of birth
• Donation and payment-related information
• Supporter, beneficiary or service-user information
• Uploaded documents and attachments

Organisations reported in coverage as affected include the Molly Rose Foundation, The Upper Room and Macmillan Cancer Support Jersey. That does not mean that every Beacon customer was affected in the same way, or that every record held by those organisations was accessed.

Beacon serves a large charity and non-profit customer base. Different reports describe that customer base as more than 1,000 or around 1,500 organisations. The scale matters because one supplier incident can create a large number of customer-level investigations, but it is not evidence that all 1,500-plus customers had data stolen.

Why one supplier breach becomes many incidents

A business can have strong passwords, MFA, patched laptops, secure Microsoft 365 and endpoint protection, yet still have its information involved in a breach. That is because the information may be sitting inside a third-party platform with its own people, applications, cloud accounts, storage and backup processes.

The supplier's incident becomes a customer incident when the customer has to work out what information was held, assess the possible impact, answer questions from people, involve insurers or advisers, and decide whether any notification is required.

The investigation revealed a wider lesson

Later reporting indicated that Beacon believed the likely route into the environment involved an AWS access key potentially exposed in publicly accessible JavaScript build files. The report describes a suspected route into the supplier's environment, not a finding that every customer had made the same mistake.

In plain English, a credential capable of accessing part of a company's cloud infrastructure may have been accidentally exposed somewhere external users could see it. That matters because businesses often think credentials only means passwords.

• Cloud access keys
• API keys
• Application secrets
• Service accounts
• Automation credentials
• Administrator tokens

These can be just as important as a username and password. A supplier may have MFA for human administrators while a leaked machine-to-machine credential still provides a route into cloud resources, storage or applications.

"But our systems were not hacked"

That is exactly the issue. A customer can secure its own network and still depend on a supplier's security decisions. The customer may not control the supplier's servers, developers, infrastructure or security team, but its information can still be processed, copied and retained there.

Modern organisations have a technology supply chain whether they realise it or not. A typical SME may rely on external systems for:

• Customer relationship management
• Accounting, payroll and HR
• Marketing automation
• Cloud storage and collaboration
• Helpdesk and customer support
• Backups and disaster recovery
• Payment processing
• Industry-specific applications

Every supplier holding important information becomes part of the business's security environment. That does not mean every supplier needs a complex audit. It does mean the business should know where important data lives and what would happen if that provider had a serious incident.

This is supplier risk

Cybersecurity conversations often focus on protecting the organisation's own network. That is necessary, but incomplete. The better question is:

Do not keep data forever

CRM platforms accumulate information. Contacts stay in the database, old attachments remain, former customers stay listed and historical records build up. The longer unnecessary data remains in a platform, the more information there is to assess if that platform is breached.

Data retention is therefore both a security issue and a compliance issue. Reducing unnecessary data does not prevent a supplier breach, but it can reduce the scope and difficulty of the resulting investigation.

MFA still matters, but it does not solve everything

Beacon supports two-factor authentication and reportedly requires it for administrators. That is good practice for protecting human access to the application.

But this incident demonstrates that security cannot stop at user logins. If the suspected route involved a cloud infrastructure key, machine-to-machine access matters too. Businesses increasingly rely on APIs, service accounts, application integrations, automated workflows and cloud administrator credentials.

These credentials need ownership, restricted permissions, safe storage, monitoring and regular review. A supplier's MFA policy is useful information, but it is not a complete description of the supplier's security posture.

What should your organisation do?

You do not need to investigate every SaaS provider in the same depth. Start with systems that contain sensitive information, support important operations or connect to many other services.

1. List your important cloud services

Start with anything containing customer information, employee information, financial information, operational records or sensitive documents. Include the systems chosen by departments without a central IT project, because they may still hold business data.

2. Record what each platform actually holds

Do not write only CRM or cloud storage. Record the actual categories of information, the business purpose, the approximate retention period and whether attachments, exports or backups are included.

3. Turn on MFA and protect administrator access

• Prioritise administrators, finance users and cloud platforms.
• Use MFA for CRM systems, email and remote access.
• Remove former staff, dormant accounts and unnecessary administrators.
• Avoid shared administrator accounts where named accounts are practical.
• Review external users and third-party application access.

4. Review integrations and machine access

Understand which API keys, applications, automation tools, connectors and service accounts can access important systems. Ask who owns each credential, where it is stored, what it can reach and how it would be revoked if the supplier or integration were compromised.

5. Reduce unnecessary data

Delete information that no longer has a legitimate business, legal or contractual reason to be retained. Check old contacts, attachments, exports and test records rather than focusing only on the active database view.

6. Understand your exit route

• How can the data be exported?
• What format will it use?
• What happens to stored copies after cancellation?
• How long does the supplier retain backups?
• Can the business operate if the service is unavailable?

7. Ask proportionate supplier questions

For a critical platform, ask about incident notification, administrator MFA, access logging, backup protection, vulnerability management, sub-processors, data location and recovery arrangements. Use the answers to understand risk, not to create a false guarantee that a supplier can never be breached.

8. Plan for a supplier breach

Ask what would happen if a critical supplier emailed tomorrow saying: Assume your data has been downloaded. Decide who would investigate, assess the information involved, contact the insurer, speak to legal or data-protection advisers, decide whether customers need to be notified and keep operations running.

The IT Club view

The lesson from the Beacon incident is not that cloud software is unsafe. SaaS platforms can be practical, secure and essential to a modern business.

The lesson is that outsourcing a system does not outsource your risk. Your organisation may not control the supplier's servers, developers, infrastructure or security team, but it does control which supplier it uses, what information it stores there, who gets access, how long data is retained, which systems connect to it and what happens if that supplier has a problem.

Most businesses now have a technology supply chain whether they realise it or not. Knowing what sits in that supply chain is becoming a basic part of cybersecurity.

Sources and further reading

This article is original IT Club commentary and explanation. Brigantia surfaced the story internally. The incident details and reported attribution should be checked against the latest supplier and source updates before being used for formal decisions.

The Register: UK charities count the cost of Beacon CRM cyberattack →

The Register: AWS key exposed in JavaScript may have lit way to Beacon's charity data →

Beacon: Cyber security incident information →