The scopes feature in Hyperproof provides a mechanism for distributing controls based on combinations of categories that identify specific sectors of your organization.
​

For example, you may have a group of people in Europe responsible for DevOps for your handcrafted soap product line. That combination of categories identifies a group of people responsible for providing proof for a control. However, there may be other similar groups in your company that must also provide proof for the same control, but at a different time.
​

Use scopes to track proof collection on controls for subdivisions of your organization. Note that scopes can only be linked to controls.

Luna B. Technologies, a large global technology firm, views each control in its organization as having three separate dimensions: Subsidiary, Region, and Software. Each of these dimensions has various sub-dimensions. For example, the Subsidiary dimension represents the organization's four products—Luna A., Luna B., Luna D., and Luna Y.
​

Different proof is needed to satisfy each scope, since each scope represents a specific business area. When each scope is satisfied, the main control is deemed healthy. Refer to Control health for more information.

Luna B.’s administrator creates three single-select custom fields. Each custom field is checked to be available on scopes. Note that up to 7 custom fields can be linked to scopes.

The administrator then creates five scopes based on the custom fields. Each scope has an owner.

Finally, the administrator assigns the scopes to their appropriate controls.

When a scope is assigned to a control, a control scope is created. Each scope assignment has an owner who defines the control scope's implementation process. The control scope can have its own labels, Hypersyncs, tasks, and repeating tasks for collecting proof. Automated control testing can also be run on the control scope.
​

Administrators and compliance managers only need to manage the main control. All collected proof is visible via the Proof tab in the parent control. It's important to note that proof attached to control scopes is "rolled up" to the parent control, but not to other control scopes. Control scopes don't inherit proof from each other or from parent controls.

No. Custom fields are useful for organizations that need additional hierarchy around scopes—as in the Luna B. Technologies example above—but are not required for using the scopes feature.
​

Example use case for scopes without custom fields
​

Luna B. Technologies has three product lines: Product 1, Product 2, and Product 3. A control in Luna B.’s program explicitly states that all of the company’s product lines must provide proof of user data encryption. Because each product line has different characteristics, different proof is needed for each line. Further, each product line must be tested independently to ensure that it’s achieving the control’s requirements.
​

Rather than creating additional controls, Luna B.’s administrator creates three scopes: Product 1, Product 2, and Product 3. The administrator then links each scope to the control. The parent control now has three control scopes, each with its own access, owner, implementation procedures, and set of proof to collect. The administrator can check the parent control and view all proof collected across the three control scopes (including proof stored in labels).