The atomic scoring unit
The Containment Lattice
Response does not vary meaningfully per ATT&CK technique — you isolate a compromised laptop the same way whether the adversary arrived via T1566 or T1190. It varies by where on the attack path you are, and what kind of asset you are acting on.
TID-CMM scores coverage against in-scope ATT&CK techniques. That is the right unit for detection, because detection logic is written per behaviour. It is the wrong unit for response. The atomic unit of TIR-CMM is therefore a lattice cell: one attack-path stage crossed with one asset class.
A cell carries three things — a criticality tier inherited from the crown-jewel mapping, a Response Readiness Status from 0 to 3, and an expiry date. Together they produce the Validated Response Score, the engineered-versus-proven gap, and the blind-cell list.
Attack-path stages — the rows
Eight stages, collapsed from ATT&CK tactics into the boundaries at which a different response decision is available. S0 — Prevent & Harden is new in v0.2 and is scored first, ahead of every response stage.
| ID | Stage | Response question | ATT&CK tactics folded in |
|---|---|---|---|
| S0 | Prevent & Harden New in v0.2 | Can architecture stop it, or materially slow it, before response is needed? | ATT&CK Mitigations (M-codes); D3FEND Harden |
| S1 | Initial Access & Foothold | Can we cut the entry before execution? | Initial Access, Resource Development |
| S2 | Execution & Persistence | Can we kill and prevent return? | Execution, Persistence, Defense Evasion |
| S3 | Privilege Escalation & Credential Access | Can we revoke and re-trust at speed? | Privilege Escalation, Credential Access |
| S4 | Discovery & Lateral Movement | Can we sever the path mid-flight? | Discovery, Lateral Movement |
| S5 | Collection & Staging | Can we interrupt before the data moves? | Collection |
| S6 | Command & Control and Exfiltration | Can we block egress and channel? | C2, Exfiltration |
| S7 | Impact & Objective | Can we limit, reverse and restore? | Impact |
Stage leverage
Containing early is worth more than containing late. The leverage coefficient λ is used in
prioritisation, where a cell’s impact is
ω(c) × λ(stage) × (3 − RRS(c)) × 100.
| Stage | S0 | S1 | S2 | S3 | S4 | S5 | S6 | S7 |
|---|---|---|---|---|---|---|---|---|
| Leverage λ | 1.6 | 1.5 | 1.4 | 1.3 | 1.2 | 1.0 | 1.0 | 0.8 |
Why S0 carries the highest leverage
S0 — Prevent & Harden asks a question no other row can: whether architecture or controls blunt the behaviour before a response is needed at all. It carries λ = 1.6, above every response stage, and the reason is arithmetic rather than rhetorical. Every other stage improves the odds of winning a race that has already started. S0 shortens the race, or stops it being run.
Prevention buys the one thing response cannot manufacture, which is time.
A model that scored only response would systematically undervalue the control that removed the incident, and would rank a marginal playbook improvement above a hardening change that made the playbook unnecessary. That is the opposite of the behaviour the model should encourage, and it is why prevention now sits inside the lattice rather than beside it.
S0 maps to ATT&CK Mitigations (M-codes) and to D3FEND’s Harden tactic, so a preventive control inventory already expressed in either vocabulary drops into the row without translation. It is scored on the same Response Readiness Status scale as every other cell: a status-3 S0 cell means the hardening is demonstrably in place and has been shown to work, not that a standard says it should be.
Why S7 carries the lowest
S7 is weighted lowest not because impact response is unimportant, but because by S7 the model is measuring damage limitation rather than defence. An organisation whose entire response capability is concentrated at S7 is running a disaster recovery function and calling it incident response — the leverage weighting surfaces this automatically.
The same weighting produces a counter-intuitive but correct result in the roadmap: a status-0 cell at S1 on a Tier-0 identity asset outranks a status-2 cell at S7 on a peripheral system, even though the latter feels more urgent during an incident.
Asset classes — the columns
Eight classes, derived from the “what you run” and “what you protect” steps. Classes not present in the environment are excluded entirely.
| ID | Asset class | Typical containment primitives |
|---|---|---|
| A1 | Identity & Access Infrastructure (Tier-0: AD, Entra ID, IdP, PAM) | Disable, revoke session/token, force re-auth, break trust, tier-isolate |
| A2 | Endpoint & User Compute | EDR network-isolate, kill process, quarantine, reimage |
| A3 | Server & Datacentre Workload | Isolate, snapshot, quiesce, failover, rebuild |
| A4 | Cloud Control Plane & SaaS | Revoke key/role, quarantine principal, disable API, tenant restrict |
| A5 | Network & Edge (VPN, firewall, proxy, DNS, email gateway) | Block, sinkhole, ACL, disable tunnel, quarantine mail |
| A6 | Application, Source & CI/CD | Freeze pipeline, revoke signing key, roll back release, disable webhook |
| A7 | Data Stores & Backup | Restrict access, immutable snapshot, restore, integrity verify |
| A8 | OT / ICS / IoT / Specialist | Segment, safe-state, manual fallback (scoped in only where applicable) |
Scoping and sizing
Maximum lattice: 8 × 8 = 64 cells. This is deliberately never the working set.
A cell is in scope only when both conditions hold:
- The asset class exists in the environment, as declared in step 1 of the assessment; and
- At least one modelled attack path — imported from TID-CMM or declared locally — traverses that stage on that asset class.
Typical in-scope lattice: 24–38 cells. A cell outside scope is marked N/A and excluded from both numerator and denominator, exactly as TID-CMM handles N/A sub-capabilities — no penalty, no benefit.
This is the mechanism that keeps the assessment inside the one-hour promise while giving the model far richer output than a flat questionnaire.
Cell criticality tiers
Each in-scope cell inherits a tier from the crown-jewel mapping.
| Tier | Meaning | Weight ω |
|---|---|---|
| T1 | The cell is a crown jewel, or directly hosts one | 3 |
| T2 | The cell lies on a modelled attack path to a crown jewel | 2 |
| T3 | In scope, but peripheral to crown-jewel paths | 1 |
Response Readiness Status
Each in-scope cell carries a status from 0 to 3, deliberately identical in shape to TID-CMM’s validated-coverage status, so the two lattices read the same way.
| Status | Name | Definition |
|---|---|---|
| 0 | No option | No means exists to act at this stage on this asset class. You would improvise or watch. |
| 1 | Manual only | An action is technically possible but is ad-hoc, undocumented, dependent on a specific individual, or gated behind an approval path with no defined SLA. |
| 2 | Engineered | A documented, parameterised playbook exists; tooling can execute it; an owner is named; authority to execute is defined in advance. Unproven. |
| 3 | Proven | Executed against a real incident or a live-fire exercise within the recency window, and it met its stage time objective, and the blast radius was as designed. |
The gap between the engineered rate (cells at status 2 or better — “we believe we can act here”) and the proven rate (cells at status 3 — “we have shown we can act here”) is the headline finding the lattice is built to make unavoidable rather than to flatter.
Status 3 expires
TID-CMM expires validation at eighteen months. TIR-CMM expires at twelve months, because response capability rests on people and authority, and organisations change those faster than they change detection logic.
A cell reverts from 3 to 2 on any of the following:
- Twelve months elapsed since last proof
- Change of the tooling that executes the action (EDR swap, SOAR migration, IdP change)
- Change of the on-call or escalation model
- Reorganisation of the response function, or departure of the named owner
- Material architecture change affecting that asset class
- Change of the managed provider or retainer delivering the action
Response maturity is perishable in a way detection maturity is not. This expiry rule is the single most important honesty mechanism in the model.
A worked lattice
The model’s numerical validation was executed against “Meridian Group,” a fictional mid-size European financial services organisation of roughly 9,000 staff with a competent but optimistic security team: good preparation, real detection engineering investment, a well-regarded SOAR deployment, tabletop exercises — and no live-fire, no measured decision latency, nothing signed on containment authority. This is the most common profile in the market.
Thirty-two cells fall in scope, inside the 24–38 design band. The OT/ICS column is excluded entirely: the asset class does not exist in the environment. Four of the thirty-two are the new S0 Prevent row, which is why the total moved from 28 in v0.1.
Containment Lattice — Meridian Group
32 in-scope cells · VRScj 45.5% · engineered rate 40.6% · proven rate 3.1%
| Attack-path stage | Identity | Endpoint | Server | Cloud/SaaS | Network | App/CI-CD | Data/Backup |
|---|---|---|---|---|---|---|---|
| S0 Prevent | |||||||
| S1 Initial Access | |||||||
| S2 Execution | |||||||
| S3 Priv-Esc | |||||||
| S4 Lateral | |||||||
| S5 Collection | |||||||
| S6 C2 & Exfil | |||||||
| S7 Impact |
Table view of the same 32 cells
| Cell | Stage | Asset class | Tier | ω | RRS | Status |
|---|---|---|---|---|---|---|
| S0×A1 | Prevent & Harden | Identity & Access Infrastructure | T1 | 3 | 1 | Manual only |
| S0×A2 | Prevent & Harden | Endpoint & User Compute | T2 | 2 | 2 | Engineered |
| S0×A5 | Prevent & Harden | Network & Edge | T2 | 2 | 2 | Engineered |
| S0×A7 | Prevent & Harden | Data Stores & Backup | T1 | 3 | 1 | Manual only |
| S1×A1 | Initial Access & Foothold | Identity & Access Infrastructure | T1 | 3 | 1 | Manual only |
| S1×A2 | Initial Access & Foothold | Endpoint & User Compute | T2 | 2 | 2 | Engineered |
| S1×A4 | Initial Access & Foothold | Cloud Control Plane & SaaS | T3 | 1 | 1 | Manual only |
| S1×A5 | Initial Access & Foothold | Network & Edge | T3 | 1 | 2 | Engineered |
| S2×A1 | Execution & Persistence | Identity & Access Infrastructure | T1 | 3 | 1 | Manual only |
| S2×A2 | Execution & Persistence | Endpoint & User Compute | T2 | 2 | 3 | Proven |
| S2×A3 | Execution & Persistence | Server & Datacentre Workload | T2 | 2 | 2 | Engineered |
| S2×A6 | Execution & Persistence | Application, Source & CI/CD | T3 | 1 | 0 | No option |
| S3×A1 | Privilege Escalation & Credential Access | Identity & Access Infrastructure | T1 | 3 | 0 | No option |
| S3×A2 | Privilege Escalation & Credential Access | Endpoint & User Compute | T2 | 2 | 2 | Engineered |
| S3×A3 | Privilege Escalation & Credential Access | Server & Datacentre Workload | T3 | 1 | 1 | Manual only |
| S3×A4 | Privilege Escalation & Credential Access | Cloud Control Plane & SaaS | T3 | 1 | 1 | Manual only |
| S4×A1 | Discovery & Lateral Movement | Identity & Access Infrastructure | T1 | 3 | 1 | Manual only |
| S4×A2 | Discovery & Lateral Movement | Endpoint & User Compute | T2 | 2 | 2 | Engineered |
| S4×A3 | Discovery & Lateral Movement | Server & Datacentre Workload | T3 | 1 | 1 | Manual only |
| S4×A4 | Discovery & Lateral Movement | Cloud Control Plane & SaaS | T3 | 1 | 1 | Manual only |
| S4×A5 | Discovery & Lateral Movement | Network & Edge | T2 | 2 | 2 | Engineered |
| S5×A2 | Collection & Staging | Endpoint & User Compute | T3 | 1 | 1 | Manual only |
| S5×A3 | Collection & Staging | Server & Datacentre Workload | T3 | 1 | 1 | Manual only |
| S5×A7 | Collection & Staging | Data Stores & Backup | T1 | 3 | 1 | Manual only |
| S6×A2 | Command & Control and Exfiltration | Endpoint & User Compute | T2 | 2 | 2 | Engineered |
| S6×A4 | Command & Control and Exfiltration | Cloud Control Plane & SaaS | T3 | 1 | 1 | Manual only |
| S6×A5 | Command & Control and Exfiltration | Network & Edge | T2 | 2 | 2 | Engineered |
| S6×A7 | Command & Control and Exfiltration | Data Stores & Backup | T1 | 3 | 1 | Manual only |
| S7×A1 | Impact & Objective | Identity & Access Infrastructure | T1 | 3 | 1 | Manual only |
| S7×A3 | Impact & Objective | Server & Datacentre Workload | T2 | 2 | 2 | Engineered |
| S7×A6 | Impact & Objective | Application, Source & CI/CD | T3 | 1 | 0 | No option |
| S7×A7 | Impact & Objective | Data Stores & Backup | T1 | 3 | 2 | Engineered |
One blind Tier-1 cell falls out of the grid: S3 × A1 — privilege escalation and credential access on identity infrastructure, with no response option at all. It is a stage on a crown jewel where the organisation would improvise or watch. Under R6 — the Blind-Cell Gate, that single cell caps the reported band at L2 on its own, regardless of the decimal score.
The engineered-versus-proven gap — 40.6% against 3.1% — is the response analogue of TID-CMM’s 48.9% against 12.7%, and is proportionally wider. That is the expected and intended result, since response capability is rehearsed far less often than detection logic is exercised.
Adding the S0 Prevent row widened the gap rather than narrowing it, which is worth noticing. Meridian has hardened its endpoint and network estate to engineered, but its identity and backup estates — the two crown-jewel classes — sit at manual only. Prevention, like response, has been built where it was easy rather than where the crown jewels are.
Meridian’s tempo makes the same point arithmetically: breakout 62 minutes against MTTD 180 + MTTDecide 95 + MTTC 40 = 315 minutes. Containment Margin −253 minutes. Tempo Ratio 5.08. R5 fires and caps the band at L1 — against a self-assessed 2.69 that would have read L2 and, in most maturity models, been reported as “approaching level 3.”
The mechanical roadmap that follows puts live-fire exercising first, the blind identity cell second, decision-latency measurement third, exercise timing capture fourth and persistence on identity infrastructure fifth. Not one of the top five is a product purchase, and three of the five are things this organisation believed it already had.