Controls
Assign owners, set status and add comments
Controls are where compliance work actually happens. Each one is a requirement from an adopted framework, with an owner, a status, evidence and a history.
The control page
Requirement
The control text as published by the framework, its category, and the evidence
types it expects. Evidence types are marked required, recommended or
optional — required ones gate the control from passing.
Ownership
Assign an owner so the control has a name against it. Unowned controls are the
ones that quietly stay at not started for a quarter.
Status
Set the status as the work progresses:
| Status | When to use it |
|---|---|
Not started | No work done yet |
In progress | Being implemented |
Implemented | In place, evidence attached |
Not applicable | Out of scope, with a justification |
Alongside it sits the derived status, computed from evidence rather than set by
hand. It adds failing — an automated check exists and it says no — and
at risk, where evidence is missing or expired. When your status and the derived
one disagree, the derived one is the honest answer.
Internal controls
Framework controls from different standards often ask for the same thing. An internal control is your own single implementation, mapped to every framework control it satisfies, so ISO and SOC 2 asking for access reviews is one piece of work rather than two.
Evidence attached to an internal control counts for every framework control mapped to it.
Comments and activity
Comments are threaded on the control, which keeps the discussion next to the requirement. Activity records status changes, owner changes and evidence added or removed, with who did it and when — the trail an auditor asks for.
Working through a control set
Sorting by status and filtering by owner turns a 100-control framework into a short list per person. Two filters worth keeping:
- Needs evidence — implemented in practice, unproven on paper.
- At risk — evidence exists but has gone stale.