VRM & Compliance10 min read

Role-Based Access Control for Nonprofit Financial Systems

Role-based access control ensures that each person in your nonprofit can only access the financial data and functions required for their role — it is the first line of defense against fraud, errors, and audit findings related to segregation of duties.

Most nonprofit financial system breaches and fraud incidents do not start with sophisticated external attacks. They start with excessive internal access — a bookkeeper who can approve their own transactions, a staff member with admin credentials they don't need, a shared login that makes attribution impossible when something goes wrong.

Role-based access control ensures that each person in your nonprofit can only access the financial data and functions required for their role. It is the first line of defense against fraud, errors, and audit findings related to segregation of duties — and it is one of the most commonly cited deficiencies in nonprofit financial audits.


What Is Role-Based Access Control?

Role-based access control (RBAC) is a security model in which users are assigned to roles, and roles are assigned to permissions. Instead of configuring access for each user individually, you define what a Finance staff member can do, what a limited data entry staff member can do, and what a board member with read-only access can see — and then assign users to those roles.

RBAC accomplishes two things: it enforces the minimum necessary access principle (each user has only the access they need to do their job), and it enables segregation of duties by design rather than by policy.


Segregation of Duties: The Core Control

Segregation of duties is the internal control principle that no single person should be able to initiate, approve, and record a financial transaction. The principle exists to create a system of checks in which any error or fraudulent action by one person requires a second person to miss or ignore it.

In practice for nonprofits:

  • The person who enters a payment should not be the same person who approves it
  • The person who records a journal entry should not be the same person who can modify the chart of accounts
  • The person who reconciles bank accounts should not be the same person who has custody of cash receipts

When one person controls the full transaction cycle, fraud becomes easier to commit and harder to detect. The most common fraud schemes at small nonprofits — check tampering, unauthorized payments, payroll manipulation — succeed because there was no second set of eyes required by the system. A well-implemented RBAC structure makes that second set of eyes mandatory, not optional.


Why Small Nonprofits Give Everyone Admin Access

The path to everyone-has-admin access is understandable. The original system implementer created admin credentials and shared them. Configuring fine-grained roles in legacy accounting software is complicated, poorly documented, and time-consuming. The staff is small, everyone trusts each other, and the overhead of managing access carefully seems disproportionate to the risk.

This reasoning is self-undermining for two reasons.

First, trust is not a control. The ACFE's research consistently shows that fraud is most commonly committed by long-tenured employees in positions of trust. The factors that make a person seem trustworthy — tenure, reliability, dedication — are the same factors that give them the access and opportunity to commit fraud undetected over long periods.

Second, audit findings do not care about trust. When your external auditor assesses internal controls and finds that multiple staff members have admin access to the financial system, or that the same person can create and approve transactions, that is a finding regardless of whether anyone has ever misused the access. The finding reflects a control weakness, not an accusation.


Role Definitions for Nonprofit Financial Systems

A well-designed RBAC structure for a nonprofit financial system typically includes these roles:

Owner. Full system access including user management and system configuration. Typically limited to one or two individuals at the executive or IT level. The owner role should not be used for daily accounting functions — its value is in administration, not operation.

Admin. Access to all financial data and functions except user provisioning. Appropriate for the Controller or CFO who needs complete operational access but should not manage user accounts (which should require owner-level access to prevent self-provisioning of elevated permissions).

Finance. Transaction entry, report generation, bank reconciliation. Cannot approve transactions they create. Cannot modify user roles. The standard role for accounting staff.

Staff. Limited data entry for specific functions — expense submissions, time tracking, program data entry — with no access to financial reporting or GL functions. Appropriate for program staff who submit expenses or enter program data.

Readonly. View-only access to reports and data. Appropriate for board members, auditors during review, and program directors who need visibility into financial data but should not be able to modify records.

This five-role structure maps directly to the segregation of duties requirements in the COSO internal control framework and satisfies the access control questions that come up in most nonprofit financial audits.


Row-Level Security: The Next Layer

Role-based access at the function level — can or cannot approve transactions — should be paired with row-level security that controls what data within a function is visible to a given user.

For nonprofits, row-level security is particularly relevant in three areas:

Fund access. A program manager might appropriately have view access to their program's financial data but should not see financial data for other programs. Row-level security enforces this boundary within the Finance or Staff role.

Payroll data. Staff with access to accounting data should not necessarily have access to salary information for their colleagues. Payroll records should be restricted to users whose role specifically includes payroll functions.

Major donor records. Development staff need access to donor financial data that may be inappropriate for Finance staff to see in the same level of detail, and vice versa.

Row-level security distinguishes a mature RBAC implementation from a basic one. It prevents information exposure that does not rise to the level of a transaction-integrity control, but matters significantly for privacy and governance.


Compensating Controls for Small Organizations

True segregation of duties requires at least two people involved in every significant transaction cycle. Many small nonprofits have one or two finance staff, making full segregation impossible without external involvement.

Compensating controls reduce risk when staff constraints prevent full segregation:

  • Board review of bank statements. A board officer or audit committee member who reviews bank statements monthly provides an independent check without requiring a second finance staff member.
  • Dual authorization for disbursements above a threshold. Any payment above a defined amount — $1,000 is a common threshold for small organizations — requires a second approval.
  • Management review of reconciliations. Bank reconciliations reviewed and signed off by the Executive Director or CFO, not just prepared by the bookkeeper.
  • Periodic surprise reviews. Unannounced reviews of petty cash, credit card charges, or vendor payment history by the board audit committee create deterrence even when they do not find problems.

Compensating controls should be documented in the organization's internal controls policy. Auditors will ask about them, and an undocumented verbal description of informal practices is not a satisfactory answer.


The COSO internal control framework identifies control environment and monitoring activities as two of its five components. Both are directly implicated by access control failures. Common audit findings include:

  • Multiple users with administrator access who do not require it for their job functions
  • Shared login credentials that prevent individual attribution of actions in the audit trail
  • No formal access review process — access is never revoked when roles change or staff depart
  • Staff who can create and approve their own transactions in the accounting system
  • Former employees who retain active system credentials after termination

Each of these findings is directly addressable with proper RBAC implementation. Each also represents a real financial risk, not just a compliance checkbox.

The Role-Based Access feature in sherbertOSOS includes five pre-built roles — owner, admin, finance, staff, and readonly — with row-level security enforced at the database layer. Access configuration is a user management decision made at onboarding and updated as roles change. When your auditor asks about segregation of duties, the answer is a system configuration report.

For the audit trail infrastructure that complements role-based access, see Why Audit Trails Matter for Nonprofit Financial Data. For the broader audit preparation process, see Nonprofit Audit Preparation: The Complete Checklist.


Frequently Asked Questions

What is segregation of duties?

No single person should be able to initiate, approve, and record a financial transaction. Separating these functions prevents fraud by requiring at least two people to be involved in any fraudulent transaction cycle, and reduces errors by creating independent verification at each step.

What roles should a nonprofit financial system have?

At minimum: an admin or owner role (full access for system management), a finance role (transaction entry and reporting with no self-approval), a staff role (limited data entry), and a readonly role (view-only for board and auditors). Five-role structures that separate owner from admin provide stronger controls.

What if we are too small for full segregation of duties?

Compensating controls can offset the risk: board review of bank statements, dual authorization for larger disbursements, management review of reconciliations, and periodic surprise audits. Document all compensating controls in your internal controls policy — undocumented controls do not satisfy auditors.

How often should user access be reviewed?

At least annually, and immediately when staff roles change or when someone leaves the organization. Access that is not actively revoked persists indefinitely. Former employees retaining system access is a common and easily preventable audit finding.

What is row-level security and why does it matter?

Row-level security controls which records within a data set a user can see, separate from their functional permissions. It prevents information exposure — for example, a staff member with data entry access seeing salary records for their colleagues — that function-level permissions alone do not address.

Does RBAC prevent all internal fraud?

No. A sufficiently determined employee with appropriate access can still commit fraud. What RBAC does is make fraud significantly harder by eliminating single points of control, creating audit trail records of every action, and requiring collusion to circumvent the controls. Most opportunistic fraud — the most common type — depends on single-person control of a transaction cycle. RBAC removes that opportunity.


The Bottom Line

Access control is not a technology problem. It is a governance decision that determines how financial controls are enforced in your organization's daily operations. Every admin credential issued unnecessarily is a segregation of duties failure waiting to become an audit finding or a fraud incident.

The organizations that handle this well are not the ones that trust their staff more. They are the ones who understand that controls are not a sign of distrust — they are the mechanism by which good people are protected from both mistakes and false accusations.

→ Request a demo and see how sherbertOSOS role-based access enforces segregation of duties from day one.

Frequently Asked Questions

What is segregation of duties?

No single person should be able to initiate, approve, and record a financial transaction. Separating these functions prevents fraud and errors.

What roles should a nonprofit financial system have?

At minimum: admin (full access), finance (transaction entry and reporting), staff (limited data entry), and readonly (view-only for board members and auditors).

What if we're too small for segregation of duties?

Compensating controls — like board review of bank statements, dual signatures on checks, and regular surprise audits — can offset the risk when staff is limited.

Related Articles

See sherbertOS in action

Schedule a personalized walkthrough with our team.

Request Demo