A VPN Is Not a Security Plan for a Small Nonprofit

Small organisations buy a tunnel and assume they have become secure. What actually happens is that the tunnel protects one leg of one journey while the donor spreadsheet stays shared with anyone who has the link, the domain renews on a card nobody updated, and the only person who can restore the case files is on a break. A VPN is a useful control. It is not a plan, and it cannot be one.

Why the tool comes last

A tunnel protects traffic between a device and the network on the other end. That is a real and specific protection, and it says nothing about who may open a shared folder, whether a sign-in page was genuine, or whether last month's data still exists.

Most losses at small organisations arrive through those other doors. An account takeover, an over-shared document and an unrecoverable laptop are three failures that a working VPN does not touch. None of them requires anyone to break the tunnel.

Starting with the tool also inverts the budgeting conversation. You end up paying for something that solves a problem you have not named, while the unglamorous gaps stay open because nobody wrote them down.

Start with three real workflows

Pick the work the organisation actually does rather than a threat catalogue. Three workflows are enough; ten produce a document nobody finishes. A donor list, a set of sensitive case documents and a public website are three different problems with three different failure modes.

For each one, write down what is valuable, who legitimately needs access, who might misuse it, and what the consequence would be if it were disclosed, altered or simply gone. The last question is the one teams skip and the one that produces the most useful actions.

Include the people whose information appears in those records, not just the organisation's equipment. A donor list is a list of other people's details, and that framing changes how much care is proportionate. A list of donors is a list of other people's details, and that framing changes how much care is proportionate.

EFF's planning guide structures this around assets, adversaries, likelihood, consequences, effort and allies. What makes it usable for a small team is that it asks you to choose where limited attention goes instead of promising that everything will be safe.

Accounts and the recovery path

Identify who controls email, cloud storage, the domain registration and administrative access. Then check whether those are separate authorised accounts or one shared login that three people know. Shared logins turn every departure into a password reset nobody can audit.

Turn on supported multifactor authentication for the accounts that matter, and write down what happens when a staff member or volunteer leaves. Include how a replacement device gets enrolled, because that is the step that creates the next shared password. Access that only ever gets granted is access that quietly accumulates.

Plan recovery while everything still works. Know which information has an independent copy, who can restore it, and how the team reaches support when its normal email or private network is unavailable. A checkbox claiming that backups are enabled proves nothing. A restore somebody has actually performed proves quite a lot.

Name a second owner for critical accounts. A volunteer's personal mailbox must not be the only way back into the organisation's own website, and that one sentence prevents a category of very bad week.

Give the VPN one specific job

If staff need to reach a private office service, a supported tunnel is a reasonable way to deliver that. Keep the access list to the people, devices and services that need it, and leave the service's own authentication where it is.

If the team works entirely through well-configured cloud applications, establish what a new tunnel would actually change before buying one. In many small organisations the honest answer is nothing measurable, and the same money spent on account hygiene and a tested restore would do more.

Anonymity tooling is the same story in a different direction. It addresses particular observer relationships, not every organisational risk, and it is not a substitute for handling sensitive beneficiary data carefully.

Where the work involves targeted threats or unusually sensitive information, bring in qualified help for that context. A generic recommendation from a peer organisation is not a threat assessment.

What the one-page plan contains

Finish with a short list rather than a document nobody reads: the most consequential unresolved risks, the action chosen for each, an owner, and the next review date.

One page is enough because it is meant to be revised. Revisit it when a new service appears, when a volunteer joins or leaves, and when a data-sharing relationship changes.

That is a security program a small team can actually maintain, and the VPN earns its place inside it by solving a problem someone wrote down.