Role-based access control for a small business

A new ward manager starts on Monday. She needs to approve her nurses’ leave, see who has clocked in for the night shift and complete their probation reviews. She does not need payroll, the hiring pipeline or the board’s shared folder. Getting that right is what role-based access control is for, and it matters as much in a forty-person clinic or school as in a bank. This guide explains roles and permissions in plain words, how to set them up without a security team, and where small organisations usually go wrong.

Roles vs permissions, in plain words

A permission is one thing a person may do: view the team timesheet, approve leave, manage users. A role is a named bundle of permissions that matches a job: Employee, HR Manager, Ward Manager. You give people roles, never loose permissions, so that everyone doing the same job has the same access and changing that job’s access is one edit, not forty.

NIST, the US standards body, defines role-based access control as a model where “permitted actions on resources are identified with roles rather than with individual subject identities”. The model was formalised by David Ferraiolo and Rick Kuhn in 1992, and NIST’s model became an American national standard in 2004. You do not need the standard to use it; you need the habit of asking “which job is this?” before “which person is this?”.

Why it matters in a small organisation

Small organisations tend to skip access control for an understandable reason: everyone knows everyone. The trouble starts quietly. The office manager was made an admin to fix one thing in 2023 and still is. A team lead can see everybody’s salary because the HR tool had only two levels, admin and not admin. A leaver’s account still opens the shared drive. None of these is a breach until the day it is.

The principle that fixes this is least privilege, which NIST describes as restricting access “to the minimum necessary to accomplish assigned tasks”. It is not about distrust. A person who cannot see payroll cannot leak it by mistake, cannot be phished for it and does not have to be careful with it.

What good looks like

• Few roles, named after jobs. Five to ten roles cover most organisations under a hundred people. A role per person defeats the point.
• A safe default. Everyone starts as a plain employee who sees their own records, and is given more only when their job needs it.
• Admin is rare. Two or three people, not every manager. Only an admin should be able to make another admin.
• Access is part of joining and leaving. Roles change when a job changes, and go when the person does.
• Hidden, not just blocked. People should not see buttons they cannot use; it saves support questions and stops people discovering what they could ask for.

Roles and permissions in Orbiz

In Orbiz, an organisation admin manages roles in Settings → Roles & Permissions on the web. Permissions are listed tool by tool, in tabs, and only for the tools your organisation uses, so a clinic that runs HRMS and AMS is not shown project-management settings it does not have. Each permission is one action on one page: viewing the team timesheet, approving leave, managing users. You can tick a whole group or a single action.

• Built-in roles such as Admin, HR Manager, Hiring Manager, Interviewer and Employee are ready on day one. You can change which permissions they carry, but not delete them.
• Custom roles have a name, a description, the permissions you tick and a hierarchy level, which decides where the role sits for who can manage whom. A “Ward Manager” role is a custom role.
• More than one role per person. A member can hold several roles at once, so a nurse who also interviews candidates holds Employee and Interviewer rather than a one-off hybrid. Everyone who is not an admin keeps the Employee role.
• Admin stays with admins. Only an admin can give or remove an admin role, and people without one are never even offered it.
• Invites start simple. A new person is invited as an Admin or an Employee; other roles are added once they have joined.

What a person cannot do is hidden: a page their role does not include disappears from the sidebar. If they follow an old link, Orbiz says they do not have permission to view it and to ask an admin, rather than showing an empty page that looks like missing data.

Who approves whom comes from the reporting line

One distinction is worth understanding before you set up a ward manager. In Orbiz, permissions apply across the whole organisation: there is no setting that limits a role to one department or location. What keeps a ward manager to her own ward is the reporting line. A leave request goes to the requester’s reporting manager, then to the department head, and probation reviews follow the same line, so she decides for the people who report to her. If nobody is set, AMS says so on the request and asks for a reporting manager to be set in HRMS. For a worked example, see approving leave requests with an AI assistant.

So the setup for Monday is: give her a Ward Manager role with the approval and team-attendance permissions, and make her the reporting manager of her nurses in HRMS. The first decides what she can do; the second decides for whom.

A checklist for setting up roles

1. List the jobs, not the people: employee, team lead, HR, finance, admin, plus any job your sector has, such as ward manager or head of department.
2. For each job, write down the five or six things it needs to do. Those are its permissions.
3. Start everyone as an employee and add roles from the list.
4. Keep admins to two or three people and review that list every quarter.
5. Set reporting managers for everyone, so approvals reach the right person.
6. When someone changes job, change their roles the same day. When they leave, deactivate them.
7. Once a year, open each role and ask whether every permission is still needed.

If your team uses an AI assistant, the same roles carry over: an assistant connected to Orbiz acts as the person, with exactly their permissions. More on that in what AI assistants should never see in your company. For how Orbiz suits clinics and care providers, see Orbiz for healthcare.

Sources, checked 2026-10-13: NIST Computer Security Resource Center glossary entries for “role-based access control” (NIST SP 800-95, NIST SP 800-53 Rev. 5) and “least privilege”, and the NIST Role Based Access Control project page (csrc.nist.gov). Orbiz behaviour is described from the Orbiz web app.