AdaptAI ConsultingVisit Website →
← Back to blog

Role-Based Access Control: How to Set Up Roles and Permissions

November 5, 2026
Role-Based Access Control: How to Set Up Roles and Permissions

Role-based access control (RBAC) is a way of giving people access to your systems based on their job, not on who they are. You define roles such as bookkeeper, sales rep or office manager, attach permissions to each role, and assign people to roles. When someone joins, changes jobs or leaves, you change their role instead of rebuilding their access piece by piece. IBM describes it as authorizing access to systems, applications and data based on a user's predefined role.

This guide is written for owners and managers of small and medium businesses in Canada. It covers how RBAC works, how to design roles that stay manageable, how it compares with attribute-based access control, and what to do when your tools are scattered across five different logins.

AdaptAI
Bring business tools into one system
AdaptAI builds custom software that connects operational tools and data behind one login, helping small businesses manage access across their systems.
Explore AdaptAI

Table of Contents

How does role-based access control work?

The model has three moving parts: users, roles and permissions.

  • Users are the people (or sometimes services) who sign in.
  • Roles are job functions, such as "invoicing clerk" or "service technician".
  • Permissions are specific actions on specific data: view a customer record, edit an invoice, export a report.

Permissions are attached to roles, and users are attached to roles. A user never receives a permission directly. The Canadian Centre for Cyber Security describes RBAC as an access control policy that enforces access to objects and system functions based on the subject's defined role, with users inheriting the privileges defined for the roles they hold. NIST's RBAC project puts the same idea strictly: all access goes through roles, and permissions connect only to roles, not to individual users.

A simple example: your "salesperson" role can view and edit the customer database. Everyone in sales gets that role. Cloudflare's explanation notes that roles are generic rather than tailored to one employee, and that if a particular salesperson needs more, you assign an additional role instead of inventing special permissions for them.

One point trips people up: RBAC is not authentication. MongoDB's documentation is clear that it manages what a person can do after they have proven who they are. Passwords and two-factor sign-in answer "who are you?". RBAC answers "what are you allowed to do?"

Why does RBAC matter for a small business?

Small teams often skip access design because "everyone knows everyone". Then the part-time bookkeeper has admin rights on the CRM, a former employee still has a login to the scheduling tool, and nobody can say who can see payroll figures. RBAC fixes this in three practical ways.

  1. Less administration. Okta lists reduced complexity, easier onboarding, fewer mistakes and lower overall cost among the benefits. Changing one role updates everyone who holds it.
  2. Least privilege by default. The Canadian Centre for Cyber Security's baseline controls for small and medium organizations advise granting only the minimum access a job function needs, which limits the damage if an account is misused or compromised.
  3. Easier reviews. IBM points out that RBAC simplifies reviewing access because roles are relatively stable, while users and permissions change quickly. You review a handful of roles, not every person's individual settings.

There is also a sign that this is mainstream good practice, not enterprise overkill. The Government of British Columbia's Access Control Security Standard (IMIT 6.24), effective 10 November 2021, requires need-to-know and least privilege, a deny-all default before access is granted, and permissions assigned to roles rather than to individual user IDs. That standard binds the provincial government, not your company, but it is a sound template for a business in B.C.

How do you set up user roles and permissions step by step?

You do not need special software to start. You need a spreadsheet and an hour with the people who know the work.

1. Inventory who has access to what

The Cyber Centre's guidance for small organizations makes this the first step: document who has access to which systems and at what level. Expect surprises. Most businesses find old accounts, shared logins and people with far more access than their job needs.

2. Group the work into roles

Start from tasks, not names. Ask what each job actually needs to see and change. A typical 20-person service business might land on five or six roles:

RoleTypically needsTypically does not need
Owner / administratorEverything, including user managementNothing is off limits, but use a separate standard account for daily work
Operations managerScheduling, job records, reportsPayroll details, system settings
SalesCustomer records, quotes, pipelineSupplier payments, other staff's pay
BookkeeperInvoices, payments, financial reportsEditing customer contact history
Field staffTheir own schedule and job notesPricing, financials, other people's jobs
Read-only (advisor, accountant)Reports and records, view onlyAny edit rights

Okta's suggested approach is to identify roles together with management and HR, plan a timeline and invite feedback before rolling the plan out. Staff often know better than managers what a job really touches.

3. Start from deny-all

Give a new role nothing, then add what the job requires. This mirrors the deny-all default in the B.C. standard above. It is much easier to add a permission someone asks for than to discover later that a role was too generous.

4. Give each person their own account

The Cyber Centre recommends unique individual accounts and no shared credentials. Roles are pointless if three people share one login, because you can no longer tell who did what.

5. Separate admin accounts from daily accounts

The Cyber Centre also advises that administrator accounts be used only for administrative tasks, with standard accounts for email and browsing. If you are the owner, that means two logins for you.

6. Write it down

One page per role: what it is for, what it can do, who holds it, who approves changes. This is the document you will use for onboarding, offboarding and reviews.

Do you already use RBAC without knowing it?

Probably. Many tools Canadian businesses use every day are built on roles.

  • The CRA's Represent a Client service lets a business assign employee roles, including Junior and Senior administrators, with different access to functions and client information.
  • Corporations Canada distinguishes between full access managers and filing collaborators, and says only a director or authorized agent such as an officer can be a full access manager.
  • In QuickBooks Enterprise Desktop in Canada, businesses can create custom roles with levels such as View Only and Create and Modify.

The pattern is the same each time: a few well-defined roles, assigned to named people. The trouble starts when each tool has its own role list, managed in its own place, with no connection between them.

What are the limits of RBAC, and how do you avoid them?

RBAC works well, but it fails in predictable ways. Knowing them lets you design around them.

Role explosion. If you create a new role every time someone needs something slightly different, you end up with dozens of near-duplicates. Pathlock describes this as the most commonly reported RBAC challenge in large enterprises, with administrators managing hundreds or thousands of roles. For a small business the fix is simple: cap your role count, and handle the odd exception by adding a second role to a person, not by cloning a role.

Scope creep. Over time, roles collect permissions and rarely lose them. The Cyber Centre notes that RBAC can increase privacy and security risk if people in a role get access to more information than they need. Quebec's cyber defence centre makes the same point. The remedy is a regular review.

Documentation and multi-tenancy. The OWASP Access Control Cheat Sheet lists stringent documentation, difficulty with multi-tenancy and lack of support for data-based access control among the typical problems. If you serve several client organizations from one system, plan for that early.

Rules that depend on context. Roles say who someone is in the organization. They do not easily express rules like "only for accounts in their own region" or "only during business hours". That is where attribute-based access control comes in.

What are the limits of RBAC, and how do you avoid them?

How does RBAC differ from attribute-based access control (ABAC)?

RBAC decides by role. ABAC decides by evaluating rules against attributes. NIST defines ABAC, as summarized by archTIS, as a model that evaluates rules against the attributes of the user, the resource, the operation and the environment to grant or deny a request.

RBACABAC
Decision based onThe user's roleAttributes of user, resource, action and context
Example ruleBookkeepers can edit invoicesBookkeepers can edit invoices under a set amount, for their own branch, during working hours
Setup effortLow to moderateHigher, needs well-maintained attributes
Fit for a small businessUsually the right starting pointAdd selectively where roles are too blunt

For most businesses with under a few hundred staff, RBAC covers the vast majority of needs. A common approach is to start with roles and add a few attribute-style conditions (such as "own records only") for the situations that need them. You do not have to choose one forever.

How often should you review roles and offboard people?

Treat access as something that drifts. Set a recurring calendar reminder to go through each role and each person holding it, and confirm both are still appropriate. Review administrator roles more often than standard ones.

Offboarding is the review that matters most. The Cyber Centre's guidance for protecting information advises promptly and completely revoking access when an employee leaves. With a role-based setup this is one step per system. With shared logins it is a scramble to change every password.

The same discipline applies to the technical keys that connect your systems. If your software talks to other services through API keys, rotating them on a schedule belongs in the same routine, and automating API key rotation keeps that from depending on someone's memory.

How often should you review roles and offboard people?

Two more habits worth adding: turn on two-factor authentication wherever it is offered, and monitor audit logs so you can see who changed what, as multi-user QuickBooks guidance recommends. If your environment is large enough, the Cyber Centre also suggests considering centralized authorization such as LDAP or Active Directory.

Perspective: why separate tools make access control harder

We see the same pattern in almost every small business we work with. The CRM has one list of users, the invoicing tool has another, the scheduling app has a third, and reporting lives in a spreadsheet someone emailed around. Each system has its own idea of what a "manager" can do. Nobody designed that. It accumulated.

The result is that role-based access control exists on paper but not in practice. When someone leaves, you have to remember five places. When someone changes jobs, you update two and forget three. That is not a discipline problem. It is a structure problem.

Our view is that the cleanest way to get roles right is to have one system, with one login and one set of roles, covering CRM, invoicing, scheduling and reporting. You define "bookkeeper" once, and it applies everywhere the bookkeeper works. That is what we build: custom software designed around your actual processes, where the roles match your org chart and not a vendor's default template. Our clients own the code, so there is no lock-in on how your permissions are structured.

We would also say plainly that software does not replace judgment. Someone still has to decide who needs what, and teams need to understand why. That is why we pair builds with training tailored to real tasks. Clients typically report saving 5 to 15 hours of administrative work per week after implementation, and tighter, clearer access is part of what makes that work run smoothly.

Harry Gill

When does it make sense to build roles into one custom system?

Off-the-shelf tools are a reasonable choice when your processes are standard and each tool's built-in roles fit your needs. A custom system tends to pay off when:

  • You use three or more tools that each need their own user management.
  • Your real-world roles (for example, "estimator who can see quotes but not margins") do not match any tool's preset roles.
  • You need one audit trail across sales, billing and scheduling.
  • Staff turnover or seasonal hiring makes onboarding and offboarding a recurring chore.

If you are weighing this, our guides on custom software versus off-the-shelf and on a checklist for custom business software for Canadian SMEs walk through the decision. If the CRM is the main pain point, see when a custom CRM pays off.

How AdaptAI can help

AdaptAI builds custom software for small and medium businesses in Surrey and Metro Vancouver, bringing CRM, invoicing, scheduling, reporting and workflow automation together behind one login. Roles and permissions are designed around how your team works, at a fixed price with regular milestones and local support.

AdaptAI

If you are not ready for a full build, our AI strategy consulting and discovery work is a lower-commitment way to map your current tools and access. To talk through a unified system, start at adaptai.ca.

FAQ

What is the difference between RBAC and user permissions?

Permissions are the individual actions someone can take, such as viewing or editing a record. RBAC is the method of organizing them: permissions are bundled into roles, and people are assigned to roles. Without roles, you manage permissions person by person, which becomes hard to track as the team grows.

How many roles should a small business have?

There is no fixed number, but fewer is better. Five to eight roles cover most small teams, based on job functions such as admin, sales, finance, operations and read-only. If you keep needing exceptions, add a second role to the person instead of creating a new near-duplicate role, since too many roles is a well-known RBAC problem.

Is RBAC the same as authentication?

No. Authentication confirms who someone is, through a password or two-factor sign-in. RBAC controls what that person can do once signed in. You need both.

Do I need RBAC if I only have a few employees?

Yes, in a simple form. Even a team of five benefits from separating admin access from daily accounts, giving everyone their own login and limiting finance data to the people who handle it. The Cyber Centre's small-organization guidance recommends least privilege and an access inventory regardless of size.

Sources