The basic idea
Imagine setting permissions for a company of two hundred people by picking from a long list of options for each person. It would take a long time, produce inconsistent results, and be nearly impossible to check. Role-based access control, usually shortened to RBAC, is the usual alternative. Instead of attaching permissions to individuals, you attach them to roles that reflect jobs, and then assign people to roles.
There are only three moving parts:
- Users: the people or accounts.
- Roles: named bundles of permissions, such as “Accounts Payable Clerk” or “Support Agent.”
- Permissions: specific actions on specific resources, such as “view invoices” or “reset user passwords.”
A person is placed in a role and receives its permissions. Change the role’s permissions and everyone in it is updated. Move the person to a different role and their access changes accordingly.
An everyday picture
Think of a restaurant. A server can take orders and use the till, the chef can access the kitchen and stock room, and the manager can do both and also view sales reports. Nobody decides, for each new server, which doors to open. They are simply a server, and servers have a standard set of access. If the restaurant adds a table-ordering tablet that servers should use, it is configured once for the role.
Why organizations like it
Consistency. Two people doing the same job get the same access, which avoids one person quietly having more than their colleague.
Speed for joiners and movers. Setting up a new starter becomes “assign them the role” rather than a long list of individual requests. During account onboarding, this shortens setup and reduces errors.
Easier reviews. Checking whether a role is appropriate is one decision that applies to many people. Reviewers can then look at a smaller number of exceptions.
Support for least privilege. When roles are defined carefully, people receive what their work requires and little else.
Clearer explanations. “She can see payroll because she is in the payroll role” is easier to defend than a collection of individual grants.
Designing roles sensibly
Good roles do not appear by accident. A few practical steps help.
- Start from the work. List the main job functions and what each genuinely needs to do. Interview managers and people doing the job rather than copying what existing users happen to have.
- Keep roles understandable. A name should tell a reader roughly what it permits. Vague names like “Level 2” invite confusion.
- Build from small to large. Some designs use a handful of basic roles (such as reader, editor, administrator) combined with department groups. Others use more specific job roles. Pick a pattern and stay consistent.
- Separate sensitive actions. Where a task carries risk, such as approving payments, avoid putting both the ability to create and to approve in the same role. This idea, often called separation of duties, reduces the chance of error or misuse by a single person.
- Assign an owner. Each role needs someone who decides what belongs in it and approves changes.
- Write it down. Describe each role’s purpose and contents in a place staff can find, ideally referred to in the IT policies.
Classifying the information involved helps. Roles that touch confidential records often need tighter rules than ones that touch general material, which is where data classification can inform the design.
Common pitfalls
Role sprawl. Over time, every special case becomes a new role. Soon there are hundreds, many nearly identical, and the benefits of simplicity are lost. Periodically merge roles that overlap and retire unused ones.
The “everything” role. Teams sometimes create a broad role to avoid access requests. It is convenient and also defeats the aim of limiting access.
Role creep for individuals. If people keep holding several roles from past jobs, the model is not being applied during job changes. Mover steps need to remove old roles.
Ignoring exceptions. Real organizations have unusual cases. Rather than creating a one-person role every time, set up a documented exception process with an approver and an expiry date.
Treating roles as permanent. Jobs evolve. A role defined three years ago may include permissions for systems that were retired or tasks that moved elsewhere.
Roles are not the only model
RBAC is popular but not universal. Some systems also make decisions using attributes, such as department, location, device or time of day. Others let the owner of a file decide who may open it. Many real environments combine approaches: roles for the broad strokes and finer rules for sensitive areas. For small organizations, simple roles or groups often cover most needs without extra complexity.
Roles also fit alongside other measures. Signing in must still be verified, with authentication methods suited to the risk, and regular access reviews should confirm that role membership is still correct. Cloud platforms generally support roles, but the details vary, and the shared responsibility model means customers are usually responsible for assigning them sensibly.
A modest way to begin
For a small team, start with three or four roles that match how people actually work, such as general staff, team leads, finance and IT administrators. Assign every person to one, list what each role may do, and review the arrangement after a few months. Add roles only when a clear need appears. A short, well-understood set of roles is usually more useful than an elaborate one that nobody can keep up to date.