How to start with RBAC in SailPoint ISC?

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hi everyone,

We want to start using roles (RBAC) in SailPoint Identity Security Cloud.

Right now, users get access through individual entitlements and access profiles. We want to move to roles so access is easier to manage and review.

Where to start and how to start? Any guidance would be helpful.

I know the SailPoint documentation is available. I am looking for practical examples and best processes from anyone who has already done this.

Thank you!

2

My recommendation is to start with a small pilot and gradually expand RBAC across your environment.

In SailPoint ISC, I would approach it in the following steps:

Review existing access: Identify the access profiles, entitlements, and application access currently assigned to users. Look for common access patterns across users in the same department, job function, or business unit.

Map access profiles to roles: Reuse existing access profiles wherever possible instead of creating everything from scratch. A role can contain multiple access profiles across different applications.

Define role criteria: Configure role assignment criteria based on identity attributes such as department, job title, location, or employee type, where appropriate. Validate the criteria carefully to avoid assigning unnecessary access.

Start with a pilot: Choose one department or business function with clear access requirements. Test role assignment, access provisioning, role changes, and access removal in a controlled environment before expanding.

3

Hello Puppam. I agree with Chaithanya on starting small. Since you already have access profiles, I would suggest reusing them rather than building everything from scratch.

For example, start with a Finance Analyst role:

  1. Compare existing access across Finance Analysts and identify what the job actually needs. Have application owners validate it, keeping privileged and exceptional access separate.
  2. Create a role using those access profiles. Use trusted HR attributes like department and job title for automatic assignment. For additional access, consider requests with approvals.
  3. Test a joiner, mover, and leaver. Verify what actually gets provisioned and revoked before expanding.

If you have Access Modeling, Role Discovery can help identify common access patterns. Just make sure the business owners validate the suggested roles.

A couple of things I would watch:

  • Existing access: Assigning a role does not automatically clean up previous direct grants. Review those separately after validating the new role.
  • Access removal: Removing access from an existing role requires Role Change Propagation to be enabled, along with the role itself, to push removals to current members. If someone stops matching role criteria, their role access is removed unless another assigned role also provides it.

Also, automatically assigned roles cannot be manually revoked, so test your assignment criteria carefully. My suggestion is to get one role working end to end across JML before moving to the next.

4

Hello @puppamReddy,

I would add one consideration: I wouldn’t necessarily make “move the existing access to roles” the objective. The goal should be to identify which access is genuinely role-worthy.

Not every entitlement or access profile needs to become part of an RBAC role. Roles work best when the access represents a stable and repeatable business requirement. SailPoint supports roles as collections of access that can be automatically assigned based on criteria or made requestable.

Before creating roles, I would classify the existing access into three buckets:

  1. Common/birthright access – Access almost everyone in a defined population needs.
  2. Job-function access – Stable access associated with a specific business responsibility. This is usually the strongest RBAC candidate.
  3. Exception/elevated access – Access needed only by some users. I would generally keep this requestable rather than forcing it into a role simply because several users currently have it. ISC supports requestable roles/access profiles with approval controls.

One common challenge with RBAC is role explosion. If you create separate roles for every combination of department, location, job title, application and exception, the role model can eventually become harder to govern than the original entitlement model. I would therefore define the role design standards first: what qualifies as a role, who owns it, what attributes can drive membership, what belongs outside the role, and how role changes will be governed.

If Access Modeling is available, Role Discovery is useful for finding access patterns, but I would treat those patterns as candidates rather than the final role design. SailPoint’s Role Discovery identifies potential roles by analyzing entitlement similarities among identities. So my approach would be: design the RBAC governance model first, identify stable business patterns second, and build roles third. That usually gives you a cleaner and more sustainable role model than simply converting the current access structure into roles.

5

Hi Puppam,

you can refer for some sailpoint links to start with the best access modelling approach.
Design roles around what a job should have, using existing access data as evidence. Role Insights requires a basic role model already containing roles with entitlements assigned to identities.

Access Modeling Best Practices | Knowledge Base | SailPoint Community
Role Based Access Control (RBAC)