Role-based access control (RBAC) gives people access based on their job role instead of granting permissions one person at a time. For HR and sales data, that means sales reps see their own pipeline, managers see their team's, HR sees employee and pay records, and leadership sees summaries. Following least privilege, everyone gets only the access their work requires.
What is role-based access control, in one paragraph?
In RBAC, you define roles such as "Sales rep", "HR executive" or "Finance", attach permissions to each role, and then assign people to roles. When someone joins, changes jobs or leaves, you change their role, not dozens of individual settings. The model was formalised by researchers at the US National Institute of Standards and Technology (NIST) in the 1990s and is now the default way most business software handles permissions.
The benefit is consistency. Two people with the same job see the same data, access is easy to explain to an auditor, and a review means checking a handful of roles rather than every user. The risk is "role creep": roles slowly collect extra permissions until the sales role can see things only HR should.
How does RBAC compare with ABAC and individual permissions?
There are three common ways to manage access. Most companies use RBAC as the base and add a few attribute-based rules where needed.
| Individual permissions | Role-based (RBAC) | Attribute-based (ABAC) | |
|---|---|---|---|
| How access is decided | Set per person | By the role a person holds | By rules on attributes of the user, the record and the context |
| Example rule | "Give this one person access to the salary report" | "HR executives can view employee profiles" | "Managers can view leave records of employees whose manager field is them" |
| Strengths | Fast for a 5-person team | Consistent, easy to audit and review | Very precise; handles regions, teams and ownership well |
| Weaknesses | Becomes unmanageable and impossible to review as you grow | Too many roles if you try to cover every edge case | Harder to design, test and explain |
| Best for | Very small teams, temporary exceptions | Most growing companies | Large or regulated organisations, multi-entity setups |
In practice, "see your own deals" and "see your team's records" are simple attribute rules (record owner and reporting line) layered on top of roles. Good business software lets you combine both without writing code.
What does a sample role matrix for HR, sales and operations look like?
A role matrix is a table of roles against data areas, with the access level in each cell. Write yours before you configure any software; it turns a vague conversation about "who should see what" into decisions you can review. Here is a starting point for a growing company:
| Role | Deals and pipeline | Contacts and accounts | Employee profiles | Salary and bank details | Leave and attendance | Projects and vendors |
|---|---|---|---|---|---|---|
| Employee (self-service) | None | None | Own: view, edit some fields | Own: view | Own: view, apply | Assigned tasks |
| Sales rep | Own: edit | Own and shared: edit | Directory only | None | Own only | View linked projects |
| Sales manager | Team: edit | Team: edit | Directory only | None by default | Team: approve | View linked projects |
| HR executive | None | None | All: edit | View, no export | All: edit | None |
| Payroll or finance | View closed deals | View | View | All: edit | All: view | Vendors: edit |
| Operations or project manager | View closed-won | View | Directory only | None | Team: approve | All: edit |
| Leadership | All: view | All: view | All: view | Summaries only | Summaries | All: view |
| System admin | Configure only | Configure only | Configure only | None unless separately granted | Configure only | Configure only |
Two choices in this matrix are worth calling out. Leadership sees salary summaries, not individual pay, unless there is a reason to see more. And the system admin can manage settings without automatically seeing payroll. Separating "can configure the system" from "can read sensitive data" is one of the most useful controls you can put in place.
How do field-level permissions protect salary and personal data?
Role-based access usually works at the level of records: you can or can't see an employee profile. Field-level permissions go one step further and control individual fields on that record. This matters because one employee profile mixes harmless data with very sensitive data.
Fields that usually need their own rules:
- Compensation: salary, CTC breakdown, bonus, increments and pay history.
- Financial and identity data: bank account number, PAN, Aadhaar, passport number.
- Personal data: date of birth, home address, emergency contacts, personal phone number.
- Health and leave reasons: medical certificates, notes on sick or special leave.
- Performance and disciplinary notes: review comments, warnings, investigation records.
- Commercial data in sales: discounts, margins and commission rates.
For each field, decide three separate rights: who can view it, who can edit it and who can export it. Export is often the one people forget. A manager who can view a team's phone numbers on screen doesn't necessarily need to download the whole list into a spreadsheet. Audit logs are the safety net: they record who viewed, changed or exported sensitive fields, so you can investigate when something goes wrong.
Kiko supports both role-based and field-level permissions, with audit logs alongside them. The guide to roles and permissions in Kiko walks through the setup.
How should you review access every quarter?
Access drifts. People change teams, cover for colleagues, get temporary admin rights for a project and keep them. A short quarterly review catches this before it becomes a problem, and it is one of the controls auditors look for in frameworks such as SOC 2 (see our explainer on what SOC 2 Type II means).
- Export the user list with roles. Include last login date and any individual permissions granted outside roles.
- Remove leavers. Compare the list with HR's exit records. Any active account for someone who has left is a finding to fix the same day.
- Check movers. Anyone who changed team or job in the quarter should have the new role only, not old and new combined.
- Review admins. List every user with admin or "all records" access. Each one needs a current reason.
- Review sensitive fields. Confirm who can view and export salary, bank and identity fields. The list should be short.
- Remove dormant accounts. Accounts with no login in 90 days are candidates for deactivation.
- Check role definitions. Compare each role's permissions with your role matrix and remove anything added "temporarily".
- Record the review. Note who reviewed, the date, what was changed and who approved. That record is your evidence.
How do SSO and SCIM automate access on joining and exit?
Manual access management fails at the edges: the new hire who waits three days for logins, and the leaver who can still open the CRM a month later. Two standards fix most of this.
Single sign-on (SSO) lets people log in to business apps with one company account from an identity provider such as Google Workspace, Microsoft Entra ID or Okta. SAML 2.0 is the most common standard for this. When you disable someone's company account, they lose access to every app connected through SSO at once.
SCIM (System for Cross-domain Identity Management) goes further. It is an open standard that lets your identity provider create, update and deactivate user accounts in connected apps automatically. With SCIM, the full lifecycle is handled:
- Joiner: HR adds the employee, the identity provider creates their account and the app assigns a role based on their group.
- Mover: a department change updates their group, and the app updates their role.
- Leaver: deactivating the employee removes their access everywhere, without anyone remembering to log in to each tool.
Kiko supports SSO through SAML 2.0 and SCIM provisioning; see how to set up SSO in Kiko.
Frequently asked questions
What is the principle of least privilege?
Least privilege means each person gets the minimum access needed to do their job, and nothing more. It limits the damage from mistakes, compromised accounts and insider misuse. In practice, start roles with minimal access and add permissions when there is a clear need, rather than starting broad and trimming.
How often should access be reviewed?
Quarterly is a common standard for systems holding sensitive data such as payroll and customer records, and many security frameworks expect periodic reviews. Leavers should be removed immediately, not at the next review. Lower-risk systems can be reviewed less often, but at least twice a year is a sensible minimum.
What is SCIM provisioning?
SCIM is an open standard for automatically creating, updating and removing user accounts across applications. Your identity provider becomes the source of truth, and connected apps follow it. It removes manual steps on joining and exit, which is where most access mistakes happen.
Should managers see their team's salaries?
It depends on your pay policy, and there is no single right answer. Many companies let managers see pay bands or compare salaries against a range during review cycles, while exact salaries, bank details and identity data stay with HR and payroll. Whatever you choose, write it into your role matrix and set it with field-level permissions so it is applied consistently.
See role and field-level permissions in action
A role matrix only helps if your software can enforce it. Book a demo to see Kiko's role and field-level permissions, or read more about our controls on the Kiko security page.
