A cyberattack can stop a small volunteer organisation for weeks. The defences that work are dull and cheap: backups an intruder cannot reach, tight control of administrator accounts, and a recovery plan written before anything breaks.
Ars Technica reports that a nonprofit which tracks meteors was knocked offline by a cyberattack, and that the group expects to be largely unable to operate for several weeks. The technical detail of that incident — what was taken, how the attackers got in, whether data was destroyed or merely locked — is not established here, and this article does not assume it. What the case illustrates is a general pattern: organisations that run on donated time and second-hand infrastructure often hold data that cannot be regenerated, and they recover slowly because nobody wrote down how. The steps below are the preparation work that shortens that recovery.
Gather what you need before you start
You need three things and none of them are products. First, authority: agreement from whoever runs the organisation that you may inventory systems, change passwords and spend a small amount of money. Second, a complete list of the services the group depends on — web hosting, domain registrar, email, cloud storage, database, code repository, payment processor, mailing list, social accounts. Volunteer-run groups typically discover several the committee had forgotten. Third, somewhere to store the plan that does not depend on the systems it describes: a printed folder, or a file on a laptop that is not joined to the organisation’s accounts.
Budget a few hours, not a project. The work is mostly clerical. If you are waiting for a security consultant before you begin, you will still be waiting when something happens.
Map the data that would stop the work
Separate what is convenient from what is irreplaceable. For an observational science group, the irreplaceable category is usually the observations themselves: raw submissions, sensor captures, calibration records, the archive that gives older entries their meaning. A website can be rebuilt in a weekend. A decade of reports cannot be re-collected.
Write down, for each irreplaceable dataset: where it physically lives, what format it is in, who can export it, and how large it is. Size matters because it determines whether a copy fits on a cheap external drive or needs a paid service. Include the things that are not obviously data — the membership list, the donor records, the configuration that makes the collection pipeline work. Restoring a database is of little use if nobody remembers the settings that fed it.
Take stock of who holds administrative access
Long-lived volunteer organisations accumulate accounts in the names of people who left years ago. Go through the list from the previous step and record, for each service, who can log in, who can reset the password, and which email address controls recovery. Anything tied to a personal address that the group no longer controls is a failure point regardless of attackers.
Then reduce. Administrator rights should sit with the smallest number of active people who can still cover for each other — two or three, not one, and not everyone. Turn on multi-factor authentication everywhere it is offered, starting with the email account that can reset the others and the domain registrar, since control of the domain lets an intruder redirect everything else. Record where the backup codes are kept.
Build a backup an attacker cannot reach
The distinction that matters is not cloud versus local. It is whether a compromised administrator account can also delete the copy. Synchronisation services fail this test by design: corrupt or encrypt the source and the damage propagates to the copy within minutes.
Aim for copies that are offline, held under separate credentials, or write-protected once created. An external drive that is connected only while copying, stored away from the office, satisfies this cheaply. So does a storage service with versioning and a retention setting that an ordinary login cannot override. Two copies in different places is the usual minimum, and one of them should be somewhere a fire or a burglary would not reach.
Then do the part people skip: restore from the backup onto a clean machine and confirm the data opens. A backup that has never been restored is an assumption.
Write the recovery plan on paper
Keep it to a couple of pages. It needs: the order in which systems should be brought back, who is allowed to decide the organisation goes offline, the phone numbers of the people who hold access, the account details for hosting and registrar, and the location of the backups. Add whatever legal obligation applies in your jurisdiction — many places require notification to a data-protection authority within a fixed period when personal data is exposed, and that clock starts before anyone feels ready.
Print it. Store a copy at a member’s home. The recurring failure during an incident is that the contact list lives in the email system that is currently unavailable.
Rehearse a shutdown before one happens
Spend an hour walking through a scenario out loud with the people named in the plan. Assume the main server is unavailable and its contents cannot be trusted. Who is called first? Who tells contributors to stop submitting, and through which channel? Where does the group work from in the meantime?
Rehearsal exposes circular dependencies — the password manager reachable only through the compromised email, the sole volunteer who knows the hosting setup and is abroad. Fix what the exercise surfaces, then repeat it when the committee changes.
Decide what you will say and when
Draft a short holding statement now, while nothing is wrong: what happened in plain terms, what the organisation does not yet know, what contributors should do, and when the next update will come. Publishing it from a channel outside the affected systems — a social account, a mailing list on a separate provider — keeps you able to speak while your own site is down.
Say less than you are tempted to about technical detail during an active incident, and never claim data was unaffected before you have checked. Silence damages trust slowly; a confident statement that turns out to be wrong damages it quickly.
Avoid the mistakes people actually make
The common failures are not exotic. Treating file synchronisation as a backup. Keeping the only backup on a drive permanently plugged into the machine it protects. Giving every long-standing volunteer administrator rights as a courtesy. Leaving an unmaintained plugin or forum running because someone might still use it — old web software is a frequent entry point precisely because nobody watches it. Storing credentials in a shared document inside the systems being protected. Buying monitoring tools while the restore process remains untested.
One more: rushing to wipe and rebuild. Reinstalling immediately destroys the evidence needed to work out how the intruder got in, which means the same route may be open when you return.
Recognise when this approach is the wrong choice
This is preparation, not incident response. If an attack is under way, stop and get help — insurers, a national cyber agency reporting line, or a professional responder — rather than improvising containment.
It is also the wrong level of effort in two other cases. If the organisation holds sensitive personal data at scale, such as health information or detailed records about minors, a two-page volunteer plan is not sufficient and formal obligations apply. And if everything already runs on managed platforms with no self-hosted infrastructure, most of the above collapses into account hygiene and export routines; building a backup regime for data you do not really hold is wasted effort better spent elsewhere.
Frequently asked questions
What is the difference between a backup and a synchronised copy?
Synchronisation mirrors changes automatically, so deletion or encryption at the source reaches the copy almost immediately. A backup is a snapshot taken at a point in time and kept where the live system cannot alter it — on a disconnected drive, or under credentials separate from everyday accounts. Many organisations believe they have backups when they have only mirrors, and discover the difference during recovery.
Why do cyberattacks shut small organisations down for weeks?
Recovery time depends on preparation rather than on the size of the attack. A small group typically has one or two people who understand the infrastructure, no documented rebuild process, and backups that have never been tested. Each of those adds delay. Rebuilding servers, verifying that restored data is intact and re-establishing trusted access all take days when they are being worked out for the first time.
Should a nonprofit pay a ransom to get its data back?
Law enforcement agencies in most countries advise against it: payment funds further attacks, does not guarantee working decryption, and may breach sanctions rules depending on who receives the money. Some jurisdictions impose reporting requirements on payments. The decision should involve legal advice and any insurer, not be made under pressure by whoever is awake. Tested backups remove the question entirely.
How much should a volunteer organisation spend on security?
Most of the effective measures cost nothing: enabling multi-factor authentication, removing dormant administrator accounts, updating software, and documenting the recovery plan. The main cash items are backup storage and a domain and hosting arrangement that is not tied to one person’s personal account. Spending on monitoring or security tooling before backups are tested generally buys visibility into a problem you still cannot recover from.
Sources and further reading
- Ars Technica — reporting on the cyberattack against a meteor-tracking nonprofit and its expected period out of operation.
- National cyber security agencies, such as the UK National Cyber Security Centre and the US Cybersecurity and Infrastructure Security Agency — published guidance for small organisations on backups, account protection and incident reporting.
- Data protection regulators — published explanations of breach notification duties and the time limits that apply to them.
- Nonprofit technology support networks — practical write-ups on securing volunteer-run infrastructure and shared accounts.
Surfaced from the rss:arstechnica signal “cyberattack on a nonprofit”. AI-assisted draft, editorially reviewed.
