Working with scopes

Luna B. Technologies, a large global technology firm, views each control in their 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, as 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 4 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 scope assignment control is created. Each scope assignment has an owner who defines the scope assignment control's implementation process. The scope assignment control can have its own labels, Hypersyncs, tasks, and repeating tasks for collecting proof. Automated control testing can also be run on the scope assignment control.

Administrators and compliance managers only need to manage the main control. All collected proof is visible via the Proof tab in the main control. It's important to note that proof attached to scope assignment controls is "rolled up" to the main control, but not to other scope assignment controls. Scope assignment controls don't inherit proof from each other or from main 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 product 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 main control now has three scope assignment controls, each with its own access, its own owner, its own implementation procedures, and its own set of proof to collect. The administrator can check the main control and view all of the proof collected across the three different scope assignment controls (this includes proof stored in labels).

Watch this short video to learn more about scopes.