Nonprofit document permission model guide

Nonprofits keep sensitive files in many places: grant folders, donor records, finance drives, board packets, audit binders, and email. Permission problems appear when everyone can see everything or when no one can find the file they are allowed to use.

A document permission model gives the team a simple rule set. It says who can view, edit, approve, export, share, and delete each file type. It also says how access changes when staff leave, auditors arrive, or a grant closes.

Use this with the grant document management requirements guide and the auditor read-only access guide.

Start with document types

Do not begin with user names. Begin with file types.

Common nonprofit document groups include:

• grant agreements
• approved budgets
• invoices and payroll support
• donor restriction letters
• board packets
• audit evidence
• HR files
• contracts
• bank records
• Form 990 support

Each group may need different access. A grants manager may need to edit grant reports. That same person may only need to view finance support. A board treasurer may need read-only access to board finance materials, not donor notes.

Define actions, not just access

“Has access” is too broad. Separate the actions.

Use these permission actions:

• view
• upload
• edit
• approve
• export
• share
• delete
• manage access

Many users need view access. Fewer need edit access. Very few should delete files or manage permissions.

This is part of internal control design. 2 CFR 200.303 requires internal controls for federal awards. Document access is one place where those controls become practical.

Build roles around work

Use work-based roles, not personal exceptions. Examples include grants editor, finance reviewer, program viewer, board viewer, auditor read-only, and system admin.

Each role should match a real job. Avoid one-off roles like “Mary special access.” If Mary needs access because she reviews grant invoices, use the finance reviewer role.

Keep the role list short. Too many roles become hard to review.

Separate donor, grant, and finance access

Donor records, grant files, and finance support overlap. They should not collapse into one open folder.

Development may need donor intent and relationship notes. Grants staff may need award terms and report files. Finance may need source support, invoices, payroll reports, and fund coding. Leadership may need summaries and exceptions.

Design the model so each group can do its work without seeing unrelated sensitive files.

Use read-only access for review

Auditors, board members, consultants, and funders may need to review files. That does not mean they need edit rights.

Read-only access should show approved files, clear names, dates, and related records. It should prevent accidental edits. It should also leave an access record when possible.

If the system cannot support read-only review, create an evidence packet. The packet should be complete, dated, and controlled.

Protect deletion and retention

Deletion should be rare. A staff member should not be able to delete a grant agreement, invoice support, audit file, or restriction letter by mistake.

Record retention rules matter. 2 CFR 200.334 generally requires federal award records to be retained for three years after final report submission, with exceptions. Some donor, employment, tax, and state records may have different rules.

Your permission model should make retained files hard to delete and easy to find.

Review access on a schedule

Review permissions at least quarterly. Also review them when staff leave, board members rotate, contractors finish work, or auditors finish fieldwork.

The review should answer simple questions. Who has admin rights? Who can delete files? Who can export donor data? Who can see finance support? Who has access but no current role?

Write down changes. Access review is more useful when the team can prove it happened.

Add access logs where possible

NIST security guidance includes audit and accountability controls for information systems. A small nonprofit may not need a complex security program, but it should still value access logs.

Useful logs show who viewed, uploaded, edited, deleted, shared, or exported a file. They also show permission changes. Logs help when a file goes missing or an auditor asks who had access.

Plan for shared drives

Many nonprofits still use shared drives. If that is your current system, make the rules visible.

Use folder owners, naming rules, access groups, retention folders, and quarterly access review. Do not give every staff member edit rights to the whole drive. Do not store passwords or raw bank details in general folders.

Backups also matter. CISA lists backups as a core data protection practice. Backup rules should include document folders and permission records.

Test the model

Pick one grant file, one donor restriction letter, one invoice support file, one board packet, and one audit file. For each file, ask who can view, edit, approve, export, share, and delete it.

Then test a role change. What happens when a grants manager leaves? What happens when a board treasurer rotates off? What happens when audit fieldwork ends?

If the team cannot answer, the model is not ready.

Where GrantPipe fits

GrantPipe can be considered when grant documents, restricted funds, reports, and auditor access need clearer roles in one system. The permission model should still be written before setup so the tool follows the nonprofit’s rules.

DEFINITION

Permission model

The rules that decide who can view, edit, approve, export, share, or delete each file type.

DEFINITION

Read-only access

Access that lets a user see or download approved files without changing source records.