Over 1,000 UK organisations, many of them charities, are now dealing with the fallout of a breach at Beacon, a CRM platform widely used across the not-for-profit sector. Investigators believe attackers copied and likely downloaded database backups after finding an AWS access key exposed in publicly available JavaScript build files. Beacon says the data was encrypted, but has warned that the attackers may have been able to decrypt it — meaning names, phone numbers, email addresses and postal addresses tied to supporters and customers could now be readable in the wrong hands.

The sector affected this time is charities, but the mechanism is the one every UK SME should sit with. This wasn’t a nation-state hack or a novel exploit. It was a credential, left somewhere it shouldn’t have been, in code that shipped to production. That is one of the most common and most preventable root causes in modern breach disclosures, and it can happen to any business running a website or app, not just a specialist CRM vendor.

Why this matters even if you’ve never heard of Beacon

Most SMEs don’t build their own CRM, accounting, or booking systems — they rent access to someone else’s. That’s the right call commercially, but it means your customer data’s security now depends on a vendor’s engineering discipline as much as your own. When that vendor makes a mistake, you inherit the consequences: breach notification obligations, reputational damage with your own customers, and potentially GDPR liability, even though you never touched the compromised system.

The uncomfortable truth is that most businesses can’t audit their vendors’ AWS configurations or code repositories. What you can do is control how you respond when a vendor tells you something has gone wrong, and how carefully you choose vendors in the first place.

What to check in your own stack this week

Ask your key vendors directly whether secrets ever ship in client-side code. You won’t get a technical answer from most sales contacts, but asking the question puts security on record as something you care about, and a vendor who can’t answer at all is a signal in itself.

Know exactly what data each vendor holds on your customers. If you can’t list which of your tools store names, contact details, or payment information, you can’t assess your own exposure when one of them has an incident. A simple spreadsheet of vendor, data held, and contract owner takes an afternoon and pays for itself the first time you need it.

Read breach notifications from suppliers properly, not just skim them. Beacon’s customers were told database backups were “likely downloaded” — that’s a meaningfully different risk than “we detected unauthorised access with no evidence of exfiltration,” and it should trigger different actions, like proactively warning your own customers rather than waiting to see if anyone complains.

Build the vendor-breach scenario into your incident response plan, not just the direct-attack scenario. Most SME cyber planning assumes the business itself gets phished or ransomed. Increasingly, the more likely route in is a supplier you trusted completely. If you don’t have a documented plan for “what do we do if a vendor tells us our customer data was in a breach,” this is the week to write one — it’s a short document, not a project. KeepSafe specialises in exactly this kind of incident monitoring and response planning for businesses that don’t have an in-house security team.

The takeaway

The Beacon breach wasn’t caused by anything exotic — it was a credential that shouldn’t have been public, sitting in code that was. Every SaaS tool your business relies on carries the same theoretical risk. You can’t eliminate it, but you can make sure you know what data is exposed where, and that you have a plan ready before the notification email arrives rather than after.