Volunteer offboarding: how should nonprofits handle logins and shared accounts?

Most nonprofits know who is on staff. Fewer can say which of last year's volunteers can still open the donor database, the shared inbox or the case management system. Volunteer offboarding closes that gap, and it starts the day a volunteer is first given a login.

Why are volunteer accounts a security risk for nonprofits?

Volunteer accounts are a security risk because volunteers come and go without the HR events that normally trigger account changes. A paid employee has a hire date, a last day and a manager who files paperwork. A volunteer often has a first shift, an informal handoff and then simply stops showing up, while the login to the donor database, the shared inbox or the client case system keeps working.

The data behind those logins is the kind California law protects. The state's customer records chapter defines a business to include nonprofit organizations, and Civil Code section 1798.81.5 requires a business that owns, licenses or maintains personal information about California residents to implement and maintain reasonable security procedures and practices. Under the state's breach notification law, section 1798.82, a username or email address combined with a password that would permit access to an online account is itself personal information. A volunteer's reused password showing up in someone else's breach can become your notification problem.

Is a shared volunteer login ever acceptable?

No, a shared volunteer login is not acceptable for systems that hold donor or client data. A shared login means no one can tell which person did what, the password has to be changed every time anyone leaves, and multifactor authentication either gets switched off or ends up tied to one person's phone. The CIS Critical Security Controls treat individual accountability as basic hygiene: Safeguard 5.2 calls for unique passwords, and Safeguards 6.3 and 6.4 require MFA for externally exposed applications and remote network access. All of these sit in Implementation Group 1, the starting set for small organizations.

Shared mailboxes are the common exception, and they work if set up correctly. Microsoft's guidance on shared mailboxes in Microsoft 365 is direct: "Always block sign-in for the shared mailbox account and keep it blocked." People reach the shared mailbox through their own accounts, so each person signs in individually and access can be removed one person at a time. Microsoft also notes that each person accessing a shared mailbox needs their own licensed Exchange Online mailbox, which is a budget question worth settling before you design volunteer access. Our guide to cleaning up shared mailboxes and generic accounts walks through the conversion.

What should happen when a volunteer starts?

When a volunteer starts, a staff member should own a short, written access request. CIS Safeguard 6.1 calls for a documented process for granting access, and Safeguard 5.1 calls for an inventory of all accounts that includes each person's name, username, start and stop dates, and department. For volunteers, the most useful additions are:

• A staff sponsor, the employee responsible for that volunteer's access and the person who will be asked whether it is still needed.
• An expected end date, even if it is a guess, such as the end of an event, a program cycle or a semester.
• The minimum access the role needs. A volunteer who stuffs envelopes for the gala does not need the full donor database export.
• An individual account with MFA, never a recycled login from the last volunteer.

Where your systems support it, set the end date in the system itself. Microsoft Entra access packages can expire on a date or after a set number of days, and SharePoint can expire guest access to a site automatically, so access ends even if nobody remembers to remove it.

How fast should a departed volunteer lose access?

A departed volunteer should lose access immediately when the departure is known, and after 45 days of inactivity when nobody announced it. CIS Safeguard 6.2 calls for a process for revoking access by disabling accounts immediately upon termination or role change, and notes that disabling rather than deleting preserves audit trails. Safeguard 5.3 covers the quiet departures: delete or disable dormant accounts after 45 days of inactivity, where supported.

That second rule matters more for volunteers than for staff, because many volunteers never send a resignation email. A monthly report of accounts with no sign-in for 45 days, reviewed by each sponsor, catches the people who drifted away. Safeguard 5.1 adds a quarterly check that every active account is still authorized.

What belongs on a volunteer offboarding checklist?

A volunteer offboarding checklist covers the main account plus every other place a volunteer picked up access, often in systems IT never provisioned:

• The organization's Microsoft 365 or Google Workspace account, disabled rather than deleted.
• The donor or case management system, which often has its own separate logins.
• Shared mailbox, Teams and SharePoint memberships, and any files shared to the volunteer's personal email.
• Social media, event platforms, email marketing tools and online payment dashboards they helped run.
• Group chats, shared password vault entries and any passwords they knew, which should be changed.
• Organization-owned devices, keys and badges.

If volunteers use their own phones or laptops, the controls in blocking unapproved AI sign-ups on volunteer devices also limit what organization data stays on those devices after they leave.

What should a nonprofit do this quarter?

• Pull a list of every account in your email platform and main databases, and mark which belong to volunteers.
• Assign a staff sponsor to each volunteer account and ask each sponsor to confirm which are still needed.
• Disable any volunteer account with no sign-in for 45 days.
• Replace shared logins with individual accounts, and convert shared inboxes to shared mailboxes with sign-in blocked.
• Add an expected end date and a sponsor to your volunteer onboarding form, and put the offboarding list above into your volunteer coordinator's checklist.
• Turn on MFA for every account that can reach donor, client or payment data. Our list of free cybersecurity wins for nonprofits covers where to start.

How does s90 help?

s90 manages identity and access for nonprofits as part of managed IT: account inventories, MFA, shared mailbox setup, expiring guest access and the monthly dormant account review, with reports your board or a funder can read. If volunteer turnover has left your account list longer than your volunteer roster, we can help you sort it out without disrupting the people who are still showing up.