The Beacon CRM security incident

We held off writing about the Beacon CRM unauthorised access when it first happened.

We know Beacon well. We’re a Beacon implementation partner, but we don’t receive commission for recommending it (we’re partners with other CRMs and management systems too). We’re independent in the systems we recommend and have suggested Beacon in the past because, for the right organisation, it is indeed an excellent system with a great support team behind it. We have implemented it, supported organisations using it and recommended it where our analysis showed clearly that it was the right system for the job at hand. Our job isn’t to defend Beacon, nor is it to use an incident like this to push charities towards another CRM.

We also aren’t cyber-forensics specialists, so we wanted to know more before joining the commentary. Apparently this isn’t the best strategy for maximising a PR opportunity, but we’re working on that.

In this article:
01 The picture is much clearer now
02 The human mistake isn’t actually the most interesting part
03 So — should charities still choose Beacon?
04 The bigger question: why do we collect so much data?
05 Anonymous, pseudonymous and identifiable data
06 Charities are still responsible for the data they choose to collect
07 What should organisations do with this now?
08 What this incident should teach us

On 12 August, Beacon said its external cyber-security investigation had concluded that a copy of the database holding all Beacon customer data, including attachments, was made and likely downloaded in readable form. Its probable root cause is an AWS access key that may have been exposed in public JavaScript build artefacts. Beacon says the attacker had valid credentials and that, although the data was encrypted at rest, AWS therefore decrypted the downloads. Its current assessment is that all data contained within the database was exported.

That’s a serious incident, with a very large potential impact. But it is also a useful lesson, because it doesn’t appear from the information released so far to involve somebody breaking encryption or using some new form of sophisticated attack. It appears that a credential ended up somewhere it shouldn’t have been and somebody found it and used it.

In other words, at some point something seems to have gone wrong involving people, process or configuration. And that is exactly the sort of thing good security has to assume will eventually happen.

What makes this incident particularly instructive is that Beacon wasn’t an obviously risky supplier. Beacon is ISO 27001:2022 and Cyber Essentials Plus certified. It encrypted customer data at rest. It used AWS. It carried out penetration testing and vulnerability scanning and talked publicly about its security processes.

• Those are exactly the kinds of questions charities, their procurement teams and consultants like us ask when assessing a technology provider.
• Is the supplier ISO 27001 certified?
• Is the data encrypted?
• Where is it hosted?
• What access controls are in place?
• Is MFA supported?
• Are systems penetration tested?
• How are vulnerabilities managed?

Beacon could give good answers to those questions. Now, that doesn’t make these questions pointless – we should still ask them. But this incident shows why the answers aren’t a guarantee.

If the probable root cause identified by the investigation is confirmed, a sensitive AWS credential ended up somewhere it should not have been. But we’re less interested in blaming whoever or whatever process allowed that to happen than in what happened after it. Because humans (or these days too: machines) will always make mistakes. That’s something we need to calculate into any risk profile. Human mistakes are very difficult to eliminate completely. Someone will eventually click the wrong thing or give an account too much access. They put a secret in the wrong place and maybe approvals miss something during a code review. Or they configure a service incorrectly, lose a device, get phished – you name it. You can make all of those things less likely, but building your security around the assumption that nobody will ever make a mistake isn’t realistic.

The bigger question is how far one mistake can go. Security professionals call that grandly the “blast radius”.

In Beacon’s case, the malicious activity it has identified lasted around one hour and 27 minutes. Beacon’s assessment, based on the amount of data transferred, is that the attacker exported all data contained within the database. There has so far been no indication from online monitoring that the data has been published or misused. All of that raises some difficult questions that Beacon has to address going forward:

• How could the initial compromise have been prevented?
• Could permissions or segmentation have reduced the potential impact?
• Could monitoring or additional controls have detected or stopped the activity sooner?

We don’t know the answers and it would be wrong to invent them, even if speculation is very tempting. But Beacon’s investigation is still being completed and it has already said that some technical details may not be published because doing so could create further security risk. But the outcome tells us that the impact of all of this was very large. That’s the part every organisation should pay attention to.

There is some irony here that people have already pounced upon.

In July 2025, Beacon itself published a really good article about another supplier’s £3 million data breach. It used the Swiss cheese model to explain cyber security: every security control has holes, so you use several layers to make it much less likely that the holes line up. That’s what we’re doing here too! Hundreds of consultants will currently be going through their own processes to reassess their own risk.

So that principle is right as this incident now demonstrates extremely clearly. The answer isn’t simply “never expose a credential”. It is to have enough other layers that an exposed credential does not automatically lead to a catastrophic outcome. That means limiting permissions, separating systems where appropriate, monitoring unusual behaviour and restricting access to sensitive data. All of this should make bulk extraction harder. Internal tests and repeated training can also ensure that credentials are managed properly. Testing your processes and controls rather than assuming they work once you’ve written them down is a good practice that can easily get overlooked because “something else” is always more important.

The ICO’s current security guidance takes exactly this risk-based approach. It says organisations must use technical and organisational measures appropriate to the data and the risks, covering not only prevention but detection and minimising the impact of an incident.

Or, put much more simply:
Design the system so that a mistake has somewhere to stop.

Beacon has been clear that the data was encrypted at rest. That sounds contradictory when the same update says the attacker probably received readable data, but it isn’t. Encryption at rest protects stored information. A legitimate system still needs to be able to decrypt that information when an authorised service or user needs it. Beacon says the attacker had valid credentials, so AWS would have treated the requests accordingly and returned readable information. So this isn’t evidence that encryption is useless – it is again evidence that encryption is only one layer.

The ICO makes the same point in its guidance. Encryption is one part of a wider approach to security, alongside access controls, resilience, monitoring and regular testing. Exactly what happened at Beacon and what the investigation ultimately concludes about the controls in place, is not yet clear. Beacon has reported the incident to the ICO and is continuing to work with external cyber-security specialists.

The answer to this question is actually the same as before that incident:

For many organisations, yes – for others, maybe not.

We would not make that decision on the basis of the breach alone. Beacon is a strong product and has made flexible CRM technology available to charities that might otherwise be choosing between spreadsheets, older fundraising databases and much larger – and unaffordable! – enterprise systems. The breach doesn’t make the software suddenly bad. But good software doesn’t make the breach less serious either. Unsurprisingly, competitors have been quick to position alternatives, but that’s what competitors do.

But moving CRM doesn’t remove the underlying problem. Every system has administrators, integrations, APIs, infrastructure, suppliers and human beings. A migration also involves extracting, transforming, copying and re-importing large amounts of data, which introduces risks of its own. And lots of time and cost on top of dealing with the fallout now. So if moving CRM becomes a consideration, we would advise to first stop, let the dust settle and approach this as a longer term consideration. For charities using Beacon, the question is not “How quickly can we leave?”. Because to be brutally honest – moving CRM now cannot undo the exposure that has already occurred, so any decision to move should focus on future risk rather than reacting to the incident alone

But: given what we now know, what is our future risk if we stay, compared with the risk and cost of moving

Beacon’s final investigation, the changes it makes, the sensitivity of your own information and your tolerance for risk should all form part of that decision.

There are several ways organisations can reduce this risk. Suppose a charity needs demographic information for funder reporting – it could collect that information alongside someone’s identity while it is needed operationally. It could then generate its statistical reporting information and remove the connection with the individual once that connection is no longer needed.

So instead of retaining:

Sarah Jones, 34, condition X

you retain:

Age 25-34: 146 people
Condition X: 41 people

If it is no longer reasonably possible to work backwards and establish which individuals produced those statistics, the information can be properly anonymised and is no longer personal data for UK GDPR purposes. A stolen reporting dataset would still disclose your organisational statistics but it wouldn’t disclose Sarah’s health information. And that is a very different level of breach.

This is an important distinction:

Imagine you replace Sarah’s name with:

Participant 83572, 34, condition X

and you keep another table somewhere saying:

Participant 83572 = Sarah Jones

You’ve reduced the risk because the identifying information is separated, but the information is still personal data because your organisation can reconnect it to Sarah. That’s pseudonymisation, not anonymisation and ICO guidance is pretty explicit about that difference. Pseudonymisation can still be very useful. You could have a service-delivery database containing identifiable records available only to the people who need them, while analysts work from a separate pseudonymised dataset. Or even better, where reporting does not require individual-level information at all, you may be able to aggregate and anonymise it as per the above examples. And sometimes you can avoid collecting the identity in the first place: If an equality or outcomes survey exists purely to understand your service-user population, does it actually need a name, email address or CRM contact ID? Sometimes it will. Often it won’t.

This is quite an important caveat though: removing someone’s name doesn’t automatically make information anonymous. If a small rural service has eight users and you retain someone’s exact age, postcode, unusual medical condition or occupation, it may be obvious who they are even without a name attached. ICO guidance says data is only effectively anonymised where people can no longer be identified using “reasonably available means”. That probably includes your AI and social media supported online sleuthing. So that might mean using an age band instead of an exact date of birth or using a broader geographic area instead of a full postcode. Other things to consider:

• Removing unnecessary free-text information
• Not reporting categories containing a limited amount of people (one or two!)
• Should all those demographic fields need to be collected together at an individual level in the first place?

For Beacon customers, as has been stated various times before: assume the information you stored may have been downloaded and carry out your risk assessment on that basis. That is Beacon’s own current advice.

Then (maybe once the first dust and panic has settled) take the opportunity to look further than the systems you’re using (not just Beacon!) make a plan to become more resilient. Some suggestions to get you started:

• Review sensitive information across all your systems, not just your CRM
• Ask why each category of personal information is being collected
• Delete information you no longer need
• Don’t keep identifiable information indefinitely simply because it might be useful for reporting later – and even if it does, separate it from individuals records
• Where you need statistics rather than identities, consider collecting anonymously or anonymising after the identifiable data has served its purpose
• Where identity still needs to be recoverable, consider pseudonymisation and keep the identifying information separately
• Reduce the number of people and systems that can access sensitive information
• Rotate any API keys on a regular basis (e.g. every 3 months) to reduce the risk of outside access
• Review attachments and free-text fields, where sensitive information often accumulates without much structure
• Review retention rules and, where possible, automate deletion rather than relying on somebody remembering to do it
• When assessing suppliers, ask not only whether controls exist but what happens if one of them fails
• Review your internal documentation and training sessions – does your team know about your data policies?