TLCTC · Evidence · CIS Controls v8.1 mapping

153 Safeguards. 74 objectives.

The full cell-by-cell mapping of every CIS Controls v8.1 Safeguard onto the TLCTC 10×6×2 matrix. The ≥60-objective reduction was a prediction. This is the count.

CIS Controls v8.1 (153 Safeguards, 18 Controls) · TLCTC 10×6×2 matrix · method & data below · CC BY 4.0

RESULTThe count cascade

Each CIS Safeguard was assigned the TLCTC cluster(s) whose generic vulnerability it acts upon, plus a Bow-Tie side (prevention / detection-response). Objectives are then counted at their true grain: (cluster, side, generic-strategy).

CIS count
153
Safeguards, each counted as one "control"
– Fail the floor
48
Pure enablers (inventory / process / governance) that act on no cluster — not control objectives
– De-duplicate
31
Repeated strategies & collapsed umbrella fragments hitting the same cell
Cell-pure objectives
74
Each granular enough to reach target-zero on one cell
Prediction confirmed

The blog forecast a reduction "on the order of 60 objectives." The mapping yields 153 → 74, a net reduction of 79 — the hypothesis holds, with margin. Two independent drivers produce it, pulling from opposite directions exactly as predicted.

DRIVER 148 Safeguards fail the granularity floor

Nearly a third of v8.1 acts on no cluster's generic vulnerability. These are inventories, processes, policies, and governance rows — they enable other controls but cannot themselves be measured to target-zero against any cause. Under the floor, they are not control objectives. Examples: 1.1 asset inventory, 3.1 data management process, all nine of Control 17 (Incident Response process rows), 16.1–16.3 dev-process rows, 18.1/18.3/18.4 pentest-program rows. Legitimate work — but not cause-acting controls.

DRIVER 234 Safeguards are umbrellas

These span more than one cluster and must de-aggregate. The classic case 7.4 Application patch management spans #2#3#10 — three causes, three velocity classes, one Safeguard. It cannot reach target-zero on any of them. After splitting, the fragments collapse into shared cells with other Safeguards (de-duplication), which is where the count comes back down.

SafeguardSpansWhy it's an umbrella
7.4#2#3#10App patching covers server-side, client-side, and third-party components
13.2 / 13.7#2#3#7Host IDS/IPS detects exploitation (server+client) and malware
8.11#1#4#7Log review spans abuse, identity, and malware indicators
2.5 / 2.6 / 2.7#1#7Allowlisting blocks both function-abuse and foreign code execution
5.4 / 6.8 / 3.3#1#4Access control acts on both abuse-of-function and identity
12.7#5#4VPN + AAA: anti-MITM transit and identity at once
13.9#8#4Port-level NAC: physical port control and identity
14.3 / 14.8#9 + #4/#5Awareness training folds social engineering with authn / transit

34 umbrellas total; representative rows shown. Full machine-readable mapping in the accompanying data file.

COVERAGEAll 20 cause/side coordinates are touched

A reassuring finding for CIS: v8.1 does reach every cluster on both Bow-Tie sides — there are no empty cells at the cluster level. The problem is not absence of coverage; it is that coverage is distributed without a cause axis to balance it. Look at the load:

Prevention (left of SRE)Detection–Response (right of SRE)
#1 Abuse of Functions128
#2 Exploiting Server197
#3 Exploiting Client94
#4 Identity Theft174
#5 Man in the Middle52
#6 Flooding Attack12
#7 Malware1211
#8 Physical Attack81
#9 Social Engineering92
#10 Supply Chain73

Cell values = number of Safeguard-fragments landing in that (cluster, side) coordinate after de-aggregation.

The imbalance the cause axis reveals

#2 Exploiting Server carries 19 preventive fragments. #6 Flooding Attack carries 1. #5 Man in the Middle carries 5. This is not a risk-weighted distribution — it is an artifact of where the control set historically accreted. CIS RAM's expectancy engine cannot even see this skew, because its commonality axis is asset-class frequency, not cause. The matrix surfaces it instantly: massive redundancy on server exploitation, near-singleton coverage on flooding and MITM.

READWhat this proves — and what it doesn't

It proves: (1) the ≥60 prediction was conservative — the real figure is 79; (2) the reduction is not deletion of capability but reclassification — 48 enablers move out of the objective count into a separate "enabling" register, and umbrella fragments de-duplicate into shared cells; (3) every cluster is already covered, so adoption is a re-anchoring, not a rebuild.

It does not prove: the exact strategy-grain assignment is canonical. Cell counts depend on how finely the six generic strategies are cut within a cluster. A different but reasonable strategy taxonomy would move 74 by a handful either way. The direction and magnitude are robust; the precise integer is mapping-dependent and should be ratified against the canonical TLCTC strategy set before publication.

Bottom line for CIS

You do not have a coverage gap. You have a resolution problem: 153 line items that mix 48 non-controls, 34 umbrellas that cannot reach target-zero, and a server-exploitation cluster carrying 19× the load of flooding. Re-anchor onto the matrix and the set resolves to 74 cause-pure objectives plus a clean enabling register — every objective measurable, every gap nameable, every redundancy visible. DoCRA stays on top, untouched.

Context: Why CIS Cannot Answer Your Cyber Threat Risk · the blind spot, visualized: What CIS Cannot See.

Mapping: 153 v8.1 Safeguards → 10×6×2 matrix. 153 → 74 objectives (−79). Strategy-grain assignment is illustrative and pending ratification against the canonical TLCTC strategy set.