Control Management

The Control Scoping section is where you select which SCF controls apply to your organization, track their implementation progress, and assess maturity. This is the foundation of your compliance program.

Accessing Control Scoping

Click Control Scoping under Controls & Frameworks in the sidebar.

The Control Scoping Interface

Control Scoping uses the same two-screen pattern as the rest of the platform: a full-width list, then a full-width detail page for the control you pick.

The list

A collapsible filter sidebar down the left, a toolbar above the list, and the controls themselves filling the width. The list is virtualised, so it stays responsive across the whole catalogue.

• Filter sidebar — scope, domain, NIST CSF function, control weight, framework, business function, owning team and accountable owner
• Toolbar — search by control ID, name or description, plus the in-scope count
• Scope by Framework — opens a modal where you pick frameworks to bulk-scope their controls
• Rows — each shows the selection checkbox, control ID, name, status badge, maturity and domain
• Selection bar — appears once you tick one or more rows. It applies Set maturity (L0–L5) or Set status to the whole selection in a single operation, and assigns an owning team. It does not change what is in scope — use Scope by Framework, or a control’s own scope checkbox, for that

The detail page

Click a row to open the control full-width, with a breadcrumb back to the list and ←/→ to step through neighbouring controls. It shows:

• Control header — ID, name, domain, theme, and type
• Control Details section — Description, policy standard, implementation guidance, testing procedure
• Maturity Roadmap — Visual roadmap showing the path from current maturity to target level
• Business Size Guidance — Tailored implementation recommendations based on your organization size
• SCRM Focus Badges — Supply chain risk management relevance indicators
• Risk & Threat Context — Related risks and threat scenarios linked to this control
• Implementation Tracking section — All the fields you can configure
• Audit Artifacts section — Evidence items required by this control
• Framework Mappings section — Which frameworks this control satisfies
• Audit Log — Field-level change tracking showing who changed what and when
• Comments — Threaded discussion for team collaboration

Selecting Controls for Scope

Individual Selection

1. Click the checkbox on any control card to toggle its selection
2. Or open a control and check “Include this control in scope”

Scope by Framework

The Scope by Framework button opens a modal listing all 260+ supported frameworks. Select one or more frameworks to automatically scope every control mapped to them. This is the fastest way to build your initial control scope.

Framework-Based Scoping

Use Scope by Framework for your primary compliance target (e.g., ISO 27001), then refine with the framework filter in the sidebar to review specific subsets.

Tracking Implementation

For each scoped control, you can track:

Implementation Status

Status	When to Use
Not Started	Control is scoped but no work has begun
In Progress	Implementation work is underway
Implemented	Control is fully operational
Ready for Review	Implementation is complete and awaiting audit or peer review
Monitored	Control is implemented and under active monitoring
At Risk	Implementation is delayed or has issues
Not Applicable	Control doesn’t apply to your environment
Deferred	Intentionally postponed to a future date

Priority

Set the implementation priority:

• Critical — Must be addressed immediately
• High — Should be completed soon
• Medium — Normal priority
• Low — Can be addressed when resources allow

Maturity Level

Assess how mature your control implementation is. The Maturity Roadmap in the detail panel visualizes your current level and the path to your target.

Level	Name	Description
L0	Incomplete	No process or ad-hoc activity
L1	Initial	Ad-hoc, inconsistent processes
L2	Developing	Repeatable but undocumented
L3	Defined	Documented and standardized
L4	Managed	Monitored and measured
L5	Optimized	Continuously improving

Ownership

Ownership is recorded in three places, on two different tabs of the detail panel. They do different jobs and none of them replaces another:

Field	Where	What it records
Owner Team Label	Details tab	A free-text label from a per-organisation list in Settings. A name, and nothing more.
Owning teams	Assignments tab	Your organisation’s real teams, one of them accountable. The durable ownership record.
Your Assignments	Assignments tab	The individual people currently doing the work, via the Assignment Picker.

Owner Team Label is a label; owning teams are teams

The free-text dropdown still exists and still behaves exactly as it always has — your existing values are untouched. Only its name changed, from Owner Team to Owner Team Label, so the two can be told apart. The helper text under it now says so directly:

A free-text label from your organisation’s settings. It records a name only — it is not one of the teams under Users → Teams. To record which real team owns this control, use “Owning teams” on the Assignments tab.

Owning teams are the other thing entirely: teams defined once in User Management, with members, a primary, a delegate and a function. The two are independent — they can disagree, and neither corrects the other. Nothing converts one into the other, and no migration guesses which label meant which team.

Treat owning teams as the source of truth for who owns a control, and the label as a note that stays until your organisation has finished moving off it.

Teams and people answer different questions, which is why both exist on the Assignments tab. A team outlives its members, so it still owns the control after the person who set it up has left; the Assignment Picker names who is doing the work right now. Neither implies the other.

Assigning Teams to a Control

Team assignment answers two different questions at once: which teams work on this? and who is answerable for it?

1. Open the control, go to the Assignments tab, and find Owning teams below the assignment picker
2. Pick a team from the Select a team… dropdown and click Add team
3. Repeat for every team that genuinely owns part of this control
4. Select the Accountable radio button on exactly one of them

Adding a team never makes it accountable — that is a separate, deliberate click. A control you have not saved yet shows Save control to enable assignment instead; save it first.

The radio button is the whole point of the control: a radio, not a checkbox, because exactly one team can hold it. Selecting it on a second team moves the marker off the first immediately. There is no confirmation step and no error, because nothing has gone wrong — accountability moved, which is a normal thing for it to do.

A control may have any number of owning teams. Shared work is normal — a control can rely on IT Operations to build something, Security Operations to monitor it and GRC to evidence it — and recording only one of those teams makes the register a fiction.

Exactly one team is accountable. Accountability is the answer an auditor asks for by name: when this control fails, whose name is on it? Shared ownership with nobody accountable is one of the most common findings against a control register, because every team assumes another team had it. The platform allows at most one accountable team per control, so the answer can never be ambiguous.

A control with teams assigned but none accountable shows a No accountable team badge beside the Owning teams heading, which explains itself on hover: “Teams own this control but none is accountable, so nobody is answerable for it. Mark one accountable when you know which.”

The badge appears only when at least one team owns the control and none is accountable. A control that no team owns gets no badge at all — it shows No teams own this control yet instead. That distinction is worth knowing: the badge means an ownership decision was started and left unfinished, not that the control is unowned.

Either state is allowed. Assigning teams and deciding accountability are separate acts, and blocking on the second would only push people into marking whoever happens to be first in the list. The badge is advisory — it blocks nothing — and it is the same badge, deliberately, as the team health warnings in User Management. Treat it as a to-do item to resolve before an audit rather than during one.

To hand accountability over, make a different team accountable; the marker moves in one step. To end a team’s involvement altogether, click Remove — that removes it from this control only, and does not touch the team, its members, or its assignments elsewhere.

Removing the team that was accountable leaves the control owned by the others with nobody accountable, and the badge comes back. Accountability is never quietly inherited by whichever team happens to remain — handing it over is always a decision somebody makes, not a side effect of a deletion.

Who can change assignments

Adding teams, changing accountability and removing teams require the Admin role, the same as managing the teams themselves. Any member of the organisation can see which teams own a control; non-admins see the accountable team as a plain Accountable pill with no radio buttons, and the note “Only organisation admins can change which teams own this control.”

Filtering by Team and Function

In the filter sidebar, below the existing domain, framework and control weight selects, are two more:

• All Functions — show the controls owned by any team delivering that business function
• All Teams — show the controls one team owns

The distinction matters in a federated organisation. Filter by the team EMEA Security Operations and you see that team’s controls; filter by the function Security Operations and you see the controls owned by every security operations team you have, EMEA and APAC alike. Day-to-day work happens at the team level; coverage questions happen at the function level.

The two work together. Choosing a function narrows the team list to that function’s teams, and clears a team already chosen from a different one — “Legal” plus “Service Desk” is a pair that could only ever return nothing, so the filters do not let it stand.

Both filters match any owning team, not only the accountable one: a team that owns a control still owns it when another team is answerable for it. Controls that no team owns drop out of the results while a filter is active — they are excluded, not listed as unowned.

A third select sits with them, All Owner Types, which narrows the list by whether the accountable team is led by an external contractor — Contractor-owned — or by permanent staff — Internally owned. Note the narrower question: the team and function filters above match any owning team, while this one reads the accountable team’s primary owner only, so a control a contractor-led team was merely consulted on does not appear under Contractor-owned. Contractor status is recorded per organisation on each membership and grants nothing; see Internal Members and External Contractors.

Both filters are applied by the server across your whole catalogue, not just the controls currently on screen, and the count beside the list reflects the filtered set. The stats header above it stays organisation-wide — the two are answering different questions, not disagreeing.

One consequence worth knowing: a team filter returns only controls you have scoped. A control you have never brought into scope has nothing for a team assignment to attach to, so it cannot match a team and drops out. Filtering by team therefore narrows your scoped controls rather than the full catalogue.

Each card in the control list also shows the team accountable for it, together with that team’s primary — Security Operations (Ana Ruiz) — or the delegate if the team has no primary, or the team name alone if it has neither. Where nobody has been named, the card reads No accountable team, so an unowned control is visible while scanning the list rather than only after opening it.

Dates and Notes

• Completion Date — Target or actual completion date
• Selection Reason — Document why this control was selected
• Implementation Notes — Describe how the control is implemented

Related Documentation

Link to policies, procedures, or other documents:

1. Click + Add Document
2. Enter a Document ID (e.g., “POL-001”)
3. Optionally add a URL to the document
4. Click the ✕ button to remove a document

Seeing where the gaps are

Coverage analysis lives on the Dashboard, not on the scoping screen. Expand a framework’s Show Gap Analysis panel there and you get:

Gap by Domain

See how many controls are selected vs. total for each control domain (Access Management, Data Security, etc.). A checkmark (✓) means full coverage; a number shows the gap.

Gap by Control Theme

Analyze coverage by theme:

• Protect — Preventive controls
• Detect — Monitoring and detection
• Respond — Incident response
• Recover — Business continuity

Gap by Control Type

Coverage breakdown by control type:

• Technical — Technology-based controls
• Administrative — Policy and procedure controls
• Physical — Physical security controls

Viewing Audit Artifacts

The Audit Artifacts section shows evidence items required by the selected control:

• Tracking status — ✅ (tracked) or ⚪ (not tracked)
• Artifact ID — Unique identifier
• Artifact title — Description of the evidence
• Collecting system — System responsible for collecting this evidence (if tracked)

Artifacts are grouped by domain for easier navigation.

Note

To actually track and collect evidence, use the Evidence Workspace section.

Viewing Framework Mappings

The Framework Mappings section shows which compliance frameworks this control satisfies and the specific requirement references (e.g., “A.9.1.1” for ISO 27001).

This helps you understand the compliance value of each control—controls mapped to many frameworks provide broader coverage.

Collaboration Features

Assignments

If the control has been saved to the database, you can assign team members using the Assignment Picker. This assigns individual people to the control and is separate from the owning teams — one names who is doing the work right now, the other names which team owns it regardless of who is currently on that team.

Audit Log

The Audit Log panel provides field-level change tracking for every scoped control. Each entry records:

• Which field was changed
• Previous and new values
• Who made the change
• Timestamp

This gives your audit team a complete history of implementation decisions without relying on external tracking.

Comments

The comment thread supports threaded discussions for implementation decisions, questions, and approvals. Comments support:

• Threaded replies
• @mentions (if configured)
• Timestamp tracking

Auto-Save

All changes are automatically saved as you make them. You’ll see a ”💾 Saving…” indicator briefly appear when changes are being persisted.

---

Best Practices

Initial Scoping

1. Start with a framework — Use “Scope by Framework” to select your primary compliance target
2. Review and refine — Deselect controls that don’t apply to your environment
3. Check Business Size Guidance — Review the tailored recommendations for each control

Ongoing Maintenance

1. Update status regularly — Move controls through statuses as work progresses (In Progress, Implemented, Ready for Review, Monitored)
2. Document as you go — Add implementation notes when completing work
3. Use completion dates — Track actual vs. planned completion
4. Assess maturity — Use the Maturity Roadmap to track L0-L5 progression
5. Review the Audit Log — Check change history before audits to ensure accuracy

Team Coordination

1. Assign ownership — Every scoped control should have an owner team
2. Use comments — Discuss implementation approaches in the comments
3. Link documentation — Connect controls to policies and procedures

---

Related Guides

• Dashboard Overview — See aggregated control metrics
• Evidence Management — Track evidence for controls
• Control Library — Browse all available controls