Say an IT admin on an evaluation call asks, "Do you have RBAC?" and then, before you've finished answering, "Could we give our contractors read-only access?" The first question is the acronym. The second is what they actually need to know.

NIST defines role-based access control as a model in which permitted actions on resources are tied to roles rather than to individual people (NIST glossary). It isn't new. RBAC was adopted as an ANSI/INCITS standard in 2004 and revised as INCITS 359-2012 (NIST RBAC project), and enterprise buyers commonly expect a SaaS product to support it in some form.

For a sales rep, RBAC matters less as a definition than as a set of follow-up questions. Besides contractor access, admins tend to ask whether a team lead can see their own team's data but not finance's, and who can change those settings.

How it shows up in a SaaS product

In most admin screens, RBAC is a short list of roles, each bundling a set of permissions. In a hypothetical product, an Owner can manage billing and delete the workspace, an Admin can invite users and change settings, a Member can create and edit records, and a Viewer can only read. A user gets a role, and the role decides what they can do.

Before a call, open your product's admin screen and write down the roles that actually exist, along with what each can and can't do. Buyers ask surprisingly specific versions of the question, such as "can a viewer export data?", and that screen answers them more reliably than any feature page. VoiceVocab's cloud and security course has you practise answering these questions out loud.

Then check two things that change the conversation. Can customers create custom roles, or only use the built-in ones? And is that ability on every plan? Custom roles are often on a higher tier, and a buyer who assumed they were included will find out in the order form. Say where they sit when RBAC first comes up.

The principle behind the questions

Security teams think in terms of least privilege, which NIST describes as restricting users' access privileges to the minimum necessary to accomplish assigned tasks (NIST glossary: least privilege). Roles are how they apply it. The more granular your roles, the closer they can get, so a reviewer who sees only "Admin" and "User" will ask how they're meant to stop most staff from having admin rights.

That's also why the question tends to arrive with two others attached. Admins want role assignments to follow their identity provider, so that when someone moves team, their access changes without a manual step. Ask whether your product can map IdP groups to roles automatically, because that's often the deciding detail for a large rollout. And reviewers want an audit trail of who changed whose role and when. If your product logs permission changes, know where the admin finds that log.

Your own staff count too

Sooner or later a reviewer turns the question around: which of your employees can see our data? That's RBAC on the vendor side. Support engineers may need temporary access to a customer's workspace to debug a problem, and buyers want to know whether that access is limited by role, whether the customer has to grant it, and whether it's logged. Some products handle this with a support-access setting the customer switches on for a limited time. Find out whether yours does, and what your security documentation says about internal access, because this question usually appears in writing in the security questionnaire and your spoken answer will be compared with it.

When roles aren't enough

Some buyers need access decided by more than a role, such as only seeing records for their own region, or only during a project. That's closer to attribute-based access control (ABAC), which NIST describes as deciding access by evaluating attributes of the user, the resource, the requested action and sometimes the environment against policy (NIST SP 800-162).

You don't need to sell ABAC, and many products don't offer it. What you need is to recognise the request when you hear "can we restrict it so the EMEA team only sees EMEA accounts?" That's a question about record-level or attribute-based rules, and the honest answer might be a feature, a workaround with separate workspaces, or a no. Once the buyer is describing policies in that much detail, it's time to bring your sales engineer in.

In the demo

When access control matters to the buyer, don't only show the roles list as an admin. Log in as a restricted user, ideally a Viewer, and try to export data in front of them so they can watch the export button stay greyed out. A security reviewer watching that will usually ask two things next: whether the same restriction holds through the API, and whether the attempt shows up in the audit log.