Controls

The Controls module is the library of every safeguard your organization operates: the access reviews, the encryption settings, the segregation-of-duties rules, the change-approval procedures, the training programs, the monitoring configurations. Each control is one record. The record names the control, identifies who owns it, tracks whether it’s actually implemented, and tracks whether it’s currently operating as claimed.

This module is the operational heart of most governance programs. Frameworks define requirements; Controls is where the work that meets those requirements is registered.

When you would reach for this

You set up controls when:

• A framework or obligation requires you to implement a specific safeguard and you need a place to register what you’ve done.
• An internal policy creates a control your organization wants to operate (e.g., “all production data exports are reviewed by a second person”).
• A finding or risk needs a new control to be created as remediation.
• You’re consolidating duplicated controls across business units into a single record with multiple scope memberships.

You don’t reach for this when capturing proof that the control is operating (that’s Evidence), running an assessment of the control’s effectiveness (Assessments), or recording a waiver from a control’s normal operation (Exceptions).

What lives in a control

A single record type:

Control carries:

• A title and a stable key you pick, plus a description.
• A status: draft, active, retired, etc.
• An optional subject: when a control is tied to a specific governed object (an asset, a service, a system, a process), this records the link. Often left blank for organization-wide controls.
• An owner: a responsibility assignment naming who is accountable for this control operating.
• An implementation projection: a current snapshot of whether the control is actually implemented, scored against an evaluation model.
• A compliance projection: a current snapshot of whether the control is currently meeting its expectations, scored against an evaluation model.
• A control snapshot: structured posture detail captured at the control level (implementation source, inheritance, automation, frequency, etc.).

The two projections (implementation and compliance) are deliberately separate. Implementation is whether the safeguard is in place. Compliance is whether it’s currently delivering the outcome. A control can be implemented but non-compliant if it’s in place but failing in operation.

Implementation sources

A control can be implemented in several ways. The control snapshot captures the source:

Capturing the source matters because the audit story changes by source. An outsourced control needs supplier-side evidence; a platform control needs the platform’s attestation.

A worked example: an online retailer manages its control library

A mid-size online retailer with global e-commerce operations runs hundreds of controls across customer data protection, payment processing, fraud detection, vendor security, and internal access. Their head of security, Marie, uses Controls like this.

Step 1: structure the library. Marie organizes the control library by business area: customer-data, payments, fraud, vendor-security, internal-access. Each area is a folder in her team’s mental model; in the product, controls are filterable by tags and scope memberships.

Step 2: register the foundational controls. For each obligation the company has registered in Obligations, Marie creates a control that implements it. Each control has a stable key (customer-data-encryption-at-rest, payment-card-network-segmentation, vendor-onboarding-due-diligence, etc.), a title, and a description of what the control does.

Step 3: assign owners. Each control gets an accountable owner via a responsibility assignment. The data-protection lead owns customer-data controls; the payments engineer owns payment controls; the security analyst owns fraud detection; the vendor-management lead owns vendor-security controls.

Step 4: capture the implementation source. Most controls are operated locally. Some are platform-provided: their payment processor operates several PCI-related controls on their behalf. Marie records each platform control with source platform and references the provider in the control snapshot.

Step 5: link to frameworks. Through Frameworks, Marie creates coverage links from each framework’s requirement nodes to the implementing controls. The same customer-data-encryption-at-rest control implements three different framework requirements; one coverage link per requirement.

Step 6: set up scope. Some controls apply organization-wide (employee-mfa-required). Some apply only to a specific service or facility. Marie creates scope memberships through Scope tying each control to the parts of the organization it covers.

Step 7: live operation. The two projections (implementation and compliance) update over time:

• Implementation moves to implemented as each control is rolled out and the team marks it deployed.
• Compliance is driven by Monitoring and Assessments: if monitoring shows MFA enforcement at 100% across the workforce, the compliance projection on employee-mfa-required reads compliant. If a monitor detects drift, the projection updates accordingly.

When an auditor arrives, Marie filters Controls by the framework in question, exports the list with owners and current projections, and walks through the open non-compliant items.

What you’ll see in the product

Controls lives under Governance → Controls in the workspace.

The Controls list shows every control, with status, owner, current implementation projection, and current compliance projection. Filter by status, owner, framework, scope, or projection value. This is the page you’d live in during an audit cycle.

Inside a control, you see:

• The full title, description, and source posture.
• Linked frameworks (through coverage links).
• Linked scope nodes (through memberships).
• Linked risks, evidence requirements and claims, assessments, monitors, indicators, exceptions, and findings, grouped on tabs.
• The control snapshot (structured posture detail).
• The two projections with their current values and the assessments or monitor runs that produced them.
• Activity history.

From any of these links you can navigate to the underlying record and back.

Every change is captured in the workspace Audit Log.

The two projections

The split between implementation and compliance matters for audit clarity:

• Implementation projection answers “is this control in place?” Implementation is binary-ish (in place, not in place, partial). It tells you about the existence of the safeguard.
• Compliance projection answers “is the control currently producing the intended outcome?” Compliance is the operational result. It tells you whether the safeguard is working.

A common audit story: a control was implemented six months ago (implementation = implemented) but recent monitoring detected drift (compliance = non-compliant). The two projections together tell that story. A single rolled-up status would lose the distinction.

Both projections reference an evaluation model, so the values aren’t hardcoded. Your organization defines the scale.

Common workflows

Registering a new control

1. Controls → New control. Pick a stable key, title, description.
2. Assign an owner (responsibility assignment).
3. Capture the implementation source in the control snapshot.
4. Go to Frameworks and add coverage links from relevant framework nodes to the new control.
5. Optionally link the control to scope nodes through Scope memberships.
6. Set up Monitoring or Assessments so the compliance projection has live signal.

Walking the library before an audit

1. Filter Controls by the framework in question (via coverage links).
2. Sort by compliance projection: non-compliant first, partially-compliant second.
3. For each non-compliant or partial control, check linked findings and remediation lifecycles.
4. Export the filtered list with projection columns for the auditor.

Retiring a control

1. From the control, set status to retired, providing a reason.
2. Existing assessments, evidence, and findings against the control remain visible for historical audits.
3. The control no longer appears in active selection lists.
4. If a replacement control exists, link them through a control snapshot field or a finding’s supersedes reference.

Looking for the API?

See Controls API reference for the v1 REST endpoints to list and inspect controls from an external system.

Related

• Frameworks - the requirements that controls implement.
• Obligations - the obligations that controls address.
• Risks - the risks that controls reduce.
• Evidence - the records that demonstrate a control is operating.
• Assessments - the engagements that evaluate a control.
• Monitoring - the rules that watch a control’s live posture.
• Findings - gaps and observations against a control.
• Exceptions - waivers from a control’s normal operation.