Role-based access is a way of controlling who can see and change data by assigning permissions to job roles instead of to individual people. An agency creates a role such as agent, manager or administrator, sets what each role can do, and places each user in the role that fits the job. For an insurance agency, this decides who can view client records, export lead lists, edit pipelines or change billing settings.
This guide covers the model, a sample role setup for an agency or IMO, the rules for assigning and reviewing roles, and the limits of the approach.
TL;DR
- Role-based access control (RBAC) attaches permissions to roles. Users get permissions only by holding a role.
- Roles stay stable while staff change, so access is easier to assign, review and remove.
- A typical insurance setup has an administrator, a manager, a licensed agent, an assistant and a read-only role.
- Least privilege and separation of duties are the two design rules that matter most.
- RBAC is less flexible than attribute-based access control when decisions depend on context such as location or device.
Table of Contents
- What role-based access means
- Roles, users and permissions in an insurance CRM
- Example role setup for an agency or IMO
- Design rules: least privilege and separation of duties
- Assigning, reviewing and removing access
- Benefits and limits of RBAC
- Our perspective on roles in an insurance CRM
- Setting up a team in CallBack
- Role checklist before you add users
- FAQ
- Sources
What role-based access means
The U.S. National Institute of Standards and Technology (NIST) defines RBAC as a model where permitted actions are tied to roles rather than to individual identities. Roles typically reflect organizational functions, and permissions can be inherited through a hierarchy.
Three parts make up the model:
- Users: the people who sign in.
- Roles: named job functions, such as “agent” or “office manager”.
- Permissions: the actions allowed on data or features, such as view, create, edit, delete, export.
NIST states that a role is essentially a collection of permissions. Users receive permissions through the roles assigned to them, not through direct links between a person and a permission. Administration then comes down to two tasks: define what each job needs to do, and assign people to the right role.
The three basic rules
IBM summarizes the NIST core model in three rules: a user needs an assigned and authorized role, and receives permissions only through that role. Under NIST’s description, the requested action must also be authorized through the user’s active role and any constraints that apply. If any of the three checks fails, access is denied.
Why roles are the stable layer
NIST’s central administrative point is that roles stay relatively stable while users and permissions change more often. An agency hires, loses and reassigns people all the time. The “licensed agent” job changes far less. When access is routed through the role, onboarding is one assignment and offboarding is one removal. The same goes for reviews: a manager checks a short list of roles and their members instead of hundreds of individual settings.
The original Ferraiolo and Kuhn paper hosted by NIST describes the same idea: access decisions follow organizational functions, and administrators grant or revoke role membership as people join, change jobs or leave.
Roles, users and permissions in an insurance CRM
Insurance software documentation shows how this looks in practice. Oracle’s documentation for its health insurance product describes a user as an account representing a person who accesses the system through roles. Roles hold the access restrictions, including permissions for functions and for data. When a user holds several roles, the access adds up.
That cumulative rule has a practical consequence. Giving a person a second role never removes access from the first. An agent who is also given a manager role gains the manager’s rights and keeps the agent’s. Agencies should check the combined result, not each role alone.
The same Oracle documentation explains that restrictions cover two things: which functions a user may open, and which data those functions may touch, including read, create, update and delete rights. Data is protected by default by controlling the functions that create, read, update and delete it.
A CRM used for insurance sales has the same layers. A function might be “export contacts” or “edit a pipeline”. A data scope might be “my own leads”, “my team’s leads” or “all leads in the agency”.
Example role setup for an agency or IMO
The table below is a design example, not a description of any product’s built-in roles. It shows how an agency with a mix of licensed agents, support staff and owners might divide access.
| Role | Typical data scope | Typical permissions | Typically withheld |
|---|---|---|---|
| Administrator | Whole account | Manage users and roles, billing, integrations, all records | Nothing, but limit to one or two people |
| Agency manager | Own team | View team pipelines and reports, reassign leads, edit workflows | Billing, user deletion |
| Licensed agent | Own leads and clients | Create and edit contacts, send messages, update pipeline stages, log calls | Bulk export, other agents’ records |
| Sales assistant | Assigned agents’ leads | Schedule, send approved templates, update contact details | Policy and proposal approval, deletion |
| Marketing user | Campaigns and contact lists | Build funnels, emails and text campaigns | Individual client files, billing |
| Read-only or auditor | Selected reports | View dashboards and activity history | Any edit |
Where agencies usually draw lines
A few decisions come up in nearly every insurance office:
- Bulk export. A lead list is the most valuable asset in the system. Few roles need to download it in full.
- Deletion. Deleting records can destroy a compliance trail. Reserve it for administrators or managers.
- Lead ownership. Agents work their own leads. Managers see the team. This keeps competing agents out of each other’s pipelines.
- Outbound messaging. Marketing staff may build campaigns while only licensed agents discuss products with prospects.
- Billing and integrations. These belong to the account owner. A wrong change can stop messaging or phone numbers for the whole agency.
Medicare sales add another consideration, since marketing and call records may need to be retained and produced on request. The article on CRM steps for CMS Medicare marketing compliance covers that side. Roles decide who can alter those records.
Agencies with many offices or downlines
IMOs and larger agencies add a layer: several teams, each with its own manager, under one owner. The common pattern is a role per function and a data scope per team. The owner sees everything. Each team manager sees only their team. Agents see only their own work. Separate roles per team are usually easier to maintain than special exceptions for individuals. The same logic applies to marketing automation at an IMO, where several agents share workflows but not client files.
Design rules: least privilege and separation of duties
Two principles turn a role list into a sound control.
Least privilege. A cybersecurity implementation guide published by Puerto Rico’s insurance regulator advises a policy that restricts access and privileges to the minimum each employee needs to perform their duties, with least privilege and separation of duties built in. The document is local to Puerto Rico, but the principle is general. Start every role with nothing and add what the job requires.
Separation of duties. NIST’s role engineering guidance names this as a common RBAC constraint. Its example: a system can prohibit one user from holding roles that permit both initiating and approving a large purchase. In an agency, the equivalent is that the person who changes commission or payout details should not be the person who approves them, or that the person who builds a text campaign is not the only one who can send it to the full database.
Unique accounts, no sharing
The FFIEC IT Examination Handbook, written for financial institutions, lists prudent practices for privileged access: assign privileges to a unique user ID, prohibit shared privileged accounts, and require independent monitoring. Agencies are not all bound by that handbook, but the practice applies everywhere. A shared login called “office” makes it impossible to say who changed a record. Every person gets their own seat and their own role.
Assigning, reviewing and removing access
Roles only help if the assignments stay accurate. The FFIEC handbook describes logical access administration as enrolling new users, authorizing changes or removals, and monitoring access rights through periodic review and validation.
A workable routine for a small or mid-size agency:
- Write the role list first. Name each job and what it needs. Keep it short.
- Assign on the first day. A new hire gets one role matching the job title, nothing extra.
- Record exceptions. If someone needs a permission outside their role, note why and who approved it.
- Review on a schedule. Quarterly works for most offices. Check each role’s members and each role’s permissions.
- Remove access the day someone leaves. Disable the account, then reassign their leads. This includes mobile access, covered in the piece on mobile CRM access for insurance agents.
- Train the people in sensitive roles. The Puerto Rico guide notes that people in specialized roles should have the knowledge and skills to do their tasks with security risks in mind.
Why automation helps at scale
NIST’s National Cybersecurity Center of Excellence argues that fragmented access rights, often caused by system complexity and acquisitions, raise security risk when updates are not automated and synchronized. For an agency this means: the more tools in use, the more places a departing employee’s access can survive. Keeping lead data, messaging and calendars in one platform with one set of roles reduces that risk. The cloud security guide for CRM covers the hosting side of the same question.
Benefits and limits of RBAC
Benefits. RBAC simplifies user management and strengthens security by grouping permissions into roles. NIST adds that it can simplify administration because roles mirror organizational structure, and that complex role hierarchies and mutually exclusive roles are handled by the RBAC software. Reviews are faster, onboarding is consistent, and an auditor can read the role list.
Limits.
- Roles can multiply. If every exception becomes a new role, the model becomes as hard to manage as individual permissions.
- Permissions accumulate. Staff who change jobs keep old roles unless someone removes them.
- Roles are static. They say who the person is, not where they are, what device they use or what time it is.
RBAC compared with groups and ACLs
A common question is how RBAC differs from access control lists and ordinary groups. NIST explains that groups generally collect users and permissions may be linked to users or groups. In RBAC, permissions connect only to roles, and users receive them through role membership. RBAC can also activate only a subset of a user’s assigned roles in a session. An access control list attaches permissions to each resource, one record or file at a time, which is harder to audit across a large database.
When attribute-based access fits better
NIST SP 800-162 defines attribute-based access control (ABAC) as a method where authorization is decided by evaluating attributes of the subject, the object, requested operations and the environment. Attributes can include location, time of day, device or data sensitivity. ABAC fits when a rule depends on context, for example allowing access to client files only from a managed device. RBAC fits when the question is simply what a person’s job allows.
For most agencies, RBAC is the right starting point. It matches how offices are organized and is easy to explain to staff.
Roles in modern software
In API-driven systems, roles or permissions can travel as claims in a token. Backend APIs validate those claims before granting access. Agency owners do not manage this directly, but it is why a role change in a cloud CRM takes effect across the web app, the mobile app and connected tools.
Our perspective on roles in an insurance CRM
We build CallBack for insurance agents, agencies and IMOs, and access control is one of the first things an agency owner asks about once a second person joins the account. Our view is simple.
A CRM holds the most sensitive data in an agency: names, phone numbers, health details and coverage needs. Few people in the office need all of it. The role should match the job, and the default should be less access, not more.
We also see agencies grow in steps: one agent, then an assistant, then a team, then several teams. Roles set up early, even for a two-person office, save rework later. Our Enterprise plans are sized by the number of full CRM accounts, so each person on a team has a seat, a login and a place in the role structure.
We recommend a short role list, one owner or two administrators, own-leads access for agents and a quarterly review of who has what. Our platform is hosted on Google Cloud, and the same principle holds for any CRM: strong hosting does not replace correct permissions.
— Kyle
Setting up a team in CallBack
CallBack is a CRM and sales automation platform built for insurance agents, agencies and IMOs. It covers pipeline management, automated follow-up by text, email and voicemail, funnel and website builders, and reporting. The Professional plan costs $97 per month. Enterprise plans cost $297 per month for 10 full CRM accounts, $397 per month for 25 and $497 per month for 60. Phone numbers cost $2.30 per month per number, and other usage fees are listed on the fees page.
Agencies that need seats for a full team can review the Enterprise plans. A single agent can start with the Professional plan. The features page lists everything included.
Role checklist before you add users
- List every job in the office and what each needs to see.
- Give each person a unique login.
- Limit bulk export and deletion to one or two roles.
- Scope agents to their own leads.
- Write down every exception and its approver.
- Review members of every role each quarter.
- Remove departed staff the same day, including on phones.
FAQ
What is the difference between RBAC and ABAC?
RBAC grants access based on a person’s role. ABAC decides access by evaluating attributes such as user, resource, action and environment. RBAC is simpler to run and review. ABAC handles context-dependent rules better.
How many roles should an insurance agency have?
Most agencies work well with five to seven roles: administrator, manager, agent, assistant, marketing and read-only. If new roles are created for every exception, the model loses its benefit. Add a role only when several people share the same need.
Do users get permissions directly or through roles?
In RBAC, permissions come through roles. NIST describes users receiving permissions through assigned or inherited roles, not through direct user-to-permission links. Where a person holds several roles, the access combines.
How often should user access be reviewed?
The FFIEC handbook calls for periodic review and validation of access rights but does not set one interval for every organization. A quarterly review is a common choice for small agencies. Also review whenever someone changes jobs or leaves.
Sources
- role-based access control (RBAC) - Glossary, NIST CSRC
- Role Based Access Control FAQs, NIST CSRC
- Role Based Access Control, NIST CSRC
- Role-Based Access Controls, Ferraiolo and Kuhn
- What Is Role-Based Access Control (RBAC)? IBM
- User Access Restriction Model, Oracle Health Insurance
- Implementation Guide for Cybersecurity Controls, Puerto Rico
- Role Engineering: Methods and Standards, NIST
- FFIEC IT Examination Handbook: Logical Security
- Access Rights Management for the Financial Services Sector, NIST NCCoE
- Guide to Attribute Based Access Control, NIST SP 800-162
- What is Role Based Access Control (RBAC)? Auth0