Your Donor List Lives Somewhere Else, and You Could Not Have Stopped This

Most articles like this one end with a checklist. We are going to be straight with you instead, because a checklist would be dishonest here.

More than a thousand charities were recently told to assume their entire supporter database had been taken. Not one of them could have prevented it. There was no patch anybody missed, no setting a charity should have changed, no training that would have caught it. The data was never in their building.

That is an uncomfortable place to start, so let us go through what actually happened.

What Happened, in Plain English

Beacon makes CRM software that charities use to hold donor and supporter records. In late July, an intruder was inside Beacon's systems for roughly an hour and a half, across July 27 and 28. Beacon detected the intrusion on Wednesday 29 July and notified its customers on Monday 3 August.

Copies of customer database backups were downloaded. Those backups were encrypted, which normally means scrambled and useless to anyone without the key. Beacon has said the attacker could have decrypted the data before taking it, and after comparing the volume of data transferred against the total volume stored, the company concluded that the attacker exported everything in the database. Beacon advised customers to act as if their databases have been compromised.

The information involved, according to notices published by affected charities, includes names, phone numbers, email addresses and postal addresses. Bank account numbers, sort codes and card details were not exposed, because that information was not stored in the system.

As for how the attacker got in, Beacon's own investigation points at a compromised cloud access key that may have been exposed in publicly available build files served by its website. Beacon's chief technology officer described that key as the leading suspect. It has not been definitively confirmed.

A cloud access key, if the term is unfamiliar, is essentially a password that lets software reach a company's cloud storage directly. Leaving one in files the public can download is a known and preventable engineering mistake. Worth saying plainly: Beacon has published considerably more detail about this than most vendors do when it happens to them, and that is to their credit.

The Part That Has Nothing to Do With Your IT

Here is where we part company with the usual advice.

If you are a nonprofit that used this system, your firewall was not the problem. Your staff training was not the problem. Your password policy was not the problem. Every control you are normally told to invest in sat entirely outside the path this attack took, because the database was never on your computers.

We sell IT services for a living, and we are telling you that nothing we sell would have changed the outcome here. Any vendor who tells you otherwise is selling you something.

It is worth sitting in that discomfort for a second rather than rushing past it, because it is the actual lesson. Some of your risk does not live in your building anymore, and no amount of tightening things up on your end reaches it.

So What Is Actually in Your Control

Three things, and only three.

Knowing who holds your data. Every outside company that stores a supporter, donor or client record for you. Not the ones you remember. All of them.

Knowing what they hold. Names and emails is one conversation. Giving history, safeguarding notes, health information or anything else sensitive is a very different one.

Knowing what happens on their worst day. How fast do they tell you, who do they tell, and what do they put in writing.

None of those three prevent a breach at a vendor. What they do is decide how badly the next one lands on you, and how quickly you can respond when it does.

The Donor Conversation Is the Real Damage

This is a fundraising problem before it is an IT problem.

Your donors are not going to ring the software company. They are going to ring you. Wanting to blame the vendor is completely understandable, and it does not change who picks up the phone. The supporter relationship is the asset that takes the hit, and that relationship is yours, not your vendor's.

So say something early, say it plainly, and do not let the first your supporters hear of it come from somewhere else. Several charities affected by this incident published clear, calm notices to their own supporters within days. That is the right instinct, and it reads as competence rather than as an admission of fault.

If your board wants to spend the meeting deciding whose fault it was, that energy is better spent on who is calling which supporters this week.

A One-Page Inventory You Can Build This Week

This is the small thing worth doing, and it takes less time than the meeting about it will.

Write down every outside system that holds a supporter or client record for you. Next to each one, write the person inside your organization who owns that relationship, and where the contract lives.

If you cannot finish the list, that is the finding. Most organizations cannot, and it is not a failure of diligence. Systems get added one at a time by different people over several years, and more often than not, nobody was ever asked to keep the master list.

Start it anyway. When the next vendor has its bad week, the organizations that already know what they handed over are the ones that respond in hours instead of weeks.

If you want a second set of eyes on that list once you have it, book a free 30-minute strategy session and we will go through it with you.