Nonprofit Volunteer and Board Access: Secure File Sharing Without Shared Passwords

A shared “board” password may seem convenient until a trustee leaves, a volunteer changes roles, or a personal laptop goes missing. With several people using one identity, it becomes harder to establish who accessed a document and to remove one person without disrupting everyone else.

For nonprofits in Frederick, Maryland, a more manageable approach is individual identities, narrowly scoped workspaces, and a documented end date for access. Use this checklist when evaluating Microsoft 365 configuration or a managed IT proposal.

1. Match the account to the work

A board member reviewing meeting packets may need different capabilities from an employee managing daily operations. Start with the tasks, then choose the identity and licensing model.

• Guest collaboration: Microsoft supports basic document viewing and editing for external guests without assigning them a license in your organization. Permissions still determine what they can reach or change.
• Staff-style access: Someone who needs an organizational mailbox, personal OneDrive storage, or licensed desktop applications needs an appropriately licensed setup. Guest access does not automatically supply those services.
• Licensing review: Ask the provider to confirm applicable use rights, security-feature licensing, and nonprofit offer eligibility for each role. “Volunteer” or “board member” alone does not settle the licensing question.

Microsoft’s external-sharing overview explains guest capabilities and limits. Do not reuse an employee’s account or issue one login to an entire committee.

2. Separate board work from donor and client records

Create a dedicated board or committee workspace rather than inviting guests into a general staff site. Provide approved packets, minutes, and financial summaries there. Keep detailed donor records, personnel files, and client case notes in separately controlled locations.

Give a fundraising volunteer only the information needed for the assignment, not the entire donor database. Use view access when editing is unnecessary. Have the information owner approve exceptions and confirm any program-specific confidentiality requirements.

For confidential material, prefer authenticated, named recipients over “Anyone” links. Check existing links as well as the default for new sharing. Microsoft’s sharing settings distinguish these options; changing a default is not a review of every existing permission.

3. Decide what personal devices may do

Write down which work requires an organization-managed device and which may use an approved personal device. For bring-your-own-device access, define supported software, updates, screen locks, shared-device restrictions, and how to report loss. Explain any management requirements before enrolling a personal device.

SharePoint can restrict unmanaged devices to browser-only access without normal download, print, or sync options. This relies on Microsoft Entra Conditional Access and appropriate licensing. Browser, application, and file-type behavior need testing. Microsoft also notes that Anyone links are not affected by these device restrictions. Browser-only access cannot prevent someone photographing a screen.

Require multifactor authentication for staff and guest access through supported policies, then test the actual sign-in experience. CISA recommends the strongest available MFA, particularly phishing-resistant options. A guest invitation alone does not demonstrate that MFA is enforced.

4. Give every invitation an owner and an end date

Keep a simple access register with the person’s name, verified email, staff sponsor, approved resources, permission level, start date, and planned end date. Tie temporary access to the project or board term. Have a named backup sponsor when the primary contact is unavailable.

Review access after role changes and on a documented schedule. A quarterly review may suit a stable board; a short event project needs a check when it ends. These are planning examples, not universal legal deadlines.

Check what expiration actually covers. SharePoint guest expiration does not remove every other Teams or group entitlement, and pre-existing access can fall outside the policy. Automated Entra access reviews have feature-specific licensing requirements. A documented manual review remains useful when automation is not included.

5. Make offboarding a verified workflow

When service ends, the sponsor should notify whoever administers access. Remove the person’s relevant group memberships, direct permissions, and application access. If the relationship has fully ended, address the guest identity and active sessions through the appropriate administrative process. Preserve organizational records according to the approved retention plan.

Check for separately shared files and links, not just the main board workspace. Handle downloaded copies and returned devices under the organization’s policy: revoking cloud access does not retrieve files already copied elsewhere. Record completion and test access removal with a controlled test identity before relying on the workflow.

6. Ask the provider to demonstrate the proposal

Before approving a project, request a written scope and a demonstration using fictional documents:

• Can a test volunteer open the assigned folder but not unrelated donor or client information?
• Does forwarding the named-recipient link to an uninvited test account fail?
• Do MFA and personal-device restrictions work as proposed?
• Does removal end the intended access, including separately assigned permissions?
• Who handles invitations, reviews, urgent departures, and support, and which licenses or additional charges apply?

There is also a timely compatibility check: Microsoft is retiring legacy SharePoint one-time-passcode authentication in commercial tenants starting October 2026. Previously shared Specific people links can require a matching Entra B2B guest account when the change reaches the tenant. Entra B2B email passcodes remain supported. Have the provider test existing board access before the next meeting, rather than weakening sharing settings to fix an error.