The world of compliance is ever-evolving, and organizations are responsible for adapting to any changes that apply to their respective industries. In order to ensure that the UCF’s Common Controls continue to provide a high level of coverage and reflect the changing compliance requirements, it is sometimes necessary to adjust our suite of Common Controls. With this in mind, the UCF Team regularly reviews the Common Controls that are in place and compares them with published guidance, organizational needs, and good practice.
What to Expect with Common Control
...
Modifications
When a Common Control is updated or changed, the Authority Document mapping will automatically be updated in the Common Controls Hub (CCH).
This will result in any of the following:
...
new implied (parent controls)
new implementation controls (children controls)
changed control title
Changed Control to Citation Mapping (New Control ID)
Actions to Take
A generated build is static, so a new build will need to be generated to reflect the control changes.
Lists sent to GRC solutions will need to be resent for the changes to take effect in the GRC solution.
Types of Control Changes
Hierarchy Changes
Control Merges
Control Deprecations
New Controls
Split Controls
Hierarchy Changes
This occurs when a Common Control is moved to a new place in the Control Hierarchy.
Why?
The UCF’s Common Controls are organized in the form of a hierarchy that is broken down from general, widely applicable controls to those that satisfy specific compliance requirements. The highest level controls represent the categories or Impact Zones under which each control set will fall.
Occasionally upon review or based on guidance, the UCF team determines a more applicable parent control.
Hierarchy Changes Impact
New implied controls
New implementation controls
Control Merges
This occurs when two or more Common Controls are merged into one surviving Common Control.
Why?
With the vast number of Common Controls that the UCF manages, a degree of overlap is anticipated and sometimes necessary. Occasionally, either based on changing requirements, enhanced conceptualization, or even a change in preferred word usage, there may be two controls that satisfy the same specific requirement. To eliminate control redundancy in such cases, the controls will be merged. When merging controls, the Mapping Team will compare the two similar controls through the Citations tab in the Research Portal by searching the control IDs. Typically the control that is linked to the most mandates will be the surviving control.
...
If both controls are linked to the same number of mandates, the Mapping Team will deliberate in order to determine the surviving control based on the wording. After the controls are merged, the citations linked to the deprecated control will be linked to the surviving control on the back end.
Control Merges Impact
New Control to Citation Mapping (New Control ID)
New implied controls
New implementation controls
Control Deprecation
This occurs when the UCF Team deprecates a Common Control.
Why?
This will occur when the UCF team merges an existing Common Control into another Common Control.
Control Merges Impact
New Control to Citation Mapping (New Control ID)
New implied controls
New implementation controls
New Control
This occurs when the UCF Team creates a new Common Control.
Why?
As new regulations are passed, and as Unified Compliance’s coverage expands into different industries, the need will arise for new Common Controls. The need for a new Common Control is generally considered on a document-by-document basis, as most regulations in the industries currently served by Unified Compliance are covered by our current control sets. New controls are generally created when no established controls will satisfy a compliance requirement. The need for a new control is determined after careful examination of current controls and discussion among the Mapping Team and organizational leadership. In technical terms, we do not create new controls willy-nilly.
New Control projects can either be spawned through a Citation Matching task, or they can be selected from the Projects tab on the user dashboard. New controls are worded to apply to specific requirements without leaving coverage gaps or restating established control requirements. Similar to Citation Tagging tasks, the control will need to be tagged to facilitate matching, with appropriate definitions selected. The control is then linked to audit items in order to provide evidence that will be reviewed by examiners. Finally, a suggestion will be made as to where the control will fall in the hierarchy before being reviewed and approved by members of the Mapping Team.
Control Merges Impact
New Control to Citation Mapping (New Control ID)
New implied controls
New implementation controls
Control Split
This occurs when an existing Common Control is split into more than one Common Control.
Why?
Control Splitting is the opposite of Control Merging. When controls are created, they are worded to satisfy a requirement in full without leaving gaps. This requires the control’s wording to reflect the language of the mandates at the time of the Mapping. As governance documents are amended, updated, or replaced, and requirements change, and the language of the mandates will also change. This can cause a control to overapply to a particular mandate or cover only elements of a mandate while leaving coverage gaps. When this happens it is sometimes necessary to split one control into multiple controls.
...
In this case, an Edit Control task will need to be opened to edit the main control to apply to the first mandate, and a new control will be created to cover the second mandate.
Control Merges Impact
New Control to Citation Mapping (New Control ID)
New implied controls
New implementation controls
...