Attribute-Based Access Control (ABAC) FAQ

Attribute-Based Access Control (ABAC) is an access-control model that brings record-level access management to the OneTrust Platform. ABAC uses assignments and attributes to determine which records a user can access and what permissions they have on those records, helping organizations implement least-privileged access. ABAC Phase 1: Foundations is available in Public Preview as part of the OneTrust 202608.1.0 Summer Seasonal Release (August 2026), with additional capabilities and object support introduced over time.

For more information, see Attribute-Based Access Control (ABAC) Overview.

Role-Based Access Control (RBAC) grants access based on a user's role, while Attribute-Based Access Control (ABAC) adds more granular, record-level access control through assignments with sharing, attributes, or workflows. ABAC and RBAC work together, with roles providing baseline access and ABAC helping determine access to specific records.

For more information, see Understanding Role-Based Access Control (RBAC) Attribute-Based Access Control (ABAC).

No. Roles continue to define baseline access. ABAC adds record-level access control alongside roles. Together, they help organizations achieve least-privileged access.

ABAC Phase 1: Foundations focuses on foundational capabilities required to manage more granular, record-level access through record ownership, assignments, attributes, workflow participation, or explicit sharing. ABAC Phase 2: Dynamic Access introduces additional capabilities such as automated rules, field-level access control, and bulk sharing. ABAC Phase 1: Foundations is available in Public Preview as part of the Summer Seasonal Release (August 2026). ABAC Phase 2: Dynamic Access is planned to become available in a preview state later in 2026.

For more information, see Attribute-Based Access Control (ABAC) Overview.

ABAC is optional and can be enabled based on your organization's access-control requirements. Many larger organizations and those with stricter security, privacy, governance, or compliance requirements adopt ABAC to provide more granular control over who can access specific records and data. Work with your organization's security, governance, and compliance teams to determine whether ABAC aligns with your access-control requirements.

No additional packaging is required. ABAC Phase 1: Foundations is available to all our customers during Public Preview and is planned to remain available to all customers at General Availability (GA). That means customers on both legacy (i.e. module-based subscriptions) and new solution packages can enable and use this capability.

No. ABAC is enabled at the tenant level and applies to all supported solutions within the tenant. It cannot be enabled for individual solutions.

For more information, see Before Enabling Attribute-Based Access Control (ABAC) in Your Tenant.

During Public Preview, contact OneTrust Support to request enablement for your tenant. ABAC is not enabled automatically during Public Preview. Once the feature reaches General Availability, it is planned to become available automatically.

Yes. Enablement can be requested for a non-production environment first, and OneTrust recommends validating the configuration in UAT before enabling ABAC in Production. ABAC remains tenant-level within each enabled environment and cannot be enabled for only one solution within that environment.

If ABAC was enabled only in the Sandbox and the Sandbox is refreshed, request enablement again after the refresh. If ABAC is enabled in Production, a Sandbox refresh does not require a new Production enablement request.

Impersonation is not currently available for ABAC testing in non-production environments but is part of our 2027 roadmap.

An assignment is an administrator-configured permission set for a record. It defines what assigned or shared users can do, such as viewing, editing, deleting, or managing sharing for that record.

An element within the OneTrust Platform, such as risks, assessments, contracts, processing activities, vendors, or AI systems.

An individual instance of an object within the OneTrust Platform. For example, a specific risk, assessment, contract, processing activity, vendor, or AI system is a record.

No. Access does not automatically cascade across related records. A user may see a related tab, such as Risks or Contracts, when their assignment includes permission to view that related content, but access to each related record is evaluated separately using the applicable RBAC and ABAC permissions. Without access to a specific related record, the user cannot open its details and may be prompted to request access or see an access-denied page.

Yes. If a user does not have access to a record, they can request access from the record administrator shown on the record details page. A user may encounter the record through a direct URL or a related-record list. Requesting access is not a separate role capability; if the user encounters a record they are not authorized to access, they can request access.

Site Administrators can grant access. To route future requests correctly, reassign the record administrator for the affected record to an active user who can manage access requests.

Access is evaluated as a union. If a user receives access through either their role or an assignment, they are granted the broader level of access.

NEW: Access from RBAC roles and ABAC assignments is evaluated as a union. If either source grants access, the user receives access through that source, and the effective result reflects the broader permission configured by the administrator. To reduce access, administrators must review both the user’s roles and their ABAC assignments.

No. Existing access remains unchanged until assignments are configured or roles are updated. To achieve least-privileged access, organizations must explicitly configure assignments and adjust roles where necessary.

No. Enabling ABAC does not require any data or configuration migrations. Once enabled, administrators can configure assignments based on their organization's access requirements.

It depends on your current access model. In many cases, organizations may choose to simplify, modify, or remove custom roles as assignments are adopted to help achieve least-privileged access.

NEW: It depends on your current access model. Organizations may simplify, modify, or remove broad custom roles as assignments are adopted to help achieve least-privileged access. A common approach is to provision users into a minimal role, such as the Basic role, and use ABAC assignments to grant access to the specific records they need. For example, an administrator could remove broad Project Respondent access and share assignments only to the assessments a user supports.

No. An assignment can be mapped to sharing, an attribute, or a workflow, but not multiple mechanisms simultaneously. If the same permissions are needed across multiple mechanisms, the assignment must be copied and configured separately for each one.

Yes. Assignments can be associated with custom attributes.

NEW: Yes. ABAC assignments can be associated with both system attributes and custom attributes.

ABAC access can be shared with user groups as well as individual users, depending on the supported sharing and assignment configuration. Use existing groups where practical rather than creating static roles solely to represent record-level access.

No. Workflow assignments are available only for supported objects. Review the Supported Objects, Exclusions & Timelines for Attribute-Based Access Control (ABAC) article for current availability.

Yes. Some objects and functionality are not included in Public Preview and will follow a later adoption timeline. For the latest list of planned objects and timelines, see Supported Objects, Exclusions & Timelines for Attribute-Based Access Control (ABAC).

NEW: Yes. Some objects and functionality are not included in Public Preview and follow a later adoption timeline. The Consent module and CMP are not currently in scope for ABAC Phase 1: Foundations. Support varies by object and access mechanism, so review the Supported Objects, Exclusions & Timelines for Attribute-Based Access Control (ABAC) article for the current list.

For the latest list of planned objects and timelines, see Supported Objects, Exclusions & Timelines for Attribute-Based Access Control (ABAC).

Not in ABAC Phase 1: Foundations. In ABAC Phase 1: Foundations, assignments are granted when access is provided to a record through sharing, workflows, or a user’s relationship to an attribute. SSO and SCIM continue to provide roles, users, and groups; they do not directly grant assignments.

Not in ABAC Phase 1: Foundations. In ABAC Phase 1: Foundations, SCIM can provision users and groups and can support role and group membership management, but ABAC assignments are granted through record-level sharing, workflows, or attribute-based relationships.

ABAC works alongside SSO and SCIM role synchronization. It is an additional authorization layer on top of RBAC, and ABAC assignments are delivered independently of the roles provided through SSO or SCIM.

For least-privileged access, the recommended model is to provision users into a minimal role, such as the Basic role, and use ABAC assignments to determine which records they can access.

ABAC should complement the existing SCIM/SSO model rather than replace it upfront. Use SSO and SCIM for authentication, user onboarding, and group membership. Use ABAC for more precise, record-level access based on business context.

Over time, ABAC can become the primary model for record-level access while the existing identity and provisioning processes continue to operate.

Keep authentication, onboarding, and basic group membership in SSO and SCIM. Move record-level access decisions into ABAC assignments and policies.

Customers should consider provisioning users into a minimal role with no default record access, then using ABAC to determine which records those users can access. This can reduce the need for broad viewer, collaborator, and other custom roles.

Use existing user groups as a starting point because records can be shared directly with groups. Avoid creating additional static roles solely to represent record-level access.

ABAC is intended to reduce role complexity over time. ABAC Phase 1: Foundations supports manual sharing and assignments, while ABAC Phase 2: Dynamic Access is planned to automate access using record attributes and workflow conditions.

Yes. Existing SSO, JIT, and custom group mappings can continue to provide roles and group membership while ABAC provides record-level access.

In ABAC Phase 1: Foundations, ABAC assignments are not directly delivered through those mappings. The ABAC Phase 2: Dynamic Access plan is to route assignment access to user groups based on record attribute conditions, so customers can use SCIM to place users into the appropriate groups for automated access on onboarding.

No. For integrations with external systems, continue to use scopes or public APIs to control access to OneTrust data. This answer addresses system-to-system access and does not determine how ABAC applies to invited human users or external collaborators.

Public Preview support for reporting is limited. For supported objects, column reports, PDF reports, and schedules will respect ABAC assignments. Conversational analytics and dashboards do not support ABAC during Public Preview and will continue operating under their existing access model until broader reporting support becomes available.

For more information, see Reporting Considerations for Attribute-Based Access Control (ABAC).

NEW: Public Preview support for reporting is limited. For supported objects, column reports, PDF reports, and schedules respect ABAC assignments. Users can download a report for records they are authorized to access when they have the required RBAC and ABAC permissions. If access to a record is approved, the user can also download attachments associated with that record, subject to the applicable permissions. Conversational analytics and dashboards do not support ABAC during Public Preview and continue operating under their existing access model until broader reporting support becomes available.

ABAC controls which assessment records an approver can access. Approvers see assessments granted through an ABAC assignment or existing RBAC permission rather than receiving unrestricted visibility through broad Self-Service Portal access. The portal can still be used to launch assessments and perform its supported functions.

ABAC access controls are applied when users search for records using the Search field in the Global Header. Users can discover and access only the records they are authorized to view based on their roles, assignments, attributes, workflows, sharing relationships, and other applicable access controls.

Unless users are already aware of specific information or records that have not been shared with them, they generally will not know about information they do not have permission to access.

Reporting will not be fully ABAC-enabled until the Fall Seasonal Release. Until broader reporting support becomes available, OneTrust recommends limiting reporting access to managers and Site Admins.

No. ABAC Phase 1: Foundations does not limit which attributes are visible on a record, including records in the Vendors and Engagements details pages. Attribute visibility is planned for a later phase of ABAC and is not part of the Phase 1 access model.

Use the Activity Log and the Manage Access capability on a record to review who has access. Organizations can also request the Global Activity Log so access-related events are captured in one place. If activity-log data must be exported from OneTrust, continue to use Integration Builder with the Activity Log integration.