Understanding Roles-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)

Important:

The Attribute-Based Access Control (ABAC) Phase 1: Foundations feature is under Public Preview. Please contact OneTrust Support to request early access.

The OneTrust Platform uses both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) to help organizations manage user access. While both models control access, they solve different challenges and are designed to work together. RBAC provides broad access and permissions through roles, while ABAC adds more granular control over which records users can access and what actions they can perform on those records. Understanding how these models work together helps organizations implement a least-privileged access strategy within OneTrust.

Tip:

The recommended model is to assign the Basic role to most users and use ABAC to provide targeted record-level access. Elevated role-based permissions should be reserved for administrative users who require broader privileges. This approach helps organizations reduce role complexity, simplify access management, and implement least-privileged access more consistently across the OneTrust Platform.

What is Role-Based Access Control (RBAC)?

Role-Based Access Control (RBAC) is an authorization model that grants access based on a user's assigned role. Roles provide a standardized way to manage access and permissions within the OneTrust Platform by assigning users to predefined roles that contain a set of permissions. RBAC provides broad access through static permissions that apply consistently across records. Depending on the role assigned, users may receive administrative privileges, broader access to records, or only basic platform access.

RBAC answers the question: What level of access and privileges does this user have within the platform? The following examples illustrate how roles define baseline permissions:

A Site Admin can administer platform settings, manage users, and configure access controls.
An IT Risk Manager can create, review, and manage risk-related records and workflows.
A Privacy Officer can manage privacy program activities, assessments, and related records.
A user assigned the Basic role can access the OneTrust Platform homepage and manage personal preferences without receiving broad access to records.

Benefits of RBAC

RBAC works well for predictable and repeatable access patterns where groups of users require the same permissions and level of access. For example:

Administrators can grant a predefined set of permissions by assigning a user to a role.
New users with similar responsibilities can be onboarded quickly using existing roles.
Organizations can establish consistent security controls across teams and departments.
Permission management becomes easier to maintain as the number of users grows.

While RBAC is effective for managing broad permissions, organizations often need more granular control over which specific records users can access. This is where ABAC complements RBAC.

What is Attribute-Based Access Control (ABAC)?

In ABAC Phase 1: Foundations, Attribute-Based Access Control (ABAC) extends the access model by providing more granular, record-level access control. Rather than granting access to all records within a solution, ABAC uses sharing, attributes, and workflows through assignments to determine which specific records a user can access and what permissions they have on those records.

ABAC answers the question: Which specific records can this user access? The following examples illustrate how access can be limited to specific records:

A user may be able to edit only the records they own.
A user may be able to access only records where they are assigned as an approver.
A reviewer may be able to access only records explicitly shared with them.

Benefits of ABAC

ABAC works well for dynamic access requirements where users need access to specific records based on their responsibilities, participation in workflows, ownership relationships, or collaboration needs. For example:

Users can access only the records relevant to their responsibilities.
Organizations can implement least-privileged access without creating large numbers of specialized roles.
Teams can collaborate on records while limiting access to unrelated data.

As organizations grow, ABAC helps address access scenarios that can be difficult to manage through roles alone.

Understanding the Relationship between RBAC and ABAC

RBAC and ABAC are complementary access-control models that work together to provide both broad platform permissions and granular record-level access. Rather than choosing one model over the other, organizations use RBAC to define what a user is generally allowed to do within the platform and ABAC to determine which specific records those permissions apply to. Together, they support a least-privileged access model that gives users the access they need while limiting access to records that are not relevant to their responsibilities.

Example: RBAC without ABAC

Consider a user assigned the Vendor Manager role. The role grants the permissions needed to work with vendor records, including viewing, creating, updating, and managing vendors. Because access is determined through the role, the user can access vendor records that fall within the scope of their role. However, if the user needs to collaborate on records outside of those responsibilities, additional permissions or roles may be required.

Example: RBAC and ABAC Together

Now consider the same user after ABAC has been enabled. The Vendor Manager role continues to provide access to vendor records and vendor management activities. ABAC can then be used to grant additional access to specific records that support the user's responsibilities outside of vendor management. For example:

The Vendor Manager role provides access to vendor management activities and vendor records.
A sharing assignment grants the user access to a specific engagement record in another organization where they would not otherwise have access through their Vendor Manager role. This allows them to collaborate on that engagement without receiving broader permissions within that organization.
A workflow or user attribute assignment grants the user access to a specific risk record where they are responsible for review or approval.

In this example, RBAC provides access based on the user's role and responsibilities, while ABAC extends access to specific records based on ownership, collaboration, approvals, workflows, and sharing relationships.

Together, RBAC and ABAC enable organizations to provide users with the broad permissions required for their role while granting targeted access to individual records when participation in related business processes is required. This reduces the need to create additional roles, supports collaboration across teams, and helps organizations implement least-privileged access more effectively.

OneTrust's Recommendations

OneTrust recommends implementing ABAC using a least-privileged access model. Most users should receive access through the Basic role combined with ABAC assignments, while elevated roles should be reserved for administrators and program managers who require broader access and administrative privileges.

When implementing ABAC:

Assign the Basic role to viewers, collaborators, reviewers, approvers, and other users who primarily need access to specific records. Provide record-level access through ABAC assignments instead of granting broad access through additional roles. Reserve elevated role-based access for administrators and program administrators who need to configure, manage, or administer a solution.
Use assignments, user attributes, and workflow stages to grant access based on ownership, review, approval, and collaboration responsibilities.
Review existing custom roles and replace them where possible with the Basic role and ABAC assignments to reduce role proliferation and simplify long-term access management.
Define access requirements by user persona before enabling ABAC and align assignments and attributes to real workflow responsibilities.
Regularly review access models to ensure users retain only the records and permissions needed to perform their responsibilities.

Settings & Administration