Scope

The Scope module is where you draw the lines inside your organization. Almost every other governance module asks “for which part of the organization does this apply?” Scope is where that answer lives.

You’ll create scope nodes when you need to track a control, a risk, an evidence claim, or any other governed record against a specific facility, service, department, system, data domain, or other boundary inside your organization. Without scope, every record is implicitly organization-wide; with scope, you can say “this control applies to our customer-facing services only” or “this risk affects our European data domain.”

When you would reach for this

You set up scope when:

• A framework requires you to demonstrate compliance for a specific boundary (a facility, a service, an information system, a jurisdiction).
• Different parts of your organization have different risk postures and you want to track them separately.
• A control needs to be enforced consistently across many similar boundaries (the same patch-management control across forty servers, for example).
• You’re preparing for an audit and need to demonstrate that you have evidence for the audited boundary specifically.
• Reporting needs to be sliced (by site, by business line, by data domain) and you want the slicing baked into the records themselves rather than reconstructed each time.

What lives in scope

Two record types:

1. Scope nodes are the boundaries themselves. Each node has a name, a stable key you pick, an optional description, and a scope kind (the type of boundary it represents).
2. Scope memberships link a record in another module (an asset, a service, a contract, a control) to the scope node it belongs to. Memberships are the connective tissue: a single asset can be a member of multiple scope nodes (it sits in a facility, supports a service, and processes one information type), and a single scope node can contain many members.

Scope nodes can nest. A facility node can have rooms beneath it; a service node can have sub-services. Parent-child relationships are expressed through the parentScopeNodeId field on a node.

Scope kinds

When you create a scope node, you mark it with a scope kind describing what it represents. Common kinds:

Kind is free text, so if your organization has its own vocabulary (cells, pods, lines, divisions), use that. The product doesn’t impose a fixed list.

A worked example: a multi-site manufacturer

A manufacturer with three production sites and one R&D center wants to track quality and security controls against each site independently while keeping organization-wide policies coherent. Their governance lead, Priya, sets up Scope like this.

Step 1: root node. Priya creates a single top-level node scopeKey: "org-root", kind organization, name “Acme Manufacturing.” Everything else will sit beneath it.

Step 2: facilities under the root. She creates four child nodes, kind facility, one for each site: plant-a, plant-b, plant-c, rnd-center. Each carries the site’s name and a short description.

Step 3: services that cross facilities. Some services aren’t tied to one site. She creates service nodes at the org level: iam (identity and access), email, customer-support-portal. These have no specific facility parent; they’re owned by central IT.

Step 4: link existing assets to the right scope. Priya goes to Assets and finds the access-control system at Plant A. From the Scope tab on that asset, she creates a membership linking it to the plant-a facility node. She does the same for every asset, picking the facility (and sometimes the service) each one belongs to.

Step 5: link a control to multiple scope nodes. A “Quarterly access review” control needs to be performed at every facility. From the control, Priya creates scope memberships to plant-a, plant-b, plant-c, and rnd-center. The control now demonstrates coverage of all four sites; assessments against it can be sliced per facility.

Later, when an auditor visits Plant B, the team can pull every control, evidence claim, and finding that has a membership linking it to the plant-b scope node. The audit scope is defined by the boundary, and the boundary is a single object everything else points at.

Memberships and roles

When you create a membership, you can label its membership role (e.g., primary-owner, consumer, provider, processor, hosts). The role explains how the member belongs to the scope node, not just that it does. A service might be hosted-in a facility and consumed-by a department; the role distinguishes the two relationships.

Like scope kind, membership role is free text; use the vocabulary that fits your organization.

What you’ll see in the product

Scope lives under Governance → Scope in the workspace.

The Scope list shows every scope node you’ve defined, in a tree view that respects the parent-child structure. Filter by status, kind, or owner.

Inside a scope node, the Members tab shows everything that’s a member of that node, grouped by source module. You see the assets at this facility, the services hosted here, the controls scoped to it, and so on, in one place.

Inside any asset, service, control, or other record that supports scope membership, you can see the scope nodes it belongs to and add or remove memberships directly. You don’t have to come back to the Scope module to wire things up; the relationship is reachable from both ends.

Every change is captured in the workspace Audit Log with the actor, the change, and the reason you provided.

Snapshots

When a scope node is referenced by a framework adoption, a risk assessment, an evidence claim, or an audit package, the referring record captures a snapshot of the scope at that moment. The snapshot is what gets reviewed in an audit, not the live scope node. This means changing a scope node later (renaming it, adjusting its description) doesn’t retroactively alter records that were created against an older version of that node.

For day-to-day work this is invisible; for compliance reviews it’s the guarantee that historical records reflect what was true at the time, not what is true now.

Common workflows

Setting up scope for the first time

1. Scope → New scope node. Create one root node, kind organization, for your whole organization.
2. Decide what boundaries matter for your governance work. Most organizations start with facilities (where things physically sit) and services or systems (what the organization delivers or operates).
3. Create the next layer of nodes beneath the root.
4. As you wire up controls, evidence, and other records, create memberships linking them to the relevant scope nodes.

Adding a new facility

1. Create the facility scope node under the root (or under a regional grouping if you have one).
2. As assets and services are added at that facility, create memberships from each one to the new facility node.
3. Any organization-wide control automatically applies; any facility-specific controls need an explicit membership to the new node.

Reorganizing the boundary structure

1. Create new scope nodes representing the new structure.
2. Move memberships from the old nodes to the new ones one record at a time, or use the bulk membership re-assignment workflow inside each affected module.
3. Archive the old scope nodes once nothing references them.
4. Historical records keep their snapshot of the old structure for audit purposes.

Decommissioning a scope

1. First, remove or re-assign all current memberships pointing at the node.
2. Scope → [node] → Archive, providing a reason.
3. Existing snapshots in older records remain readable.

Related

• Frameworks - frameworks adopt against a scope.
• Controls - controls live in scope (or organization-wide).
• Risks - risks are assessed against a scope.
• Evidence - evidence claims are scoped.
• Assets - assets are typical scope members.