Volunteers and part-time staff have system access, handle sensitive data, and rarely get security training. Here's why that's a problem and what to do about it.
TL;DR: Volunteers and part-time staff show up because they believe in your mission. They also show up with system access, personal devices, and almost no security training, cycling in and out of your organization faster than your full-time security practices can keep up with. The vulnerabilities they create aren't the result of bad intentions. They're the result of an organization that built its security posture around its permanent team and never fully extended it to the people doing a significant portion of the work.
Ask most nonprofit leaders to name their biggest cybersecurity risk and they'll say phishing emails, aging hardware, or a tight budget that hasn't kept pace with threats. All of those are real. But there's a risk that sits closer to home and gets named a lot less often.
It's the volunteer who's been helping with donor data entry every Tuesday for two years, using a login that was set up the week she started and hasn't been reviewed since. It's the part-time program coordinator who processes client intake on a personal laptop because nobody ever set him up with a work device. It's the board member who has admin access to the financial system because it seemed easier at the time, and who still has that access eighteen months after rotating off the board.
Think about a community theater production. The cast and crew might number fifty people over six weeks, most of them volunteers. The production manager hands out keys, access codes, and schedules. But when the show closes, does every key come back? Does every access code get changed? The costumes go into storage, the set gets struck, and the access just lingers. Nobody meant for it to happen that way. It just did.
Mission-driven organizations run on exactly this kind of distributed, rotating workforce. It's one of the things that makes them remarkable. It's also one of the things that makes them vulnerable in ways that full-time staff policies were never designed to address.
The good news is that fixing this doesn't require a large budget or a security team. It requires acknowledging the gap and building a few deliberate practices around it. Here's where the risk lives and what to do about it.
CISA defines insider threats as any person with authorized access whose actions, intentional or not, could harm an organization's mission, resources, or systems. The definition explicitly includes contractors, vendors, and anyone given access to complete their work, not just full-time employees.
Volunteers and part-time staff fit that definition exactly. They have authorized access. They handle sensitive data. And the vast majority of the risk they create is unintentional: the well-meaning volunteer who clicks a phishing link, the part-time coordinator who reuses a password across every account she has, the board member who forwards a sensitive document to the wrong email address. Nobody meant to create a problem. The problem exists anyway.
What makes this population distinctly risky is a combination of three things that tend to show up together. They have enough access to cause real harm. They move through the organization on schedules that make consistent oversight genuinely difficult. And they exist largely outside the security conversations that happen at the full-time staff level, because the people having those conversations aren't thinking about them when they design the policies.
That last one is the core issue. Most security programs are built around permanent employees: their devices, their accounts, their training cadence, their offboarding process. The rotating workforce operates in the gaps of that structure, not because anyone decided they didn't matter, but because nobody designed the structure with them in mind.
The most common access control failure in mission-driven organizations isn't a sophisticated attack. It's an account that was set up appropriately on day one and never looked at again.
A volunteer starts helping with data entry and gets a login. That login gives her the access she needs for the task at the time. Nobody reviews whether that access level is still appropriate after she takes on different responsibilities. Nobody reviews it after she reduces her hours. And when she eventually stops coming in, the account stays active because there's no process that catches it.
Run that pattern across every volunteer and part-time staff member who's cycled through your organization in the past three years. Most of those accounts still exist. Most still have their original permissions. Some of those people haven't walked through your door in eighteen months.
This is the minimum necessary access principle that good security practice requires: people should have access to what they need to do their job, and nothing more. It sounds simple. It requires intention to maintain, because the default in most organizations is that access accumulates rather than shrinks.
The fix has two parts. The first is configuring access based on role rather than individual, so that when someone's responsibilities change, their access changes with it. The second is a scheduled review, ideally annual, where someone goes through every account with access to sensitive systems and confirms it still makes sense. Not a one-time project. A habit.
Many volunteers and part-time staff do organizational work on personal devices. Personal laptops for document creation. Personal smartphones for communication apps. Personal email accounts because setting up an organizational one felt like more overhead than it was worth at the time.
Each of those situations creates a data boundary problem your organization probably hasn't fully addressed. Sensitive donor records, client intake information, financial data: anything that lives on a personal device is data your organization can't monitor, can't secure, and can't recover if the device is lost, stolen, or the person simply stops returning your calls. The FTC's guidance on protecting personal information is clear that organizations are responsible for data in their possession, regardless of what device it sits on. Personal laptop is not a defense.
The practical solution isn't providing a device to every volunteer, which isn't realistic for most organizations. It's making deliberate decisions about what data can be accessed from personal devices and under what conditions. Browser-based tools that don't require data to be stored locally wherever possible. Clear guidance for volunteers and part-time staff about what they can and can't do from a personal device. And a conversation, at onboarding rather than after an incident, about why those boundaries exist.
Most volunteers will follow reasonable guidelines when they understand the reason behind them. The organizations that struggle with this aren't the ones with bad volunteers. They're the ones who never had the conversation.
Most organizations that do security awareness training do it annually for full-time staff. Volunteers and part-time staff are often left out entirely, because scheduling is difficult, because they're not technically employees, because it feels like significant overhead for people who are only in once a week.
That logic made more sense when phishing emails were obvious and attacks were less targeted. It doesn't hold up in 2026, when AI-generated phishing is indistinguishable from legitimate communication and credential-stuffing tools run automated attacks against every account they can find. A volunteer who processes donor data every Tuesday is as likely to receive a targeted phishing email as anyone on your full-time team. The fact that she's part-time doesn't reduce the risk. It just reduces the training she's received to recognize it.
Effective security training for a rotating workforce doesn't have to be elaborate. A short onboarding module that covers three things: what a current phishing attempt actually looks like, what to do if something seems wrong, and who to tell. An annual update that reflects how attacks have changed rather than recycling the same content from three years ago. And a culture where reporting something suspicious feels like the right call rather than an overreaction.
That last one matters more than any training content. If your volunteers and part-time staff don't feel comfortable flagging something unusual because they're not sure it's worth mentioning or they don't know who to tell, your early warning system has a significant gap in it. The organizations that catch problems early are almost always the ones where people feel safe reporting them.
When a full-time employee leaves, most organizations have some version of a process. HR initiates it, IT executes it, access gets revoked. It's imperfect in a lot of places, but at least it exists as a defined step.
When a volunteer stops coming in, or a part-time staff member's contract ends, or a board member's term concludes, the process often doesn't follow. There's no HR trigger. There's no IT checklist. The person just stops showing up, and their accounts stay active because nothing in the organization's workflow is designed to catch it.
Active accounts belonging to people who no longer have a relationship with your organization are exactly what attackers look for. A credential that hasn't been used in months but is still valid is unlikely to trigger any alerts when it's compromised. CISA's insider threat guidance specifically identifies former insiders, people who retain access after their relationship ends, as a documented risk category, whether the retention was intentional or simply overlooked.
The fix is straightforward: an offboarding checklist that applies equally to volunteers, part-time staff, board members, and contractors, with system access revocation as a non-negotiable line item. It doesn't need to be long. It needs to exist, be executed every time without exception, and be owned by someone specific rather than assumed to happen on its own.
One practical addition worth building in: a recurring calendar reminder, quarterly or annually, to review active accounts against your current roster. People fall through the cracks even with a good offboarding process. A periodic sweep catches what the process misses.
The organizations that manage volunteer and part-time staff security well share a handful of consistent practices. None of them require sophisticated technology or a dedicated security team.
Role-based access from day one. Access gets provisioned based on what someone actually needs to do their specific role, not a generic account with broad permissions. When the role changes, the access changes with it.
Unique logins for every person. Shared credentials are impossible to audit and impossible to revoke cleanly. Every volunteer and part-time staff member gets their own login, full stop.
MFA on any account touching sensitive data. A stolen password paired with MFA is useless to an attacker. This one control closes a disproportionate amount of risk for the effort it takes to implement.
A short security onboarding for everyone. Not a full training program. Fifteen minutes covering what phishing looks like today, what to do if something seems off, and who to tell. Delivered before someone starts, not six months in.
An offboarding checklist with teeth. System access revocation is a non-negotiable step, applied consistently to every departure regardless of how long the person was there or how they left.
These five practices don't eliminate every risk. They close the gaps that account for the vast majority of incidents involving this population, and they do it without requiring resources most mission-driven organizations don't have. For the broader security baseline these practices build on, Running Lean, Running Secure: A Technology Guide for Nonprofits, Schools, and Local Government covers the full picture.
The people cycling through your organization as volunteers, part-time staff, and board members aren't a security liability by nature. They're a security liability by neglect, and that's a fixable problem. Every gap described in this post, the over-permissioned account, the personal device with donor data on it, the former board member whose login still works, exists because someone built a security program around permanent employees and didn't extend it far enough. Not because they didn't care. Because nobody told them they needed to.
The broader reality for mission-driven organizations in 2026 is that attackers don't distinguish between a breach that came through a full-time employee and one that came through a Tuesday volunteer. The data is the same. The consequence is the same. The families, clients, and donors whose information your organization holds deserve the same level of protection regardless of whose hands it passed through on the way to being compromised.
Mann IT works with Michigan nonprofits, private schools, and local government agencies that want security practices built around how they actually operate, including the rotating workforce that most IT programs treat as an afterthought. We're based in Ann Arbor and we've helped organizations build access control processes, offboarding checklists, and security training programs that actually reach the volunteers and part-time staff who need them most. That means nobody who shows up for your mission gets left outside the security posture protecting it.
If your current setup was built around your permanent team and hasn't been extended further, that's exactly the conversation worth having. Get in touch with Mann IT for a consultation about where your current practices leave gaps.
1. How do we handle security training for volunteers who only come in occasionally?
Keep it short and make it part of onboarding. A fifteen-minute module covering current phishing tactics, what to do if something seems wrong, and who to tell is far more effective than a comprehensive training that never gets scheduled. For long-term volunteers, a brief annual update is reasonable. The goal isn't comprehensiveness. It's making sure everyone who touches your systems knows the most important things before they start.
2. What's the minimum we should do to secure volunteer access without creating a lot of overhead?
Four things: provision access based on actual role, require unique logins rather than shared credentials, add MFA to any account touching sensitive data, and include account deactivation on your offboarding checklist. Those four steps address the majority of volunteer-related security risks without significant infrastructure or ongoing overhead.
3. Are we liable if a volunteer causes a data breach?
Generally yes. The organization is responsible for data in its possession and for the access it grants to that data, regardless of employment status. If a volunteer's account is compromised because it had excessive permissions or was never deactivated after they left, the organization bears responsibility. Treating volunteer access with the same intentionality as employee access isn't just good practice. It's necessary risk management.