Cybersecurity

Beacon's Breach Falls Outside Every Safety Net

A leaked AWS key let attackers copy Beacon's charity CRM database. Financial firms get DORA, critical infrastructure gets NIS2 - the charity sector gets neither.

CybersecurityBy Servola Tech Desk2026-08-154 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

Beacon's Breach Falls Outside Every Safety Net

Key takeaways

Beacon's own CTO David Simpson traced the intrusion to an 87-minute window on 27-28 July 2026 only by retrospectively analysing AWS Cost and Usage Reports across May to July; the root cause, an AWS access key exposed in Beacon's own public JavaScript build artifacts, was not confirmed and disclosed until 4 August, and updated again on 13 August.
The attacker used that valid key to copy Beacon's entire customer database, donor records and attachment files in readable form; the data was encrypted at rest, but the compromised credential carried its own decryption access, so encryption provided no real protection once the key leaked.
Beacon serves more than 1,500 charities and says it cannot yet establish how many had data taken; named affected organisations reported by The Register include Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association and Lincoln Cathedral.
Unlike the financial entities covered by the EU's DORA or the critical-infrastructure operators covered by NIS2, none of Beacon's charity customers sit inside a regime that mandates a vendor risk register, a third-party audit right or a maximum incident-response timeline; their only backstop is UK GDPR's general accountability duty and a voluntary Charity Commission serious-incident-report process.
The original Servola read: a secret hard-coded into public-facing JavaScript is exactly the class of defect that DORA's mandatory penetration-testing regime exists to force regulated vendors to catch before it ships, and its complete absence from the charity sector means the review burden now falls on 1,500 under-resourced organisations filing reports one at a time, instead of on one accountable vendor before the contract was ever signed.

Eighty-seven minutes, traced a week late

The intrusion itself lasted roughly 87 minutes in the early hours of 27-28 July 2026. Beacon's technical account, given by chief technology officer David Simpson, says an AWS access key had been sitting exposed inside JavaScript build artifacts served directly from the company's own public website, the kind of client-side bundle any visitor's browser downloads without ever triggering an alert.

Beacon did not catch the intrusion in real time. Simpson says the company only reconstructed what happened by analysing AWS Cost and Usage Reports covering May through July 2026 after the fact, and found a spike in data-transfer costs on exactly the two days in question, evidence that lined up with the download activity rather than any live detection system flagging it.

That retrospective method explains the disclosure gap: the breach happened on 27-28 July, Beacon told customers on 4 August, and issued an updated account on 13 August that still could not close every question. Simpson told customers directly that 'there are things we may never be able to find out about this incident,' and promised a fuller account in the following weeks.

Who is actually exposed

Beacon's customer base runs to more than 1,500 charities, and the company has been explicit that it has not established how many of them actually had data taken, only that a full copy of its database, including attachment files, was made and was almost certainly downloaded in readable form.

The Register's reporting names specific affected organisations, including Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association and Lincoln Cathedral, a spread that runs from bereavement and mental-health support to hospital fundraising, disability advocacy and cultural heritage.

None of that is medical or clinical data in the way a hospital's own patient record would be, but donor and supporter records held by organisations like these routinely include people in bereavement, illness or crisis, exactly the population a data controller is supposed to protect with proportionately more care, not less, than a typical mailing list.

The gap DORA and NIS2 were built to close, but do not reach

The EU's Digital Operational Resilience Act requires financial entities to maintain a register of every ICT third-party provider and to assess the risk each one poses, under Articles 28 to 30, precisely so a vendor's security posture gets audited before, not after, an incident. NIS2 imposes comparable security and incident-reporting duties on essential and important entities across energy, health, digital infrastructure and public administration.

Charities and the SaaS vendors that serve them sit outside both regimes entirely. Their only backstop is the general accountability principle in UK GDPR, which still makes a charity liable as data controller even when a processor's own product fails, and the Charity Commission's serious-incident-report process, which the regulator itself describes as prioritising reports by risk rather than acting on all of them at once.

That is the Servola read that does not appear in any single source report: an AWS key left inside public JavaScript is precisely the class of basic secrets-hygiene failure that a DORA-regulated vendor's mandatory penetration test and audit trail exist to catch before a contract is signed. Strip that regime away, as it is for the charity sector, and the review that should have happened in procurement now happens after the fact, one Charity Commission incident report at a time.

What a charity, or any small nonprofit buyer, should ask before renewing

The practical response does not require a new law. Any charity or nonprofit signing or renewing a SaaS contract can ask a vendor directly for evidence of automated secret-scanning in its build pipeline, a written incident-response commitment with a stated timeline, and confirmation of exactly which donor or beneficiary fields are genuinely necessary to store rather than merely convenient.

The pattern is not unique to Beacon. Vendor breaches driven by basic credential-hygiene failures, from RingCentral's still-unexplained social-engineering incident to the Trezor-ShipMonk shipping-provider compromise, keep recurring because supply-chain security assurance built for regulated sectors does not automatically extend to adjacent sectors buying the same class of tools with a fraction of the security budget and none of the contractual leverage.

Until that leverage exists for charities the way it exists for banks under DORA, self-reporting through the Charity Commission is doing the enforcement job that no external regulator is currently positioned to do, one under-resourced organisation and one serious-incident report at a time.

Frequently asked questions

What data was actually taken in the Beacon CRM breach?

Beacon says the attacker made a readable copy of its full customer database and attachment files, covering more than 1,500 charity customers; this typically includes supporter and donor names, postal addresses, phone numbers, email addresses and donation histories. Beacon has said it cannot yet establish exactly how many individual records were taken.

Does DORA or NIS2 apply to this breach?

No. DORA covers only EU financial entities and their designated critical ICT providers, and NIS2 covers essential and important entities in sectors like energy, health, digital infrastructure and public administration. Charities and their SaaS vendors, including Beacon, sit outside both regimes, leaving UK GDPR's general accountability principle and the voluntary Charity Commission incident-report process as the only oversight.

How did the attacker get in?

Beacon's own account points to an AWS access key that was exposed inside JavaScript build artifacts served from its public website. Whoever found that key gained valid credentials to Beacon's own cloud storage and used them to copy the full customer database.

What should a charity using Beacon or a similar CRM do now?

Request a written incident report directly from the vendor, check whether your organisation needs to notify the ICO or supporters under UK GDPR, and going forward, ask any SaaS vendor for evidence of automated secret-scanning in its build pipeline before signing or renewing a contract.

A DORA-regulated bank would have forced Beacon to prove its secrets never touch a public JavaScript bundle before a contract was ever signed. A charity buying the same class of software has no equivalent leverage, and until that changes, the review that should happen in procurement is happening in a Charity Commission queue, one serious-incident report at a time.

Beacon CRMCharity CommissionAWSData BreachDORANIS2

Hugging Face Had To Ask For Its Own Breach Logs

Hugging Face could not identify the model that broke in. Its CEO then asked OpenAI publicly for the traces. Nothing compels a vendor to hand them over.

7 min read

Infrastructure

Your DR Plan Assumes the Region Comes Back

AWS estimated at least a day to restore its UAE region after drone strikes in March. On 30 April it said the region could not reliably support applications.

5 min read

Decisions

The Third Pivot Was the Warning Magic Leap Missed

Magic Leap filed a WARN notice for 193 layoffs effective 1 October 2026, its fourth strategic pivot after $4 billion raised. The lesson is the pattern, not the pivot.

4 min read

← All articles