Managing Control Implementations
What is a control implementation?
A control implementation is the process of designing and putting into action specific safeguards, procedures, or processes to protect an organization from risks. This involves configuring, customizing, and deploying controls to meet security and regulatory requirements, ensuring they are effectively integrated and documented.
In today’s complex compliance environment, organizations face the challenge of managing a vast number of controls across various frameworks, inventories, and business units. Without the right approach, this can lead to redundant efforts, increased risk of errors, and a fragmented view of your control environment.
How can shared controls help manage control implementations?
OneTrust’s shared controls functionality is designed to address this challenge, empowering teams to reduce duplication, increase efficiency, and align control management with how organizations operate in the real world.
Historically, applying a control library record to multiple objects in OneTrust has resulted in a new control implementation each time. Over time, this leads to hundreds of duplicate controls for what is, in practice, a single policy or process. Not only is this inefficient, but it also creates complexity in reporting, auditing, and ensuring consistency across compliance efforts. For example, a single organization-wide change management policy might apply to processes, systems, and business entities, but under the traditional setup, it must be documented separately for each one.
With shared controls, you can align multiple inventories to a single control implementation, significantly reducing redundancy and effort. This approach reflects how organizations naturally manage controls, centrally and consistently, yet flexibly enough to address different scopes and entities.
Where can shared controls be leveraged?
The following areas in OneTrust support shared controls.
|
Shared Control Functionality |
Description |
|---|---|
|
Control Management |
|
|
Reporting |
|
|
Risk Management |
|
|
Bulk Import |
|
The following areas in OneTrust do not currently support shared controls. However, support may be considered in the future.
-
Leverage the inventory hierarchy to add inventories to shared controls.
-
Public APIs
-
Assessments
-
Custom Integrations
Shared Control Business Logic
This section outlines the business logic that governs shared control implementations. It covers how shared controls operate, how evidence is shared across controls, and the rules for merging and splitting both control implementations and their associated evidence.
Shared control implementations
-
A control implementation can be linked to multiple inventories (assets, entities, vendors, processing activities) or risks.
-
An inventory can only be the primary inventory on a single implementation of a control library record.
-
The primary inventory on a control implementation cannot be changed after it is created. If a different primary inventory is needed on the control implementation, you can create a new, separate control implementation with the correct primary inventory and the original control implementation can be merged into it.
-
An inventory can be linked to more than one control implementation of the same control library record as a related inventory.
-
An evidence task implementation will inherit the same primary inventory as its linked control implementation. It will also have relationships to all other related inventory records.
-
You can add or remove related inventories from the control implementation. These changes will be reflected on the associated evidence task implementations.
Sharing evidence across controls
-
Given a Control Library and Evidence Library relationship, control implementations will share an evidence task implementation if the primary inventory is the same.
-
By default, evidence is shared where possible. Users can choose to create a separate evidence task implementation later, if needed.
-
The shared evidence task will include all related inventories from the control implementations in which it is linked.
-
Adding or removing related inventories (outside of the primary inventory) on control implementations will flow down to the shared evidence task(s).
-
Inventories cannot be added or removed directly on an evidence task implementation.
Merging and splitting control and evidence implementations
See Merging Control Implementations and Evidence Tasks and Splitting Control Implementations and Evidence Tasks for more information.
-
Implementations of the same Control Library record can be merged into one.
-
The primary inventory of the control implementation will be retained moving forward, along with its attribute values.
-
Linked records (e.g. issues, risks, related inventories, etc.), tasks, and attachments will be copied into the merged control implementation.
-
Assessments, activity logs, workflow stages, and comments will not be merged.
-
The merged control implementations will be removed.
-
-
Evidence task implementations can be merged within the merge control implementation flow.
-
The primary inventory of the linked control implementation being merged will dictate which evidence task implementations will be retains and merged into.
-
The attribute values of the merged evidence task will remain (e.g. assignee).
-
Evidence collected on each evidence implementation will be copied into the merged evidence task.
-
Some evidence tasks cannot be merged if they are shared across multiple control from different frameworks. In this case separate evidence task implementations will remain.
-
-
Evidence implementations can be merged or split later within a separate merge evidence implementation flow.
-
Keep evidence task implementations merged on a shared control to collect evidence centrally for the shared control. For example, a privacy policy applies to all regional entities and just needs to be collected once.
-
Split evidence task implementations on a shared control to collect evidence separately for each inventory on the shared control. For example, each asset-application owner is responsible for collecting proof of password configuration.
-
-
A shared control implementation can be split into individual implementations of the control, one for each inventory on the shared control implementation. Evidence will be split into separate implementations and linked to its respective control implementation record.
-
Attachments / evidence collected on the original control implementation will not be copied to each separate implementation.
-
The attribute values (e.g. assignee) of the split control (and evidence) could be optionally copied into the separate implementations.
-
Creating Controls in the Control Library
This section outlines two approaches for creating controls using the control library: shared controls and separate control implementations. Follow the steps outlined in the sections below to create controls using each approach.
To create shared controls using the Control Library
Follow the steps outlined below to create shared controls on specific control library records. These controls are implemented once and mapped across one or more inventories.
To create separate control implementations using the Control Library
Follow the steps outlined below to create separate control implementations for each inventory selected. Separate control implementations are individual control records created for each framework or requirement, even when the control activities are similar. Use separate implementations when different frameworks require unique evidence, language, or ownership, or when the control is applied differently across business units.
Creating Controls in Inventory Records
This section outlines how to add controls directly within an inventory record using different methods. You’ll learn how to add multiple shared controls at once, add a single shared control, and link an existing control implementation to an inventory. Each method supports different use cases depending on how controls are managed across frameworks.
To add multiple shared controls to an inventory record
To add a single shared control to an inventory record
To add an existing control implementation to an inventory
Managing Shared Controls
To add related relationships to shared controls
To add existing risks to shared controls
Use Cases
- Test Once, Comply Many
-
Meet multiple compliance requirements with a single control to reduce duplicate efforts.
- Cross-Inventory Application
-
Apply one control across multiple assets, processes, or business units without recreating the control.
- Streamlined Evidence Gathering
-
Centralize evidence for faster audits and assessments.
- Dynamic Scope Management
-
Easily adjust the scope of a control as your business needs evolve.
- Simplified Reporting
-
Get a unified view of control coverage without sifting through redundant records.