Beacon breach shows what supplier questionnaires miss

Beacon, a London-based supplier of customer relationship management (CRM) software built for charities, told customers on 12 August 2026 that the probable root cause of the breach it had disclosed earlier in the month was “a compromised AWS access key which was potentially exposed in public JavaScript build artifacts”. After a further report from its external investigators, its assessment was that the attacker “exported all data contained within the database”, including attachment files. The earliest malicious activity observed began in the early hours of 27 July and lasted about an hour and a half.

The data was encrypted at rest in Amazon Web Services (AWS). But Beacon says the attacker had valid credentials, so the downloads would have been decrypted by AWS and readable. Its 4 August update said customers, out of an abundance of caution, may want to assume that all the data they stored had been downloaded. On 7 August the Charity Commission said a number of affected charities had submitted serious incident reports and warned trustees that its responses were likely to take longer than usual because of the volume. Beacon has reported the incident to the Information Commissioner’s Office (ICO).

Beacon has more than 1,500 customers, according to The Register, and its staged updates have set out the mechanics in some detail. That is what makes the case useful beyond the charity sector.

The reflex for anyone who buys software for a small organization will be to tighten the supplier questionnaire. That misses where the real control lies. A questionnaire is unlikely to catch a credential potentially exposed in a public JavaScript file. What a small buyer can actually decide is how much data it hands to a supplier in the first place, and how fast it can act when that supplier says to assume the worst.

Check, don’t assume

The government’s Cyber Security Breaches Survey 2025/2026, published in April, found that 15% of businesses and 9% of charities formally reviewed the cyber risks posed by their immediate suppliers. The figure fell to 12% among micro businesses, against 48% of large businesses. Only 3% of businesses and 3% of charities required suppliers to hold Cyber Essentials.

The survey’s interviews were blunter. Among smaller businesses and charities outside highly regulated sectors, buying software generally involved little or no cybersecurity consideration, and a few assumed protections such as encryption without knowing whether their data was actually encrypted once it sat in a supplier’s system.

Beacon’s account shows why that assumption is weak. Encryption at rest protects against a stolen disk. It does nothing when the attacker holds a working key, which is the scenario Beacon describes.

Ask every supplier about secrets

A few direct questions about how a supplier handles credentials and watches data leaving its systems belong in any software-as-a-service (SaaS) due diligence, whichever supplier is being assessed. They are quicker to answer than a long questionnaire.

• Does the supplier scan its code and build output for secrets before every release?
• Are its cloud credentials short-lived and limited in scope?
• Would an unusual volume of data leaving its environment raise an alert while it is happening?

The list applies to every SaaS tool a small organization uses. Security leaders at vendors serving small customers can run it as a self-check.

Hold less, plan the notice

The bigger lever sits with the buyer. Beacon’s FAQ told customers that all those using the platform before 27 July were affected, and that each should decide whether to notify the people in its records. Any charity that kept attachments, case notes or service-user details in its CRM has to work out what was there.

The Scottish Council for Voluntary Organisations (SCVO) put the point plainly to Scottish charities on 4 August: the important question was “not simply whether your organisation uses the affected system but what information was stored within it”.

That is a question to answer before a breach, not after one. For a small organization it means four habits: an inventory of what personal data lives in each SaaS tool; retention rules that delete what is no longer needed; limiting the most sensitive case files to the systems that need them; and a supplier-breach playbook with draft notices to supporters, staff and regulators, ready before a supplier sends the email nobody wants.

None of this requires a security team. It requires someone to decide, tool by tool, what the organization is prepared to lose.

Small organizations cannot audit their suppliers’ build pipelines. They can decide what those suppliers hold. When the advice is to assume everything is gone, the only data that is safe is the data that was never there.