Appearance
Common Control Layer
A control is rarely one thing. It is usually several duties bundled into one record because they were written in one paragraph.
The Common Control Layer lets you address those duties individually.
Control elements
A control element is a single clause within a control, with its own normalised statement, its own kind, and its own evidence expectation.
Take a privileged access control:
"Privileged access is granted only through an approved request, is restricted to named individuals, is time-bound to 90 days, is reviewed quarterly, and is revoked immediately on termination."
That is five elements:
| Element | Kind |
|---|---|
| Granted only through an approved request | approval |
| Restricted to named individuals | restriction |
| Time-bound to 90 days | restriction |
| Reviewed quarterly | review |
| Revoked on termination | revocation |
Why elements matter
An obligation about revoking access on termination should map to the revocation clause, not to the whole control.
Mapping to the whole control asserts that everything in it addresses that obligation, which is untrue and produces two specific problems:
- Over-claimed coverage. The obligation looks addressed by a five-part control when only one part is relevant.
- Unclear evidence. What evidence proves the mapping? Evidence of quarterly reviews does not prove revocation on termination.
Element-level mapping fixes both. The mapping points at the revocation clause, and the evidence expected is evidence of revocation.
Element kinds
| Kind | What the clause does |
|---|---|
approval | Requires an authorisation before something happens |
restriction | Constrains who, what, when or how much |
review | Requires periodic examination |
revocation | Requires removal or withdrawal |
monitoring | Requires ongoing observation |
reconciliation | Requires comparison between two records |
reporting | Requires information to be provided to someone |
escalation | Requires a matter to be raised to a higher authority |
training | Requires people to be trained |
communication | Requires something to be communicated |
resourcing | Requires resources to be allocated |
oversight | Requires a governance body to supervise |
recordkeeping | Requires records to be created or retained |
remediation | Requires identified issues to be fixed |
other | None of the above |
The first six describe what an access or transaction control does. The governance kinds were added because a compliance charter, a board reporting line or a training mandate had no accurate word among them and everything organisational fell into other, carrying no information.
Elements and evidence
Each element can carry an evidence hint — what would demonstrate this clause operating.
| Element | Evidence hint |
|---|---|
| Granted only through an approved request | Approval records for each grant in the period |
| Time-bound to 90 days | Expiry configuration and a report of grants exceeding 90 days |
| Reviewed quarterly | Completed recertification per in-scope system |
| Revoked on termination | Reconciliation between HR terminations and access removals |
Writing these is the fastest route to a realistic expected evidence set, because it forces the question: what would actually prove this?
Element lineage
Elements extracted from a source document carry lineage back to the text they came from, so a reviewer can see the original wording alongside the normalised statement.
Elements have their own status and version, so a clause can be revised without rewriting the whole control.
When to use elements
| Situation | Use elements? |
|---|---|
| A control with several distinct duties | Yes |
| One obligation maps to one clause of a multi-clause control | Yes |
| A single-purpose control | No — element decomposition adds nothing |
| A control you are about to split into several controls anyway | Split the control instead |
Elements are not a substitute for splitting a control
If two clauses have different owners, different frequencies and different evidence, they are probably two controls, not one control with two elements. Elements are for clauses that genuinely belong to one operational control.
Permissions
| Action | Permission |
|---|---|
| View control elements | mapping.read |
| Propose a mapping to an element | mapping.propose |
| Approve an element-level mapping | mapping.review |
Example
Control CTL-2026-0044 — Privileged Access Management, five elements.
Three obligations from two frameworks map to it:
| Obligation | Maps to | Relationship |
|---|---|---|
| "Privileged access shall be approved by the system owner" | Element 1, approval | equivalent |
| "Access rights shall be reviewed at planned intervals" | Element 4, review | subset — covers the planned interval, not change of employment |
| "Access shall be removed promptly on termination" | Element 5, revocation | equivalent |
The second mapping is subset at the element level, which is far more informative than a whole-control mapping would be. It says precisely which part of the obligation the element covers, and by implication which part is still unaddressed — change of employment other than termination.
That gap became a finding, and a sixth element was added to the control covering role changes.
Troubleshooting
"I cannot see elements on a control." The control may have none. Elements are created by extraction or added deliberately; not every control has them.
"An element mapping does not appear in the SoA." Only approved mappings appear, whether they target a control or an element.
"Elements duplicate what our control descriptions already say." That is expected. Elements do not replace the description; they make its clauses individually addressable.