Volunteer turnover is an access control problem, not just an HR one

The volunteer who left in March still has your donor list

Small nonprofits run on people who come and go. A board term ends, a student volunteer graduates, a grant-funded coordinator's contract finishes, and nobody circles back to switch off what that person could see. Phishing and account takeover attempts affected 94% of nonprofit organisations surveyed for a 2025 humanitarian and development sector cybersecurity report, up from 74% the year before, and nonprofit technology researchers point to the same root cause repeatedly - accounts and access that nobody owns once the person who set them up has moved on ^[1].

The pattern is familiar to anyone who has run a small organisation in Israel, Greece or Spain. A shared login gets handed from one treasurer to the next because creating a new account feels like paperwork. A departing volunteer's laptop had the donor spreadsheet synced to a personal OneDrive folder, and it is still there. An old committee member's email still forwards financial reports because turning it off might break something nobody wants to test. None of this is malicious. It is just what happens when access follows habit instead of a process.

Why shared logins and orphaned accounts are the real risk

A shared login has no accountability - if donor data is exported or a payment is approved, there is no way to know which of the six people who know the password actually did it. An orphaned account is worse, because it is a working set of credentials nobody is watching, sitting on a network long after the person behind it stopped checking their email. Researchers at UC Berkeley's Center for Long-Term Cybersecurity found that 46% of nonprofits cite funding as the primary obstacle to improving their security posture, which is real, but the fix here is not a bigger budget - it is a smaller number of standing exceptions ^[1].

Donor data sitting on a departed volunteer's personal drive is also a data protection problem, not only a security one. Under the GDPR, an organisation processing personal data must apply data minimisation and integrity and confidentiality safeguards to that data for as long as it holds it, which does not stop being true because the person who downloaded a spreadsheet is no longer volunteering ^[2]. A nonprofit in Greece or Spain processing EU donor and beneficiary data carries that obligation regardless of how informally the access was granted in the first place.

The joiner-mover-leaver routine, sized for a five-person office

Enterprises call this JML - joiner, mover, leaver - and it does not need enterprise headcount to work. It needs three lists that someone actually checks.

1. 1Joiner - a new volunteer or staff member gets their own named account, added to a group, never a shared password. The group, not the person, carries the permissions, so removing someone later is one click instead of a hunt through every system they might have touched.
2. 2Mover - someone changes role, say from fundraising to programmes. Their group membership changes with them. Nobody manually revokes and re-grants a dozen individual permissions, because there were never individual permissions to begin with.
3. 3Leaver - the account is disabled the day the person leaves, not whenever someone remembers. Disable first, delete later, so mailboxes and files can be reassigned to whoever inherits the role.

CISA's guidance on securing accounts recommends multi-factor authentication as a baseline control precisely because a single stolen or shared password is often the only thing standing between an attacker and an account ^[3]. Group-based access does not replace MFA, but it does mean that when MFA catches a suspicious login, you know exactly which account and which group to lock down, instead of guessing who else knows the shared password.

Group-based access beats shared logins even for a two-person IT team

The instinct in a small nonprofit is to keep things simple by keeping fewer accounts - one shared inbox for donations, one login for the accounting software, one password everyone on the board knows. That simplicity is exactly what makes recovery from a mistake or a breach almost impossible, because there is no single account to disable and no log that points to one person.

Group-based access flips this without adding complexity for the volunteer. Someone joining the "Fundraising" group gets the donor CRM, the mailing list tool and the shared drive folder in one step. Someone leaving loses all three in one step, because removing them from the group removes the access, rather than someone trying to remember which of five systems they were ever added to. The overhead moves from "remember every system a person touched" to "remember which group a person was in" - a much shorter list, and one a volunteer coordinator can maintain without any IT background.

Licensing that makes this affordable for a five-person nonprofit

The routine above assumes a directory that supports groups and MFA, and small nonprofits often assume that means an enterprise budget. It does not. Microsoft's nonprofit programme grants eligible registered nonprofits access to Microsoft 365 licensing at nonprofit pricing, provided the organisation can show it is a nonprofit in the country where it operates and that the person registering is a genuine employee or strategic volunteer rather than a third-party IT provider acting on the nonprofit's behalf ^[4]. Google runs an equivalent programme, and its own eligibility page states that an applying organisation must be a nonprofit charitable organisation in good standing and meet the programme's full published criteria before it can claim Google Workspace for Nonprofits access ^[5].

Both routes get a small nonprofit in Israel, Greece or Spain to the same place - a real directory where accounts belong to named people, groups carry permissions, and switching someone off is one action instead of a memory test. The eligibility check itself takes an afternoon of paperwork, not a procurement process, and it is the single highest-leverage thing a five-person nonprofit can do before writing a security policy nobody will read.

What to do this month, not this year

None of this requires hiring anyone. It requires deciding, once, that individual accounts and groups replace shared logins and personal drives, and then holding that line every time someone joins, changes role or leaves. Start with whoever handles donor data and financial approvals, because that is where an orphaned account or a leaked shared password costs the most, and work outward from there as capacity allows.