Managing Attribute-Based Access Control (ABAC) for Tech Risk & Compliance

Important:

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

Overview

In ABAC Phase 1: Foundations, Attribute-Based Access Control (ABAC) for Tech Risk & Compliance enables organizations to grant access to specific records without providing broad access across the entire solution. By combining role-based access with record-level assignments, organizations can support collaboration across risk, compliance, policy, and audit-related activities while maintaining least-privilege access.

ABAC is particularly valuable in Tech Risk & Compliance because different stakeholders often need to participate in activities related to specific risks, controls, initiatives, policies, and evidence tasks without requiring access to all records within the solution.

How ABAC Works in Tech Risk & Compliance

In Tech Risk & Compliance, assignments are provisioned as record-level access grants that layer on top of a user's existing role and permissions. Rather than granting access to the entire solution, assignments provide access to individual records and define what users can do on those records.

ABAC enables organizations to control who can view, edit, administer, share, and collaborate on specific records. For example:

Risk owners can be granted access to specific risks requiring review or remediation.
Control owners can collaborate on individual controls without receiving broader solution access.
Policy stakeholders can review and contribute to specific policies or procedures.
Compliance contributors can participate in initiatives or evidence collection for individual records.

The primary goal is to support collaboration around specific Tech Risk & Compliance records while maintaining visibility, ownership, and least-privilege access.

Common Use Cases

Use cases describe the most common business scenarios where ABAC helps teams collaborate on records while maintaining least-privilege access. The examples below highlight how organizations can use ABAC to provide the right users with access to the right records at the right time.


Use Case	How ABAC Helps
Risk Management	Allows stakeholders to collaborate on specific risks without receiving access to all risk records. Example personas include: Chief Information Security Officer (CISO), Chief Risk Officer (CRO), and Risk & Compliance Practitioners / GRC Analyst.
Control Management	Enables control owners and reviewers to participate in control-related activities for individual records. Example personas include: CISO, Compliance Lead / Manager, Internal Audit, Risk & Compliance Practitioners / GRC Analyst.
Policy and Procedure Reviews	Provides scoped access to specific policies, procedures, and standards undergoing review or approval. Example personas include: Compliance Lead / Manager and Policy Manager / Policy Owner.
Compliance Initiatives	Allows contributors and reviewers to collaborate on specific compliance initiatives and related records. Example personas include: Compliance Lead / Manager and Risk & Compliance Practitioners / GRC Analyst.
Evidence Collection and Reviews	Enables stakeholders to access only the records necessary to complete evidence gathering, reviews, or attestations. Example personas include: Compliance Lead / Manager, Internal Audit, Risk & Compliance Practitioners/ GRC Analyst, and Third-Party Auditor.

Key Workflows Impacted by ABAC

ABAC introduces record-level access controls within existing solution workflows. The following workflows are commonly impacted by ABAC and may change how users access, review, and collaborate on records.


Workflow	How ABAC Changes the Experience
Risk Reviews and Remediation	Enables targeted collaboration on specific risks and remediation efforts without requiring broader access.
Control Management	Allows users to manage and review individual controls based on their responsibilities.
Policy, Procedure, and Standard Reviews	Supports participation in the review and maintenance of specific governance documents.
Compliance Initiatives	Enables collaboration on specific initiatives while limiting access to unrelated compliance activities.
Evidence and Audit Activities	Allows users to contribute to or review evidence and related activities on specific records.
Cross-Functional Collaboration	Supports sharing and collaboration on specific records across governance, risk, compliance, and audit teams.

Tech Risk & Compliance-Specific Considerations

Tech Risk & Compliance programs commonly involve collaboration among risk owners, risk approvers, risk managers, control owners, task owners, business stakeholders, auditors, and other governance teams. ABAC enables organizations to grant access to specific risk records and actions based on assignments and attributes, reducing the need for broad role-based access across the entire IT Risk Management product.
Risk assignments such as Risk approver, Exception approver, Risk manager, Risk owner, and Stage approver can independently grant access to specific risk records when ABAC is enabled. As a result, users may gain access through assignments even when they do not have broader role-based permissions traditionally required in non-ABAC environments.
Risk visibility and data exposure are still governed by the View risks permission. This permission determines which risk attributes are visible to users and may result in partial data visibility or redacted information based on a user's assigned permissions and relationship to the risk.

Understanding ABAC Changes in Tech Risk & Compliance

ABAC includes certain system assignments by default. These out-of-the-box assignments apply across all objects, so you can begin managing access without creating assignments manually.

You are not required to use the default behavior. If your organization needs more specific access rules, create custom assignments to override selected default permissions. This allows you to retain the standard capabilities where they work for you while tailoring access for specific objects or business requirements. For more information, see Managing Assignments with Attribute-Based Access Control (ABAC).

Editing Risk Records


Before ABAC	After ABAC	Things to Know
The user role needed the relevant edit permission. The user needed to be assigned as the Risk owner, Risk approver, or Risk Manager or have the Act as an admin on risks permission.	Users assigned as the Risk owner, Risk approver, or Risk manager can edit the specific risk based on assignment alone. They no longer need the broader organization-wide risk permission. Role-based permissions and record-level assignments can independently grant access to risks.	Confirm risk assignments are set up to preserve access for users with custom roles with risk-editing permissions. The risk-editing permissions on the role alone will not apply it at the record level. A risk owner can reopen risks within their organization and all child-orgs. Risk owners cannot reopen risks above or outside of their organization. Permission checks do not happen outside the organization. However, assignments can grant users access to risks outside their organization.

Control Implementation Access


Before ABAC	After ABAC	Things to Know
Users needed role-based access to view control records and related tabs. In some cases, seeded assignments such as Control owner, Control approver, Control admin, or Task assignee could impact control record access.	Users assigned as the Control owner, Control approver, Control admin, or Task assignee now have expanded access. Actions like changing the record status, launching assessments, or editing implementation details still rely on the corresponding role-based permission and record-level assignments. The View all org control implementation permission no longer grants users the ability to view related task details. Access now requires the role permission, ownership, approval, or being the assignee. Admin-level access must now come through an explicit role-based permission. The Control admin role no longer grants extra access automatically.	Before enabling ABAC, validate custom roles to ensure assigned users maintain the correct action-level access and review Control owner and Control approver assignments. Test control details, workflows, assessments, activity, and related tabs in a non-production environment to identify changes in access behavior.

Evidence Tasks Access


Before ABAC	After ABAC	Things to Know
Access to evidence task details depended solely on the corresponding permissions that determined whether the user could add, remove, or manage related tasks and content.	Control owners, Control approvers, Task assignees, and Evidence assignees can access evidence task details through record-level assignments. The evidence owners can edit the evidence task record. Actions like changing the record status, launching assessments, or adding and removing evidence tasks still rely on the corresponding role-based permission and record-level assignments. Admin-level access must now come through an explicit role-based permission.	Before enabling ABAC, confirm the evidence assignee and task assignee values are populated correctly. After ABAC is enabled, compare the view actions to the edit and delete actions separately. Assignment-based access is not identical for every evidence-task action.

Exception Access


Before ABAC	After ABAC	Things to Know
Users needed the relevant role-based permissions for each exception capability or tab. For example, viewing exception details required both the Exception details view permission and the Exception attribute groups view permission.	Users can access exception details and perform workflow, task, activity, document, related, comments, control, and risk actions when the relevant permission is granted through a role, or when they are the exception requestor, exception approver, or a user with an assignment.	Before enabling ABAC, review exception requestor, exception approver, and assignment values. Assignment-based access can grant exception actions in addition to role-based access, so validate custom roles and test each capability in a non-production environment.

Initiative Access


Before ABAC	After ABAC	Things to Know
Users needed the relevant role-based permission to view and manage initiatives.	Users can view and manage initiatives using relevant role-based permissions and record-level assignments.	Review initiative assignments before enabling ABAC to confirm that the intended users receive access. Existing role-based access remains available, while assignments provide an additional way to grant access.

Issue Record Access


Before ABAC	After ABAC	Things to Know
Users needed the relevant role-based permission to view and manage issues, issue tasks, comments, workflows, and attachments.	Issue owners can access assigned issues along with users who have the role-based permissions. Issue owners can view and edit issue records and related details regardless of whether they hold the specific role permission. Issue approvers can access assigned issues along with users who have the role-based permissions. However, approvers do not have the ability to edit, create comments, or create tasks. These actions are limited to Issue owners and role-based permission holders.	Before enabling ABAC, review the Issue owner and Issue approver assignments to ensure action-specific permissions such as the Edit issues, Change issue workflow stage, and Create issue comments permissions are on roles where users need broader access. Before enabling ABAC, validate custom roles that rely on issue task and attachment permissions to ensure assigned users maintain the correct action-level access. Validate issue details, workflow stage, and comment behavior in a non-production environment to identify changes in access behavior. Update internal role-mapping guidance if your implementation distinguishes owner access from approver access. After ABAC is enabled, test task, attachment, activity, and workflow-tab behavior to compare the view and edit actions separately. Assignment-based access is not identical for every issue-task action.

Policy, Procedure & Standard Access


Before ABAC	After ABAC	Things to Know
Users needed the relevant role-based permission to view, edit, and manage documents, approve workflows, view activity, and manage related content. Owners and approvers also needed the appropriate assignments.	The View basic fields permission grants access to basic attributes. The View advanced fields permission grants access to advanced attributes. Role-based permissions or Editor and record-admin level assignments can independently grant edit access. Users with delete permissions can delete the applicable records. Users with the workflow stage approve permission or an applicable workflow assignment can approve the record. Users with the relevant permission through a role or assignment can view activity or attachments and perform the applicable content builder operation on the record.	Before enabling ABAC, validate the delete and approval permissions, workflow assignments, and approval behavior. Validate content builder permissions and assignments separately from general record access. Review custom roles and assignments. Advanced-attribute visibility now depends on the explicit view advanced fields permission. Review activity and attachment permissions and assignments to confirm that users retain the intended visibility.

Risk Admin Access


Before ABAC	After ABAC	Things to Know
The Act as an admin on risks permission allowed users to complete the following actions on any organization risk regardless of their assignment: edit, update attributes, delete, restore, move workflow stages, bulk actions, manage attachments, manage tasks. The Act as an admin on risks permission did not check if the risk belongs to the users organization hierarchy. This resulted in users being able to act on risks outside their reporting line.	The Act as an admin on risks permission will still appear in your roles configuration, but it will no longer take effect once ABAC is enabled. The equivalent access will instead come from the specific action permission (for example, the delete permission) combined with the View all organization risks permission on the role.	If an existing role depends on the Act as an admin on risks permission for access to risks they aren't directly assigned to, grant the equivalent action-specific permission(s) and the View all organization risks permission before ABAC is enabled. No permission checks will happen if a role does not include the View all organization risks permission.

Field-Level Permissions

Additional field-level permission capabilities will be added in future releases. These field level permissions are related to pre-existing Tech Risk & Compliance capabilities. Additional field-level capabilities will be added in the future, with ABAC Phase 2: Dynamic Access.


Before ABAC	After ABAC	Things to Know
Custom roles and users were assigned to risks based on ownership and approval assignments (RBAC behavior). Access to individual fields were based on these assignments. Users assigned to risks could view risk attributes, filters, and saved views within other objects.	Field-level permissions for risks have been introduced through the View basic fields for risks, View advanced fields for risks, and action-specific permissions. The View basic fields for risks permission grants users access to all risks within their organization and their basic attributes. If a role does not have this permission and ABAC is enabled, the permission will have no impact. The View advanced fields for risks permission grants users access to all risks within their organization and their advanced attributes. If a role does not have this permission and ABAC is enabled, they will not be able to view advanced attributes.	Before enabling ABAC, review workflows, reporting processes, or integrations that depend on risk ownership, approval, or management assignments. ABAC can change how users gain access to risks and perform risks across organizations. Before enabling ABAC, validate custom roles, assignment configurations, approval processes, and organizational hierarchies in a non-production environment to identify changes in access behavior.

Supported Objects, Attributes & System Assignments

This section provides a reference for the objects that support ABAC within this solution and the system assignments that can be used to grant record-level access. Supported objects and assignments can be found by navigating to the Assignments screen in Global Settings. For more information, see Managing Assignments with Attribute-Based Access Control (ABAC).

Supported Objects

The following objects support ABAC within Tech Risk & Compliance and can be configured using supported ABAC capabilities: Assets, Control, Entities, Evidence tasks, Exceptions, Initiatives, Issues, Policies, Procedures, Processing activities, Risks, Standards, Vendors.

Note:

Audits, Business Objectives, Findings, and Workpapers are not currently supported. For more information, see Supported Objects, Exclusions & Timelines for Attribute-Based Access Control (ABAC).

Supported Attributes

The following attributes support assignment-based access and can be used to automatically grant record-level permissions based on ownership, responsibility, participation, or other user relationships. Attributes are organized by object and divided into standard and advanced attribute categories.


Object	Standard	Advanced
Assets	Created By, Created Date, Hosting Location, IT Owner, Last Updated By, Last Updated Date, Managing Organization, Name, Status, Type	All system and custom attributes.
Controls	Category, Control Approver, Control ID, Control Name, Control Owner, Description, Guidance, Implementation Id, Organization, Record Admin, Source, Source Type, Stage, Standard / Framework, Status, Workflow	Custom Attributes, Deadline, Effectiveness, Inventories, Linked Objectives, Maturity, Risks
Entities	Created By, Created Date, Last Updated By, Last Updated Date, Legal Entity Owner, Name, Organization, Primary Operating Location, Status, Type	All system and custom attributes.
Evidence tasks	Approvers, Assignee, Collection Interval, Current Interval Status, Due Date, Guidance, ID, Last Collected, Name, Organization, Source, What to collect	Associated Controls, Automatic Collection, Collected Evidence, Collection Period Start Month, Related, Task Type
Exceptions	Created Date, ID, Name, Organization, Source	Closure Note, Date Resolved, Exception Approver, Expiration Date, Reason for closure, Reason For Exception, Requestor, Requestor Email, Result, SSP Stage, Stage
Initiatives	Date created, ID, Inventories, Name, Observation end date, Observation start date, Organization, Owners, Score, Source, Standards/Frameworks, Status	No advanced attributes.
Issues	Description, ID, Name, Organization, Owners, Priority, Source ID, Source Type, Status, Type	Action plan, Approvers, Category, Closed by, Closure note, Created By, Created Date, Data closed, Deadline, Reason for closure
Policies	Categories, Default Language, Description, Effective Date, Expiration Date, ID, Managing Organization, Policy Approvers, Policy Name, Policy Owners, Standard / Framework, Workflow	Added to Document Library Date, Published Version, Removed From Document Library Date, Template, Visible to all users in document library
Procedures	Categories, Default Language, Description, Effective Date, Expiration Date, ID, Managing Organization, Procedure Approvers, Procedure Name, Procedure Owners, Standard / Framework, Workflow	Added to Document Library Date, Published Version, Removed From Document Library Date, Template, Visible to all users in document library
Processing activities	Business Process Owner, Created By, Created Date, Last Updated By, Last Updated Date, Managing Organization, Name, Status	All system and custom attributes.
Risks	Children Risks, Closure Note, Hierarchy Level, Migration Status, Orphan, Parent, Reason for Closure, Reminder, Risk Appetite, Risk Template, Risk Tolerance, Threat, Vulnerability	Category, Date Closed, Date Created, Deadline, Description, ID, Inherent Risk Impact Level, Inherent Risk Level, Inherent Risk Probability Level, Inherent Risk Rollup Level, Inherent Risk Rollup Score, Inherent Risk Score, Last Updated By, Last Updated Date, Organization, Residual Risk Impact Level, Residual Risk Level, Residual Risk Probability Level, Residual Risk Rollup Level, Residual Risk Rollup Score, Residual Risk Score, Result, Risk Approver, Risk Domain, Risk Manager, Risk Name, Risk Owner, Source, Stage, Target Risk Impact Level, Target Risk Level, Target Risk Probability Level, Target Risk Score, Treatment, Treatment Plan, Treatment Status, Type, Workflow
Standards	Categories, Default Language, Description, Effective Date, Expiration Date, ID, Managing Organization, Standard / Framework, Standard Approvers, Standard Name, Standard Owners, Workflow	Added to Document Library Date, Published Version, Removed From Document Library Date, Template, Visible to all users in document library
Vendors	Business Owner, Created By, Created Date, Last Updated By, Last Updated Date, Name, Organization, Primary Vendor Contact, Status, Type, Vendor Workflow, Vendor Workflow Stage	All system and custom attributes.

System Assignments

The following system assignments are available out of the box and can be used to grant access based on common ownership, collaboration, review, approval, and access-management responsibilities.


System Assignment	Assignment Description	Access options	Applicable Objects
Assignee	Responsible for completing the evidence task within assigned intervals and ensuring evidence is gathered and submitted on time for review.	User attributes	Evidence tasks
Business Owner	Permits user to edit, delete, and reassign a record.	User attributes	Vendors, Processing activities
Control approver	Reviews the control and approves or advances it through workflow stages to help ensure compliance requirements are met.	User attributes	Control
Control editor	Allows users to edit and view a record.	Sharing	Control
Control owner	Responsible for maintaining the control, including updating details, managing evidence tasks, and advancing the control through workflow stages.	User attributes	Control
Editor	A risk editor updates risks to support the risk management process.	Sharing	Assets, Entities, Evidence tasks, Exceptions, Initiatives, Issues, Policies, Procedures, Processing activities, Risks, Standards, Vendors
Editor Assignments	Grants permission to edit and view a record.	Sharing	Assets
Exception approver	An exception approver reviews exceptions, recommends remediation actions, and approves exception requests.	User attributes	Exceptions
Exception approver	An exception approver reviews risk exceptions, recommends remediation actions, and approves exception requests.	Workflow	Risks
Exception requestor	An exception approver creates the exception request.	User attributes	Exceptions
Issue approver	Reviews the resolution before closure, verifies it meets acceptance criteria, and approves or rejects the outcome.	User attributes	Issues
Issue owner	Responsible for managing the issue from logging through resolution and ensuring corrective actions are tracked, documented, and completed on time.	User attributes	Issues
Legal entity owner	Permits user to edit, delete, and reassign a record.	User attributes	Entities
Record Admin	This assignment grants the identified user permission to edit, delete, and reassign the record. For more information, see Managing Record Admins & Ownership with Attribute-Based Access Control (ABAC).	Sharing	Assets, Entities, Evidence tasks, Exceptions, Initiatives, Issues, Policies, Procedures, Processing activities, Risks, Standards, Vendors
Risk approver	A risk approver reviews risks identified in an assessment to flag risks, propose remediation steps, and approve treatment plans.	User attributes	Risks
Risk manager	A risk manager oversees all risk identification, evaluation, treatment, and monitoring within the risk management process.	User attributes	Risks
Risk owner	A risk owner manages a specific risk, implements treatment plans, and ensures that necessary actions are taken to mitigate the risk.	User attributes	Risks
Stage approver	A stage approver reviews identified risks, flags key concerns, suggests remediation steps, and approves the risk treatment plan.	Workflow	Risks
Technical owner	Permits the user to edit, delete, and reassign a record.	User attributes	Assets
Viewer	Any OneTrust platform user identified as a viewer in the record.	Sharing	Assets, Entities, Evidence tasks, Exceptions, Initiatives, Issues, Policies, Procedures, Processing activities, Risks, Standards, Vendors

Additional Resources

For a complete list of ABAC resources, see the Attribute-Based Access Control (ABAC) User Guide, which includes foundational concepts, implementation guidance, and procedural configuration articles.

To learn how ABAC is implemented across other OneTrust solutions, explore the following solution-specific articles:

Settings & Administration