Before Enabling Attribute-Based Access Control (ABAC) for Your Tenant

Important:

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

Attribute-Based Access Control (ABAC) is enabled at the tenant level, not at the individual solution level. Unlike many OneTrust features that can be configured separately within a specific product area, ABAC operates as a shared access model across your OneTrust environment. When ABAC is enabled, it applies to all supported objects within the tenant, regardless of which OneTrust solution uses those objects.

Key Differences with ABAC

ABAC is designed around objects rather than individual solutions. Since many objects are used across multiple OneTrust products, ABAC must be implemented as a tenant-wide capability.

Key differences include:

  • All supported objects, regardless of which solution uses them, will use ABAC assignments to determine access along with a user's role(s).

  • The same access model applies across all supported solutions within the tenant.

  • When an object is used by multiple solutions, the same ABAC assignments and permissions apply regardless of where the object is accessed, helping create a consistent security model across the platform.

Because of this architecture, enabling ABAC on a solution-by-solution basis is not supported and cannot be accommodated.

What does this mean?

A tenant-wide approach enables more consistent, scalable, and centralized access control across OneTrust. However, it also means ABAC should be considered a shared change that may affect multiple teams and business processes.

Customers should expect the following:

  • Customers using multiple OneTrust solutions within the same tenant should plan for ABAC as a shared change that may affect multiple teams and business processes.

  • Teams should align on access requirements across different workflows and user types.

  • Users should understand that access behavior may change across supported solutions once ABAC is enabled.

Treating ABAC as a shared platform capability helps ensure access policies remain aligned as users move between workflows and solutions.

Tip:

ABAC Pre-Implementation Workbook

The most successful implementations start with cross-functional planning, clear access requirements, and a shared understanding of least-privileged access before rollout. Organizations should use the ABAC Pre-Implementation Workbook to guide collaborative planning exercises that help teams define ownership models, access requirements, and assignments that may impact multiple business functions. Organizations that align early on access expectations are better positioned for a smoother rollout and long-term scalability.

For more information, see Implementation Playbooks: Attribute-Based Access Control (ABAC).

OneTrust's Recommendations

Before enabling ABAC, OneTrust recommends defining a common access strategy across the teams and solutions that share your tenant.

Consider the following planning activities:

Planning Area

Questions to Consider

User Responsibilities

What tasks do different users need to complete?

Access Requirements

What level of access should each user have?

Cross-Solution Workflows

Where do teams share data, workflows, or responsibilities across solutions?

User Experience

How can access controls be implemented consistently across the tenant once ABAC is enabled?

As you define your ABAC model, keep the principle of least-privileged access at the center of your planning. Users should be granted only the access required to perform their responsibilities, helping improve security, governance, and operational consistency across the platform.

Continue Your ABAC Journey