Beacon cannot tell what the attacker took, so 1,000-plus charities must assume everything

Beacon, the UK company whose CRM platform charities use to manage donors, supporters, volunteers and fundraising activity, told customers this week that its logs cannot establish which records the intruder actually took, and that its working assumption is that everything in the database was exported ^[1][2][7]. Several affected UK charities say the incident touches all of Beacon's more than 1,000 customers, which converts one provider's forensic uncertainty into a breach notification obligation for each of them ^[9].

The sequence is short. Beacon disclosed in early August that attackers had downloaded customer database backups, adding that although the data was encrypted, the attackers could have decrypted it before exfiltration ^[3][4]. In this week's update the company said the earliest malicious activity was observed on 27 July and that the data was likely transferred on 27 and 28 July ^[5], which puts the disclosure roughly a week behind the transfer window ^[1].

The operative sentence is the one about evidence. "Specific objects, exact destination of the downloads, and definitive attribution of which objects were accessed cannot be determined from available logs," Beacon said ^[6]. What it does have is arithmetic: having compared the volume of data transferred against the total volume stored across the system, the company assessed that the threat actor exported all data contained within the database ^[7]. That conclusion is an inference from bytes moved, not a record-level account of what was read ^[2]. It is the honest answer available, and it is also the most expensive one, because it removes any basis for a charity to argue that its own supporters were outside the blast radius.

The entry point, according to Beacon's investigation, was a compromised AWS access key that may have been exposed in publicly available JavaScript build artifacts, used to pull the data from an AWS environment ^[8]. A key in a shipped front-end bundle is not an exotic failure. It is a build pipeline that published something it should have stripped, and in a multi-tenant CRM it grants reach across every tenant at once.

What the charities are telling their supporters varies. Some say personal information may have been compromised, including names, phone numbers, email addresses and postal addresses ^[10]. Others have pointed out that no bank account numbers, sort codes, card numbers or card security details were exposed, because they do not store that data in Beacon ^[11]. The distinction matters for fraud risk but not for obligation: a full-database assumption still means notifying people whose contact details, and in a charity context often their relationship to a cause, have gone somewhere unknown.

The Charity Commission is monitoring the situation and has issued guidance for affected organisations ^[12].

Two things to watch. First, whether the data surfaces: no known cybercrime group has claimed the attack, and Beacon says it is not aware of the stolen data being published ^[13][14], which is consistent with quiet resale as much as with restraint. Second, whether any of the 1,000-plus customers can independently narrow their own exposure, or whether they all end up notifying on their provider's volume estimate ^[7][9]. For anyone else running a shared-tenancy platform, the lesson is that logging which objects were read is what buys you the right to notify fewer people.