# TIR-CMM

## Threat-Informed Response Capability Maturity Model

**Model Specification v0.2 (draft for review)**
**Date:** 17 August 2026
**Status:** Design draft — not yet published
**Author:** Reza Adineh
**Position:** Response module of UTIOM (Unified Threat-Informed Operations Model). Companion and successor-in-scope to TID-CMM (Threat-Informed Detection Capability Maturity Model).
**Proposed licence:** Model CC-BY-4.0 · Tooling Apache-2.0 (identical to TID-CMM)

---

## 0. Reader's map

| Section | What it settles |
|---|---|
| 1 | Why the model exists — the three response failure modes |
| 2 | Where it sits inside UTIOM and how it bonds to TID-CMM |
| 3 | The Containment Lattice — the atomic scoring unit |
| 4 | The two headline metrics: VRS and Containment Margin |
| 8.4.1 | The prerequisite check — running TIR-CMM without TID-CMM |
| 5 | Maturity bands L0–L5 |
| 6 | The eight domains and 58 sub-capabilities |
| 7 | Scoring mathematics |
| 8 | Integrity constraints R1–R5 |
| 8A | Readiness lenses — respond, recover, withstand |
| 9 | Prioritisation, the blueprint and roadmap generation |
| 10 | Standards crosswalk |
| 11 | The TID-CMM bridge — resolving the IR domain overlap |
| 12 | Assessment flow (ten steps) |
| 13 | Data model and interop contract |
| 14 | Open questions for v0.2 |

---

## 0A. What changed in v0.2

v0.2 responds to two things: a review of the UTIOM-ORR blueprint and its companion workbook, and the plain observation that v0.1 was too heavy to start with.

### The complexity problem, and the fix

The blueprint's workbook is a genuinely good assurance instrument — 180 evidence-led questions, 697 ATT&CK rows, 106 telemetry components, a 999-row gap register. Counted honestly, that is **4,350 input cells properly scoped and 14,300 as shipped: between one and four working days of pure data entry**, before the evidence interviews, second-reviewer calibration and exercised scenarios the method rightly demands. That is a legitimate two-to-four week engagement. It cannot be the front door.

v0.1 was better at ~177 cells, but still an hour or two. Nobody self-serves into that either.

**The fix is tiering, not simplification.** One model, three depths, each a strict superset of the one below, so nothing is ever rescored:

| Tier | Time | Covers | Band ceiling |
|---|---|---|---|
| **Pulse** | 20 minutes | 20 questions, no lattice, no evidence levels | **L3** |
| **Baseline** | 1–2 hours | All 58 sub-capabilities with evidence levels, the lattice, authority map, tempo | **L4** |
| **Assurance** | 2–4 weeks | Adds telemetry attributes, exercised scenarios, the evidence register and the governance layer | none |

The ceiling is not a punishment. **The depth an assessment reaches is itself evidence** about how far its result can be trusted, and the model already expresses that idea everywhere else. Twenty questions cannot evidence a claim of adaptive maturity, however good the answers are.

Pulse deliberately does not ask for evidence levels at all. Asking a twenty-minute assessment to grade its own evidence would defeat the point; its L3 ceiling carries that weight instead.

### Adopted from the blueprint

| Change | Detail |
|---|---|
| **Evidence 0–3 replaces the binary flag** | VC0 caps at 1, VC1 at 2, VC2 at 4, VC3 at 5 — aligned to TID-CMM's Validated Coverage so an imported grade sets the ceiling directly. R3 is now a cap rather than a demotion of 4s and 5s. The cap is a **ceiling, not a conversion**: a high evidence grade permits a high score, it does not create one. A blank level is treated conservatively as VC0. |
| **S0 Prevent added to the lattice** | Ahead of S1, carrying the highest stage leverage (λ 1.6), because prevention buys the one thing response cannot manufacture, which is time. The lattice is now 8 × 8 = 64 maximum cells. |
| **Scenario validation protocol** | 12 starter scenarios, 10 lifecycle stages each, pass conditions, minimum scenario record. A scenario passes only when every stage is above 1, it was exercised, the exercise was **timed**, and observed recovery met its target. An untimed exercise cannot lift a readiness claim. |
| **Telemetry attributes** | The eight attributes — collection, completeness, timeliness, integrity, retention, queryability, health, protection — scored **per asset class** rather than per ATT&CK data component. Telemetry health is a property of a platform, not of a log type, and 106 data components is the single largest cost in the workbook for very little added signal. |
| **Governance layer** | Eight assurance conditions, the ten calibration questions, decision rights, RACI, anti-gaming rules, board reporting rules and publication cautions. |

### New constraint

**R7 — Assessment depth and governance ceiling.** Pulse caps at L3; Baseline caps at L4; and at Assurance depth, a result without evidence-led scoring, independent calibration and separation of assessor from approver is a self-assessment and caps at L4. Useful, but it must not be presented as assurance.

### Where TIR-CMM diverges from the blueprint, deliberately

1. **Detect is not weighted at 20%.** The blueprint gives Detect the highest of its eight lifecycle-stage weights, in a module that by design sits downstream of a detection assurance model. That double-counts TID-CMM and lets a strong detection score inflate a response result — precisely the lifecycle asymmetry the module exists to expose. TIR-CMM has no detection domain at all; detection enters solely as constraint R4.

2. **Critical gates stay rare.** The workbook flags 102 of 180 questions as critical gates. When 57% of questions can independently fail an assessment, the gate stops being a signal. TIR-CMM's band gates are R5, R6 and R7 — three, each with a distinct and defensible trigger.

3. **Validation is not weighted at 5%.** The blueprint opens its scenario section with "questionnaires reveal claims; scenarios reveal integration" and then weights Validate lowest of the eight. TIR-CMM inverts that: RV carries 14% and, through R1, sets the ceiling for every other domain.

### Worked example under v0.2

| | v0.1 | v0.2 |
|---|---|---|
| Self-assessed | 2.69 | 2.69 |
| Constraint-adjusted | 2.35 | **2.32** |
| Proven rate | 3.6% | **3.1%** |
| Lattice cells in scope | 28 | **32** |
| R3 firings | 3 | **6** |
| Reported band | L1 | L1 |

The graduated evidence levels catch twice as many overstated scores as the yes/no flag did, and the movement remains modest rather than theatrical — which is the intended behaviour.

---

## 1. The problem TIR-CMM exists to solve

TID-CMM asks one honest question — *"would we actually see it?"* — and produces one uncomfortable number: an organisation claiming 48.9% detection coverage can prove only 12.7%.

TIR-CMM asks the question that follows, and it is not *"do you have playbooks."* It is:

> **Could we actually stop it — inside the adversary's breakout window, with someone permitted to pull the trigger, at the blast radius we intended — and can you prove it?**

Three failure modes, structurally parallel to TID-CMM's three:

| TID-CMM's failure mode | TIR-CMM's parallel |
|---|---|
| **Coverage without visibility** — rules exist and map to techniques, but the data source is absent or degraded | **Playbooks without authority** — the procedure exists and is well written, but nobody may execute it at 03:00 |
| **Detection without threat modelling** — content comes from generic subscriptions, not an organisation-specific adversary profile | **Response without attack paths** — a generic IR plan, not derived from this organisation's crown jewels and modelled paths |
| **Capability without evidence** — detection assumptions remain untested until a breach tests them | **Capability without rehearsal** — playbooks and automation are never executed against a clock |

### 1.1 Playbooks without authority

The procedure exists. It is well written. At 03:00 on a Sunday, the analyst who could execute it is not permitted to isolate a production domain controller, and the person who is permitted is asleep and unreachable for forty minutes. The playbook was never the constraint. **Decision latency is the most under-measured variable in incident response**, and it is invisible to every maturity model currently in use.

### 1.2 Response without attack paths

The IR plan is a generic NIST-shaped document: prepare, detect, contain, eradicate, recover, learn. It is not derived from this organisation's crown jewels, this organisation's modelled attack paths, or this organisation's priority adversaries. It tells you *how to run an incident* and nothing about *which incidents you are structurally unable to stop*. UTIOM's Law 3 — crown jewels drive resource allocation — is violated the moment response is planned generically.

### 1.3 Capability without rehearsal

Playbooks are written, automation is built, and neither is ever executed against a clock. Tabletop exercises test the conversation, not the capability. An unrehearsed playbook is an assumption wearing a document's clothing. The failure surfaces exactly once, under maximum cost.

### 1.4 The consequence

Organisations invest in detection maturity while remaining structurally unable to act on what they detect. TID-CMM makes visibility honest. Without a matching instrument, response remains the last unmeasured link — and a validated detection that fires into an organisation that cannot contain is a very expensive alarm.

---

## 2. Position within UTIOM

UTIOM organises around three pillars. The two capability maturity modules map cleanly onto two of them, with no overlap:

```
┌─────────────────────────────────────────────────────────────────┐
│  UTIOM — Unified Threat-Informed Operations Model               │
├──────────────────┬────────────────────┬─────────────────────────┤
│  LEADERSHIP &    │  ENGINEERING &     │  OPERATIONS &           │
│  GOVERNANCE      │  ENABLEMENT        │  ANALYSIS               │
│                  │                    │                         │
│  Vision          │  Threat Visibility │  Response               │
│  Strategy        │  Threat Detection  │  Continuous Improvement │
│  Crown Jewels    │                    │                         │
│                  │                    │                         │
│  ── UTIOM ──     │  ── TID-CMM ──     │  ── TIR-CMM ──          │
│  maturity +      │  "would we         │  "could we              │
│  capability      │   see it?"         │   stop it?"             │
│  assessments     │                    │                         │
└──────────────────┴────────────────────┴─────────────────────────┘
```

On the UTIOM V-model, TID-CMM measures the descending arm's output (what the engineering decisions produced); TIR-CMM measures the ascending arm (whether the design survives contact and is proven by validation). This is why TIR-CMM's validation domain carries the highest structural leverage in the model.

**UTIOM Law 6 — operations functions as continuous incident response** — is the load-bearing premise. TIR-CMM does not measure "the IR team." It measures the organisation's capacity to act, of which the IR team is one component and frequently not the binding one.

### 2.1 Division of scope

| Question | Answered by |
|---|---|
| Which adversaries matter to us? | TID-CMM (TI) — consumed by TIR-CMM |
| What are our crown jewels and attack paths? | UTIOM + TID-CMM (TM) — consumed by TIR-CMM |
| Would we observe the behaviour? | TID-CMM (DC, DE, AV) |
| Does the alert reach a human or process correctly? | **Bridge** — TID-CMM IR domain, redefined (§11) |
| Can we decide, contain, evict and restore? | **TIR-CMM** |
| Are we faster than the adversary? | **TIR-CMM** (Containment Margin) |
| Did we learn, and did it change detection? | TIR-CMM (RG) → feeds back to TID-CMM |

TIR-CMM deliberately contains **no detection domain**. It consumes detection maturity as an input constraint (R4). This is what makes the two models complementary rather than overlapping, and it is the design decision that keeps a combined assessment under two hours.

---

## 3. The Containment Lattice — the atomic scoring unit

TID-CMM scores coverage against in-scope ATT&CK techniques. Response does not vary meaningfully per technique — you isolate a compromised laptop the same way whether the adversary arrived via T1566 or T1190. Response varies by **where on the attack path you are** and **what kind of asset you are acting on**.

The atomic unit of TIR-CMM is therefore a **lattice cell**: one attack-path stage crossed with one asset class.

### 3.1 Attack-path stages (rows)

Seven stages, collapsed from ATT&CK tactics into the boundaries at which a *different response decision* is available:

| ID | Stage | Response question | ATT&CK tactics folded in |
|---|---|---|---|
| **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** (used in prioritisation, §9): containing early is worth more than containing late.

| Stage | S1 | S2 | S3 | S4 | S5 | S6 | S7 |
|---|---|---|---|---|---|---|---|
| Leverage λ | 1.5 | 1.4 | 1.3 | 1.2 | 1.0 | 1.0 | 0.8 |

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.

### 3.2 Asset classes (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) |

### 3.3 Lattice sizing and scoping

Maximum lattice: 7 × 8 = **56 cells**. This is deliberately never the working set.

A cell is **in scope** only when *both* conditions hold:

1. The asset class exists in the environment (declared in step 1), **and**
2. 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.

### 3.4 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 |

### 3.5 Response Readiness Status (RRS) — 0 to 3 per cell

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. |

### 3.6 Status 3 expires — and expires faster than detection

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

This expiry rule is the single most important honesty mechanism in the model. Response maturity is perishable in a way detection maturity is not.

---

## 4. The two headline metrics

### 4.1 Validated Response Score (VRS)

The direct analogue of TID-CMM's Validated Coverage Score.

**Unweighted:**

```
VRS = Σ RRS(c) / (3 × N)          for all in-scope cells c, N = |in-scope cells|
```

**Crown-jewel weighted (the reported figure):**

```
VRS_cj = Σ (ω(c) × RRS(c)) / (3 × Σ ω(c))
```

Reported alongside it, and expected to be the number that lands in the room:

- **Engineered rate** = proportion of cells at status ≥ 2 — "we believe we can act here"
- **Proven rate** = proportion of cells at status 3 — "we have shown we can act here"
- **Blind cells** = count of status-0 cells at tier T1 or T2 — *the places on a path to a crown jewel where you have no option at all*

The expected finding, mirroring TID-CMM's 48.9% / 12.7%, is a large gap between engineered rate and proven rate. The model is built to make that gap unavoidable rather than to flatter it.

### 4.2 Containment Margin (CM) — the metric unique to response

Detection maturity is a coverage problem. Response maturity is a **race**. A model that scores response without reference to adversary tempo is measuring paperwork.

For each priority actor *a* with breakout time *B(a)*:

```
CM(a) = B(a) − ( MTTD + MTTDecide + MTTC )
```

```
TR(a) = ( MTTD + MTTDecide + MTTC ) / B(a)          "Tempo Ratio"
```

| Term | Definition | Source |
|---|---|---|
| **B(a)** | Breakout time for the actor — time from initial foothold to first lateral movement | Threat intel; UTIOM metrics calculator; industry baseline where unavailable |
| **MTTD** | Mean time to detect | Imported from TID-CMM / SIEM |
| **MTTDecide** | **Mean time from validated alert to authorised containment decision** | TIR-CMM — measured here for the first time |
| **MTTC** | Mean time to execute containment once authorised | TIR-CMM |

**MTTDecide is the contribution.** Every maturity model in circulation folds decision latency into MTTR, where it disappears. Separating it exposes the most common and most fixable failure in incident response: the organisation is not slow at containing, it is slow at being *allowed* to contain. Organisations that measure it routinely discover MTTDecide exceeds MTTC by an order of magnitude.

**Interpretation:**

| Tempo Ratio | Meaning |
|---|---|
| TR < 0.5 | Containment lands well inside breakout — genuine tempo advantage |
| 0.5 ≤ TR < 1.0 | Contains before spread, with little margin |
| 1.0 ≤ TR < 2.0 | Structurally behind — you contain a spread intrusion, not a foothold |
| TR ≥ 2.0 | You are performing post-incident recovery and calling it response |

Tempo Ratio drives constraint **R5** (§8.5).

---

## 5. Maturity bands

Six bands, identical arithmetic ranges to TID-CMM so the two scores sit on one axis.

| Band | Range | Name | Definition |
|---|---|---|---|
| **L0** | 0.00–0.99 | **Improvised** | Response is individual heroics. The outcome depends on who happens to be on shift. This is a build project, not an improvement project. |
| **L1** | 1.00–1.99 | **Documented** | Plans exist on paper. Execution is unrehearsed and personality-dependent. The document has never met a clock. |
| **L2** | 2.00–2.99 | **Repeatable** | Playbooks and tooling are in place and consistently executed for known scenarios, but remain unproven under time pressure. **The most common band, and the band where response spending most exceeds response capability.** |
| **L3** | 3.00–3.99 | **Threat-informed** | Response traces to modelled attack paths and crown jewels. Containment is pre-authorised. Exercises are regular and evidenced. **The realistic target for most organisations.** |
| **L4** | 4.00–4.99 | **Validated** | A standing validation function exists. Containment is demonstrably inside the breakout window for priority actors. Requires tempo evidence — an L4 claim without measured MTTDecide is not assessable. |
| **L5** | 5.00 | **Adaptive** | Response adapts as the threat model changes; playbook and authority coverage regenerate from threat change without a project. Treat any L5 claim with scepticism unless the evidence is exceptional. |

**Band gate:** L4 and L5 are unreachable without supplied tempo evidence (§8.5). L3 is unreachable with any T1-tier blind cell (§8.6).

---

## 6. The eight domains and 58 sub-capabilities

Weights total 100. Sub-capability counts total 58, matching TID-CMM's structure so the two radars superimpose.

| ID | Domain | Weight | Subs | Core question |
|---|---|---|---|---|
| **RP** | Response Preparation & Readiness | 10% | 7 | Are we set up to run an incident at all? |
| **RA** | Response Authority & Decision Rights | 12% | 6 | Is someone permitted to act, in time? |
| **RE** | Response Engineering & Playbooks | 16% | 10 | Is response engineered, or written? |
| **CE** | Containment, Eradication & Recovery | 14% | 8 | Do we have graded options that work? |
| **AO** | Automation & Orchestration | 12% | 7 | Does machine speed reach the decision? |
| **FI** | Forensics, Evidence & Investigation | 10% | 6 | Do we know what actually happened? |
| **RV** | Response Validation & Exercising | 14% | 7 | Have we proven any of this? |
| **RG** | Response Governance, Metrics & Improvement | 12% | 7 | Does it improve, and can we report it? |

Every sub-capability is scored 0–5. Sub-weights are within-domain and total 100 per domain.

---

### RP — Response Preparation & Readiness · 10%

*Whether the organisation can start an incident cleanly. Cheap to build, catastrophic to lack, and consistently over-scored.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **RP-1** | Incident response plan and scope | 15 | No plan, or a template never adapted | Plan is organisation-specific, names roles, covers cloud/identity/OT as applicable, reviewed annually | Plan is versioned, scenario-indexed to the lattice, and demonstrably used in the last three incidents | Plan doc + version history + incident references |
| **RP-2** | Severity and classification model | 15 | Ad-hoc severity by opinion | Documented severity matrix driven by crown-jewel and business impact, applied consistently | Severity assignment is auditable, drives automatic authority and comms activation, and is reviewed against outcomes | Severity matrix + sample of classified incidents |
| **RP-3** | Roles, rotas and 24×7 reachability | 15 | Best-effort; unclear who responds out of hours | Named IR roles, documented rota, tested reachability, defined deputies | Reachability is tested unannounced; coverage gaps are measured and remediated | Rota + unannounced call-out test records |
| **RP-4** | Response tooling readiness | 15 | Tools are assumed available, never checked | Response tooling (EDR console, SOAR, forensic kit, out-of-band comms) is inventoried and access-tested | Tooling readiness is continuously monitored; break-glass access is tested and time-bounded | Tool inventory + access test log |
| **RP-5** | Out-of-band communications and war-room | 10 | None; incident comms would run on the compromised estate | Documented out-of-band channel and bridge, contact tree maintained | Out-of-band channel is exercised at least annually under assumed-compromise conditions | Exercise report showing OOB use |
| **RP-6** | Third-party, retainer and supplier readiness | 15 | No retainer; no supplier response terms | IR retainer or in-house equivalent in place, SLAs known, onboarding pre-completed | Retainer is exercised; critical suppliers have tested notification and joint-response paths | Retainer contract + activation/exercise record |
| **RP-7** | Legal, regulatory and communications preparation | 15 | Unclear obligations; no prepared position | Reporting obligations mapped (GDPR/DORA/NIS2/sector), legal counsel identified, holding statements drafted | Regulatory clocks are automated into the incident process and have been met under exercise or real conditions | Obligation register + evidence of clock adherence |

---

### RA — Response Authority & Decision Rights · 12%

*The domain no existing maturity model measures. Response fails here more often than it fails on tooling.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **RA-1** | Pre-authorised containment actions | 25 | Every containment action requires case-by-case approval | A defined set of containment actions is pre-authorised by asset class and severity, documented and signed off by business owners | Pre-authorisation covers every T1/T2 lattice cell, is reviewed as the estate changes, and is exercised | Signed authorisation matrix mapped to lattice cells |
| **RA-2** | Decision latency measurement (MTTDecide) | 20 | Not measured; folded into MTTR | MTTDecide is measured separately per severity and reported | MTTDecide is measured, targeted against breakout time, and trending against an explicit objective | Metric series with timestamps from case system |
| **RA-3** | Escalation thresholds and triggers | 15 | Escalation is by instinct | Documented, objective escalation triggers tied to severity and crown-jewel involvement | Triggers fire automatically from the case system; false-escalation and missed-escalation rates are tracked | Trigger definitions + escalation audit trail |
| **RA-4** | Out-of-hours and degraded-mode authority | 15 | No authority exists out of hours | Named out-of-hours decision authority with documented deputies and a defined maximum response time | Out-of-hours authority is tested unannounced and meets its time objective | Unannounced out-of-hours exercise record |
| **RA-5** | Business impact acceptance and risk ownership | 15 | Security cannot accept the business impact of containment; actions stall | Business owners have accepted, in advance and in writing, the disruption cost of defined containment tiers | Acceptance is reviewed against realised impact after incidents and exercises; disputes have a defined arbiter | Signed impact-acceptance records |
| **RA-6** | Crisis and executive decision structure | 10 | No crisis structure; ad-hoc escalation to whoever answers | Documented crisis management structure with defined activation criteria and executive decision rights | Crisis structure has been activated and evaluated; executives have participated in exercises within twelve months | Crisis activation log + executive exercise record |

---

### RE — Response Engineering & Playbooks · 16%

*The largest domain, mirroring TID-CMM's Detection Engineering weight. Response content deserves the same engineering discipline as detection content.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **RE-1** | Playbook coverage of the lattice | 15 | Playbooks exist for a handful of familiar scenarios | Every T1 and T2 lattice cell has an associated playbook or documented response procedure | Full lattice coverage including T3; gaps are tracked as a managed backlog with owners and dates | Playbook-to-cell coverage map |
| **RE-2** | Threat-informed derivation | 12 | Playbooks are generic or vendor-supplied | Playbooks derive from modelled attack paths, crown jewels and priority actor TTPs | Derivation is traceable end to end: actor → path → stage → asset → playbook → action | Traceability matrix |
| **RE-3** | Playbook-as-code and version control | 12 | Playbooks live in documents or a wiki, unversioned | Playbooks are stored in version control with review, history and change approval | Playbooks are machine-readable, linted in CI, and deploy to the orchestration platform from the repository | Repository + CI pipeline evidence |
| **RE-4** | Playbook testing before release | 12 | Never tested before use | Every playbook is executed in a test or staging context before production release | Automated playbook regression testing runs on change; failures block release | CI test results |
| **RE-5** | Parameterisation and reusability | 8 | Each playbook is bespoke prose | Playbooks are built from reusable, parameterised response actions rather than duplicated steps | A response-action library exists (RE&CT/D3FEND-aligned) and playbooks compose from it | Action library + composition evidence |
| **RE-6** | Decision points and human gates | 10 | Playbooks assume a single path with no branch logic | Playbooks contain explicit decision points, named decision owners, and defined default actions on timeout | Decision points carry measured latency data and are optimised against tempo objectives | Playbook with instrumented decision points |
| **RE-7** | Playbook lifecycle and deprecation | 8 | Playbooks accumulate; nothing is retired | Playbooks have owners, review cycles and a deprecation process | Playbook health is measured (staleness, execution success rate, drift against estate) | Lifecycle register + health metrics |
| **RE-8** | Response action mapping to ontology | 8 | No mapping | Response actions are mapped to RE&CT RA-codes and/or D3FEND techniques | Mapping is bidirectional and used to identify uncovered response actions against modelled techniques | Mapping export |
| **RE-9** | Cross-domain response content (identity, cloud, OT, SaaS) | 8 | Endpoint-only playbooks | Playbooks exist for identity, cloud control plane and SaaS compromise, and OT where applicable | Cross-domain playbooks are rehearsed and reflect the specialist containment primitives of each estate | Domain-specific playbooks + exercise evidence |
| **RE-10** | Response content sharing and reuse | 7 | Nothing shared internally or externally | Playbooks and actions are shared across teams/regions with a common standard | Organisation contributes to or consumes from open response content communities with a defined ingestion process | Shared repository / contribution record |

---

### CE — Containment, Eradication & Recovery · 14%

*Graded, reversible options with known blast radius. Maps to D3FEND Isolate, Evict and Restore.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **CE-1** | Tiered containment options per asset class | 16 | One blunt option, or none | Each asset class has graded containment tiers (observe / restrict / isolate / disable) with documented business impact | Tiers are exercised, impact is measured against prediction, and selection is guided by the severity model | Containment tier matrix + exercise data |
| **CE-2** | Blast radius control and reversibility | 14 | Containment effects are unknown and irreversible | Blast radius is documented per action; every action has a defined rollback | Rollback is tested; unintended-impact rate is measured and trending down | Rollback test records |
| **CE-3** | Identity containment (Tier-0) | 14 | No ability to contain identity compromise at speed | Session revocation, credential reset, token invalidation and trust-break procedures exist and are owned | Identity containment is proven inside the breakout window and covers federated and non-human identities | Exercise record with timings |
| **CE-4** | Network and egress containment | 10 | No dynamic blocking capability | Egress blocking, sinkholing and segment isolation are available and documented | Network containment is automated where safe, with proven propagation times | Automation + timing evidence |
| **CE-5** | Eradication completeness and re-entry prevention | 14 | Eradication means "we rebuilt the box" | Eradication addresses persistence, credentials and access paths, with a documented completeness checklist | Re-infection rate is measured; eradication is verified by independent scoping before closure | Eradication verification records + reinfection metric |
| **CE-6** | Recovery, restoration and integrity verification | 12 | Recovery is IT's problem, uncoordinated with IR | Recovery procedures are integrated with IR, with defined RTO/RPO for crown jewels and integrity verification before return | Recovery is exercised at crown-jewel scale; restored systems are verified clean against a defined standard | Recovery exercise report |
| **CE-7** | Backup resilience against destructive attack | 10 | Backups are online and reachable with production credentials | Immutable or logically isolated backups exist for crown jewels, with separate credentials | Restore from immutable backup is tested at scale within the recency window, with measured time-to-restore | Restore test record |
| **CE-8** | Degraded-mode and business continuity operation | 10 | No defined degraded mode | Documented degraded-mode operation for crown-jewel services, agreed with the business | Degraded mode is exercised with business participation and meets agreed service floors | Continuity exercise record |

---

### AO — Automation & Orchestration · 12%

*Machine speed is only useful if it is permitted to reach the decision. Constrained by RA (R2).*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **AO-1** | Enrichment and triage automation | 14 | All enrichment is manual | Automated enrichment of alerts (asset, identity, intel, prior cases) before analyst contact | Enrichment quality is measured; analyst time-to-context is tracked and improving | Metric series |
| **AO-2** | Automated containment coverage | 20 | No automated containment | Automated containment exists for defined low-risk, high-confidence scenarios with pre-authorisation | Automated containment covers the majority of T1/T2 cells where safe, with measured execution success | Automation coverage map + success rate |
| **AO-3** | Human-in-the-loop gate design | 14 | Either everything is manual or automation runs unsupervised | Gates are explicitly designed: which actions require a human, which do not, and what happens on timeout | Gate placement is reviewed against measured decision latency and incident outcomes | Gate design doc + latency data |
| **AO-4** | Integration coverage and API depth | 14 | Few integrations; response requires console-hopping | Orchestration platform integrates with the tools controlling every in-scope asset class | Integration health is monitored; failures alert; coverage tracks estate change automatically | Integration inventory + health monitoring |
| **AO-5** | Automation reliability, safety and rollback | 14 | Automation fails silently or has caused unplanned outages | Automation has error handling, safety limits (rate/scope caps) and rollback paths | Automation failure rate and unintended-impact rate are measured; safety limits are tested | Reliability metrics + safety test evidence |
| **AO-6** | Case management and workflow integrity | 14 | Incidents tracked in email or chat | A case system holds all incidents with structured timeline, actions and timestamps | Case data is complete enough to compute MTTD/MTTDecide/MTTC automatically without manual reconstruction | Automated metric derivation from case data |
| **AO-7** | Automation change control | 10 | Automation is edited live in production | Automation changes go through review and testing before deployment | Automation is deployed via pipeline with staged rollout and automated regression testing | CI/CD evidence |

---

### FI — Forensics, Evidence & Investigation · 10%

*Scoping accuracy determines eradication completeness. Under-invested almost universally.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **FI-1** | Triage and scoping capability | 22 | Scoping is guesswork; "patient zero" is rarely established | Structured triage produces a defensible scope: affected assets, identities and timeframe | Scoping accuracy is measured retrospectively; under-scoping incidents are treated as findings | Scope-accuracy review records |
| **FI-2** | Evidence acquisition capability | 18 | No acquisition capability; systems are wiped before analysis | Volatile and disk acquisition is possible for each in-scope asset class within a defined time | Acquisition is proven at speed for cloud and ephemeral workloads, not only endpoints | Acquisition test records incl. cloud |
| **FI-3** | Chain of custody and evidence handling | 15 | No chain of custody | Documented chain of custody suitable for internal disciplinary and insurance purposes | Evidence handling meets a standard suitable for legal or regulatory proceedings and has been reviewed by counsel | Custody procedure + legal review |
| **FI-4** | Timeline reconstruction | 15 | No timeline produced | Incident timelines are produced for significant incidents with source attribution | Timeline construction is partly automated from case and telemetry data and is used to compute tempo metrics | Sample timelines + automation |
| **FI-5** | Log and evidence retention adequacy | 15 | Retention is shorter than typical dwell time | Retention for crown-jewel-relevant sources exceeds median dwell time for priority actors | Retention is set from measured dwell time and validated by successful historical investigation | Retention policy + successful lookback case |
| **FI-6** | Malware and artefact analysis access | 15 | No capability, internal or external | Analysis capability available in-house or via retainer, with defined turnaround | Analysis output feeds detection engineering and playbook updates within a defined cycle | Analysis reports + resulting detection/playbook changes |

---

### RV — Response Validation & Exercising · 14%

*The ceiling-setting domain. Everything else in the model is capped at RV + 1 (R1).*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **RV-1** | Tabletop exercise programme | 12 | None, or one-off compliance theatre | Regular tabletops covering crown-jewel scenarios with the right participants, findings tracked | Tabletops are scenario-derived from the lattice, include executives and third parties, and drive tracked remediation | Exercise reports + remediation tracking |
| **RV-2** | Technical live-fire exercising | 22 | Never; playbooks have never been executed under exercise conditions | Playbooks are executed technically against emulated adversary activity in a controlled window | A standing programme executes live-fire against production or production-equivalent, on a defined rotation across the lattice | Live-fire schedule + results per cell |
| **RV-3** | Purple team and end-to-end response validation | 18 | Purple team ends at detection | Purple team exercises continue through containment and eradication, not stopping at the alert | Every priority attack path is validated end to end — detect, decide, contain, evict, restore — on a defined cycle | End-to-end purple team reports |
| **RV-4** | Containment timing measurement under exercise | 16 | No timings captured | Exercises capture MTTD, MTTDecide and MTTC and compare them to breakout time | Timing objectives are set per stage, measured every exercise, and drive engineering priorities | Timing dataset across exercises |
| **RV-5** | Validation recency and coverage tracking | 12 | Not tracked | Validation status and date tracked per lattice cell; expiry applied | Expiry is automated; a validation-debt figure is reported to leadership alongside coverage | Automated validation register |
| **RV-6** | Failure injection and resilience of the response function | 10 | Never tested | Response is exercised under degraded conditions (key tool unavailable, key person absent, SIEM down) | Degraded-mode response is routinely injected and the function meets defined floors | Degraded-mode exercise records |
| **RV-7** | Independent assessment and red team | 10 | No independent challenge | Periodic independent red team or assessment includes response effectiveness, not just breach success | Independent assessment is scoped explicitly against TIR-CMM lattice cells and its findings are tracked to closure | Independent report + closure evidence |

---

### RG — Response Governance, Metrics & Improvement · 12%

*Whether the capability compounds. Closes UTIOM's Kaizen loop and feeds TID-CMM.*

| ID | Sub-capability | Wt | Score 0 | Score 3 | Score 5 | Evidence for 4–5 |
|---|---|---|---|---|---|---|
| **RG-1** | Response metrics programme | 18 | No metrics, or ticket counts only | MTTD, MTTDecide, MTTC, MTTR and containment success are measured and reported | Metrics are leading as well as lagging, tied to breakout time, and drive investment decisions | Metric definitions + reporting history |
| **RG-2** | Post-incident review discipline | 18 | Reviews happen rarely and blamefully | Blameless post-incident reviews occur for all significant incidents, with tracked actions | Reviews produce structural findings; action closure rate and recurrence rate are measured | PIR records + closure metrics |
| **RG-3** | Feedback loop into detection (TID-CMM) | 16 | No feedback; response findings die in the report | Incident and exercise findings generate detection engineering work items | The loop is measured: proportion of incidents producing detection improvements, and time to deploy | Linked incident → detection change records |
| **RG-4** | Feedback loop into architecture and hardening | 12 | None | Findings generate hardening and architecture work items with owners | Architecture findings are tracked to completion and their effect is re-validated | Linked findings → architecture changes |
| **RG-5** | Response capability ownership and funding | 12 | No clear owner or budget for response capability | Named owner and dedicated budget for response engineering, distinct from SOC staffing | Investment is prioritised using measured gaps (TIR-CMM roadmap) rather than vendor cycles | Budget + prioritisation evidence |
| **RG-6** | Regulatory and executive reporting | 12 | Reporting is improvised under pressure | Defined reporting packs and regulatory notification procedures, with owners and clocks | Reporting has been executed under real or exercise conditions within the required clocks | Reporting evidence with timestamps |
| **RG-7** | Continuous improvement cadence | 12 | Improvement is project-driven and sporadic | A regular cadence reviews response capability against the model and adjusts the backlog | Improvement is continuous, measured against the lattice, and reassessment shows movement | Reassessment history |

---

## 7. Scoring mathematics

Identical in form to TID-CMM, so results are comparable and the workbook formulas transfer.

### 7.1 Sub-capability → domain

```
domain_score = Σ(sub_weight × sub_score) / Σ(sub_weight)
```

Not-applicable sub-capabilities are removed from both numerator and denominator. No penalty, no benefit.

### 7.2 Domain → overall

```
overall_score = Σ(domain_weight × domain_score) / Σ(domain_weight)
```

### 7.3 Lattice → reported coverage

The lattice does **not** feed the overall domain score arithmetically. It is reported alongside it, exactly as TID-CMM reports Validated Coverage Score alongside domain maturity. Conflating them would let broad shallow coverage mask a structural inability to act.

The lattice does, however, bind the score through constraint **R6** (§8.6) and through prioritisation (§9).

### 7.4 Reported output set

| Output | Form |
|---|---|
| Overall maturity | 0.00–5.00 + band L0–L5 |
| Domain scores | 8 × 0.00–5.00, radar chart |
| VRS_cj | 0–100% |
| Engineered rate / Proven rate | 0–100% each — the headline gap |
| Blind cells (T1/T2) | Count + named list |
| Containment Margin per priority actor | Minutes, signed |
| Tempo Ratio per priority actor | Ratio |
| Constraint adjustments | Self-assessed vs adjusted, per constraint |
| Ranked roadmap | Ordered list with impact scores |

---

## 8. Integrity constraints

TID-CMM's central innovation is that constraints apply **mechanically**, lower scores only, and cannot be argued with. TIR-CMM inherits this exactly and adds two constraints unique to response.

**Application order:**

```
R3  (sub-capability level, evidence)
 ↓
compute domain scores
 ↓
R4  (detection dependency, cross-model)
 ↓
R2  (authority ceiling)
 ↓
R1  (rehearsal ceiling)
 ↓
compute overall score
 ↓
R5  (tempo band cap)     R6  (blind-cell band cap)
```

Each constraint operates on figures already adjusted by the preceding ones.

**Reporting rule — independent effect, not marginal effect.** Because R1 is applied last and is usually the tightest ceiling, it routinely subsumes R2 and R4, which would then appear in the report as "no effect" even where they are diagnostically the most important finding. The tool must therefore compute and display each constraint's **independent** effect — what it would cap, evaluated against the pre-constraint domain scores — alongside its marginal effect on the final number. Without this, R2 and R4 become invisible in exactly the organisations they were written for. This behaviour was identified during numerical validation of the worked example (§8.8).

### 8.1 R1 — Rehearsal Ceiling

```
∀ domain d ≠ RV:   d ≤ RV + 1
```

> **An unrehearsed playbook is an assumed capability.**

The direct analogue of TID-CMM's C1. Response is more exposed to this than detection: a detection rule at least executes automatically every day, whereas a playbook that is never run may not survive first contact with the tooling, the people or the clock.

### 8.2 R2 — Authority Ceiling

```
AO ≤ RA + 1
CE ≤ RA + 1
```

> **Automation you are not permitted to fire is a demonstration, not a capability.**

The constraint with no equivalent in any existing model. It expresses the single most common structural failure in incident response: a technically capable organisation that cannot act because nobody with authority is available, informed, or willing to accept the business impact. Buying a better SOAR does not move this score.

### 8.3 R3 — Evidence Rule

```
sub_score ∈ {4,5} ∧ ¬∃ named_dated_artifact  ⟹  sub_score := 3
```

> Unsupported claims must not outrank evidenced assessments.

Identical to TID-CMM's C3. The artifact must be named and dated: an incident ticket ID, an exercise report with a date, a signed authorisation matrix, a timestamped containment log. "We do that" is not an artifact.

### 8.4 R4 — Detection Dependency (cross-model)

```
RE ≤ D + 1
CE ≤ D + 1
FI ≤ D + 1
```

> **You cannot respond to what you never saw.**

This is the structural hinge that makes TIR-CMM complete TID-CMM rather than duplicate it. It also creates the correct incentive: an organisation cannot reach a high response score by buying response tooling while remaining blind.

**TIR-CMM does not require TID-CMM.** `D` may come from any of three sources, each justifying a different band ceiling:

| Source of `D` | Band ceiling | Rationale |
|---|---|---|
| **Imported TID-CMM assessment** | none — assessable to L5 | Detection maturity is independently evidenced. |
| **Built-in prerequisite check** (§8.4.1) | **L4** | A self-assessment is sufficient to assess response up to validated maturity. Claiming *adaptive* response maturity on an unaudited detection claim is not credible. |
| **Nothing supplied** | **L3** | The response score rests on an unaudited claim, and the report says so. |

The point of the middle row is that an organisation with no detection maturity model of any kind is a normal customer for this model, not a rejected one. Turning it away would be both unhelpful and self-defeating: response is precisely where such an organisation is most exposed.

#### 8.4.1 The prerequisite check

Eight questions, scored 0–5, of which at least six must be answered for the proxy to count.

**Detection (produces `D`):**

| ID | Question |
|---|---|
| PD-1 | Telemetry coverage of crown jewels |
| PD-2 | Where detection content comes from |
| PD-3 | Detection testing |
| PD-4 | Alert quality reaching a responder |
| PD-5 | Identity and cloud detection coverage |

**Threat modelling (produces `TM`, governing confidence in lattice scoping):**

| ID | Question |
|---|---|
| PM-1 | Crown jewel definition |
| PM-2 | Attack path modelling |
| PM-3 | Adversary prioritisation |

The modelling questions are *scored*, not assumed — which resolves open question 3 (§14) directly. A declared attack path from an organisation that has never modelled one does not earn the same scope quality as an imported modelled path, and PM-2 is where that difference is recorded.

---

## 8A. Readiness lenses

The eight domains describe how the capability is **built**. Leadership asks a different question, and it is the one that decides whether the assessment gets acted on:

| Lens | Question | Subs |
|---|---|---|
| **Readiness to respond** | If it started now, could we act on it in time? | 27 |
| **Readiness to recover** | Could we get the business back, clean, and prove it? | 14 |
| **Operational resilience** | Could we keep running through it, and be harder to hit next time? | 15 |

Each lens re-cuts the same 58 sub-capabilities, with a weight of 2 for sub-capabilities core to that outcome and 1 for contributing ones.

**They are lenses, not partitions.** Eight sub-capabilities serve more than one outcome, which is correct — CE-7 (backup resilience) is both a recovery capability and a resilience one, and forcing it into a single bucket would misrepresent it. Ten sub-capabilities sit in no lens, because they describe how the capability is engineered rather than what outcome it delivers.

Each lens reports two figures:

- **Claimed** — the weighted mean of its R3-adjusted sub-capability scores.
- **Proven** — the same figure with the rehearsal ceiling (RV + 1) applied, exactly as it is applied everywhere else in the model.

**Both are reported with equal prominence, and this is a deliberate correction.** When the rehearsal ceiling binds — which is the common case — it flattens all three *proven* figures to the same number, destroying the lenses' only job of discriminating between the three outcomes. The *claimed* figure is what still separates them, and the gap between claimed and proven is itself the most useful output: in the worked example the organisation claims 3.26 recovery readiness against 2.52 proven, a 0.74 gap and the largest of the three — the signature of a mature disaster-recovery programme that has never been exercised as an incident.

*Note:* R4 also subsumes the role of TID-CMM's C4 (intent ceiling) for the response module, since the threat modelling that produces the lattice is imported from TID-CMM's TM domain rather than re-assessed here. See §14 open question 3.

### 8.5 R5 — Tempo Ceiling

Applies to the **band**, not to domain scores.

```
TR = (MTTD + MTTDecide + MTTC) / B(a_priority)

TR ≥ 2.0            ⟹  band capped at L1
1.0 ≤ TR < 2.0      ⟹  band capped at L2
tempo not supplied  ⟹  band capped at L3, report marked "tempo unverified"
```

> **A response capability structurally slower than the adversary is not a level 3 capability, whatever the documentation says.**

This is the constraint that prevents TIR-CMM from becoming a paperwork audit. An organisation can hold excellent playbooks, full automation coverage and a rehearsal programme, and still be losing every race. The tempo cap makes that visible in one number that a board understands.

### 8.6 R6 — Blind-Cell Gate

```
∃ cell c : tier(c) = T1 ∧ RRS(c) = 0   ⟹  band capped at L2
```

> If there is a stage on a crown jewel where you have no response option at all, you are not threat-informed.

The response analogue of TID-CMM's structural-gap analysis, and consistent with UTIOM's Law 3 (crown jewels drive resource allocation) and Law 5 (blind spots are architectural choices).

### 8.7 Worked constraint effect

TID-CMM's published worked example moves an organisation from a self-assessed 2.44 to an adjusted 2.34 — a deliberately modest drop that demonstrates the mechanism without theatre. TIR-CMM behaves comparably on the decimal, and the honest shock arrives in the **band**, not the number.

### 8.8 Numerical validation — "Meridian Group"

The full pipeline was executed numerically against a fictional mid-size European financial services organisation (~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.

**Structural checks:** domain weights sum to 100 ✓ · 58 sub-capabilities ✓ · all eight domains' sub-weights sum to 100 ✓

**Constraint trace:**

| Step | Effect |
|---|---|
| Self-assessed overall | **2.69** (L2) |
| R3 evidence rule | 3 sub-capabilities demoted 4→3 (RP-3, RP-4, RA-1 — all claimed without a dated artifact) |
| R4 detection dependency | ceiling 3.34 — not binding at final ordering (independently: would not bind) |
| R2 authority ceiling | ceiling 3.30 — not binding at final ordering (independently: would not bind) |
| R1 rehearsal ceiling | RV = 1.52 → ceiling 2.52. **Binds six of eight domains.** RP 3.60→2.52, AO 2.94→2.52, FI 2.85→2.52, RE 2.74→2.52, RG 2.72→2.52, CE 2.68→2.52 |
| Constraint-adjusted overall | **2.35** (L2), Δ −0.33 |

**Lattice:** 28 in-scope cells (inside the 24–38 design band) · VRS_cj **45.3%** · engineered rate **39.3%** · **proven rate 3.6%** · one blind Tier-1 cell: **S3 × A1 — privilege escalation on identity infrastructure, no response option at all**.

The engineered-versus-proven gap (39.3% vs 3.6%) is the response analogue of TID-CMM's 48.9% vs 12.7%, and is proportionally wider — which is the expected and intended result, since response capability is rehearsed far less often than detection logic is exercised.

**Tempo:** breakout 62 min · MTTD 180 + MTTDecide 95 + MTTC 40 = 315 min · **Containment Margin −253 min** · **Tempo Ratio 5.08**.

**Band:** R5 fires (TR ≥ 2.0 → cap L1). R6 fires (Tier-1 blind cell → cap L2). Final reported band: **L1 — Documented**, against a self-assessed 2.69 that would have read L2 and, in most maturity models, been reported as "approaching level 3."

**Mechanical roadmap, top five:** RV-2 live-fire exercising · S3×A1 blind identity cell · RA-2 decision-latency measurement · RV-4 exercise timing capture · S2×A1 persistence on identity infrastructure.

Note that not one of the top five is a product purchase, and three of five are things this organisation believed it already had. That is the model working.

**Two defects were found and corrected by this validation:** the roadmap scale mismatch (§9.3) and the constraint-reporting problem (§8, reporting rule). Both would have shipped unnoticed without executing the arithmetic.

---

## 9. Prioritisation and roadmap generation

Two ranked lists are produced and then merged. Both are mechanical — no advocacy, no facilitator bias.

### 9.1 Capability gaps (sub-capability level)

Identical to TID-CMM's formula:

```
impact = (domain_weight / 100) × (sub_weight / 100) × gap_to_target × 1000
```

### 9.2 Lattice gaps (cell level)

```
cell_impact = ω(c) × λ(stage) × (3 − RRS(c)) × 100

  ω = criticality tier weight (T1=3, T2=2, T3=1)
  λ = stage leverage (S1 1.5 … S7 0.8)
```

This surfaces the correct counter-intuitive result: 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.

### 9.3 Normalisation before merge — mandatory

The two lists operate on incompatible scales. Maximum capability impact is `0.16 × 0.25 × 3 × 1000 = 120`; maximum cell impact is `3 × 1.5 × 3 × 100 = 1350`. Merging the raw figures produces a roadmap consisting **entirely of lattice cells**, with every capability gap buried — verified numerically during model validation.

Each list is therefore normalised to its own maximum before merging:

```
normalised_impact = 100 × impact / max(impact in that list)
```

This is scale-free and survives any future reweighting. The merged list is then sorted descending. Validation confirms this produces a properly interleaved result whose top five are the live-fire exercising gap, the blind identity-escalation cell, decision-latency measurement, exercise timing capture, and the persistence-on-identity cell — which is the model's central argument, generated mechanically rather than asserted.

### 9.4 The blueprint — bucketing by what it actually takes

A ranked list is not a plan. Every sub-capability therefore carries four further attributes, so the ranking can be turned into something a person can start on Monday:

| Attribute | Purpose |
|---|---|
| **act** | The concrete first action, imperative, one sentence. Not "improve decision latency measurement" but "measure the gap between alert-validated and containment-authorised timestamps on your last 20 incidents." |
| **win** | What you have once it is done — checkable, and usually the exact artifact constraint R3 demands for a score of 4 or 5. |
| **eff** | Effort tier: 1 = days, 2 = weeks, 3 = quarters. |
| **owner** | The role that must actually do it. For authority items this is a business or executive role, not security — which is the finding. |

The ranked roadmap is then bucketed by effort:

| Bucket | Window | Means |
|---|---|---|
| **Quick fixes** | 0–30 days | One person, no budget, no procurement. Writing things down, getting decisions made, measuring what you already do. |
| **Ninety-day moves** | 1–3 months | Coordination across teams, a scheduled exercise, or a contained piece of engineering. |
| **Structural work** | 6–12 months | Budget, procurement, hiring, architecture change or a standing programme. |

Effort spread across the 58: **20 / 23 / 15**.

The distribution is the argument. Authority and measurement work — the two domains that most often bind the score — is overwhelmingly effort tier 1. Five of the six RA sub-capabilities are quick fixes. This means the model's own ranking routinely puts *free* items at the top of the plan, and lets a CISO show a board that the largest single constraint on response capability costs a decision, not a purchase.

Lattice gaps are bucketed too: a **blind crown-jewel cell is a quick fix**, because naming an owner and writing an interim manual procedure is a days-not-quarters job and it is what lifts the R6 band cap. Every other lattice gap is a ninety-day move.

### 9.5 Merge and sequencing

The merged list is sequenced with dependency awareness:

1. Anything that lifts a **binding constraint** is promoted, because it unlocks score elsewhere. In practice, RA and RV work is almost always promoted — which is the model's central argument made arithmetically.
2. Items are grouped into a **90-day / 180-day / 12-month** plan, matching UTIOM's roadmap tool.
3. The output names **capabilities and authorities required, not products** — inherited directly from TID-CMM's design principle.

---

## 10. Standards crosswalk

TIR-CMM operationalises rather than replaces. Four ontologies anchor it, each doing a distinct job:

| Anchor | Role in TIR-CMM |
|---|---|
| **MITRE D3FEND 1.5.0** (7 tactics; Isolate / Evict / Restore are response-side) | Structural mirror of ATT&CK. Provides the countermeasure vocabulary for containment primitives per asset class (§3.2) and the conceptual symmetry with TID-CMM. |
| **RE&CT** (RA1000–RA6000, 6 stages, 300+ response actions) | The operational spine. Provides the response-action library that RE-5 and RE-8 score against, and the phase structure practitioners already recognise. |
| **ATT&CK Mitigations (M-codes)** | Traceability bridge. Techniques scoped by TID-CMM carry M-codes; these map to lattice cells, so the response scope derives from the detection scope automatically. |
| **NIST SP 800-61r3** (April 2025, CSF 2.0 Community Profile) | Governance crosswalk. Note that r3 deliberately abandons the linear four-phase lifecycle in favour of CSF 2.0 functions — TIR-CMM follows r3, not r2, and this is a differentiator against models still built on the 2012 phase model. |

### 10.1 Domain-level crosswalk

| TIR-CMM | NIST CSF 2.0 | NIST SP 800-61r3 | ISO/IEC 27035 | RE&CT | D3FEND | SOC-CMM | DORA / NIS2 |
|---|---|---|---|---|---|---|---|
| **RP** | GV, PR.IP, RS.MA | Preparation (GV/ID/PR) | Plan & prepare | RA1000 | Model, Harden | Process, People | ICT continuity, incident mgmt |
| **RA** | GV.RR, RS.MA | Governance & roles | Plan & prepare | RA1000 | — | Governance | Management body accountability |
| **RE** | RS.AN, RS.MI | Response execution | Detection & reporting; Response | RA2000–RA5000 | Isolate, Evict | Process, Technology | Response & recovery plans |
| **CE** | RS.MI, RC.RP | Containment/eradication/recovery | Response; Recovery | RA3000–RA5000 | Isolate, Evict, Restore | Technology | ICT continuity, backup |
| **AO** | RS.MI, DE.AE | Response execution | Response | RA3000 | Isolate | Technology | Operational resilience |
| **FI** | RS.AN, ID.RA | Analysis | Assessment & decision | RA2000 | — | Technology, Process | Evidence, root cause |
| **RV** | ID.IM, PR.PT | Continuous improvement | Lessons learned | RA6000 | — | Process | Testing (TLPT/DORA), NIS2 testing |
| **RG** | GV, ID.IM, RS.CO | Continuous improvement | Lessons learned | RA6000 | — | Governance, Services | Reporting clocks (24h/72h/1m) |

### 10.2 Positioning against adjacent models

| Model | Relationship |
|---|---|
| **SOC-CMM** | Assesses the SOC as a function. TIR-CMM assesses whether the organisation can act — including the parts of response that sit outside the SOC (authority, business acceptance, recovery). Complementary. |
| **NIST CSF 2.0** | Reporting layer above TIR-CMM. TIR-CMM supplies the evidence CSF Respond/Recover asks for. |
| **TID-CMM** | Sibling module. Bonded through R4 and the bridge domain (§11). |
| **Gartner CTEM** | Asks whether exposure is exploitable and observable. TIR-CMM asks whether exploitation can be stopped. |
| **DORA / NIS2** | TIR-CMM produces the testing, reporting-clock and continuity evidence these regimes require, without being a compliance model. |
| **VERIS** | Incident taxonomy; useful as an input to scenario derivation, not a maturity model. |

---

## 11. The TID-CMM bridge — resolving the IR domain overlap

TID-CMM v1.2 contains **IR — Incident Response & Recovery** at 10% with 6 sub-capabilities. Publishing TIR-CMM without addressing this leaves users with two contradictory response numbers.

**Resolution: substitution mode.** TID-CMM keeps IR at 10% — no reweighting, no invalidation of existing assessments — but the domain is redefined and gains a substitution rule.

### 11.1 Redefinition

TID-CMM's IR domain narrows from "incident response and recovery" to **the detection-to-response interface**: the handoff, not the response.

| Old scope | New scope (bridge) |
|---|---|
| Full IR capability, shallowly | Alert-to-case fidelity and enrichment |
| | Triage handoff quality and completeness of context |
| | Escalation path integrity from detection to responder |
| | Response feedback loop into detection tuning |
| | Case data sufficiency for tempo measurement |
| | Declared response maturity (or imported TIR-CMM score) |

This is genuinely within detection's remit — a detection function is accountable for whether its output is actionable — and it removes the pretence that a detection model can assess containment.

### 11.2 Substitution rule

```
if TIR-CMM assessment imported:
      TID-CMM.IR := TIR-CMM.overall
      report annotated "IR domain sourced from TIR-CMM v0.x, assessed <date>"
else:
      TID-CMM.IR := bridge sub-capabilities only
      report annotated "response capability not independently assessed"
```

Reciprocally, TIR-CMM consumes `TID-CMM.overall` as `D` in constraint R4. Because TID-CMM's IR is *substituted by* TIR-CMM rather than added to it, and TIR-CMM contains no detection domain, **there is no circular inflation** — the substitution is applied after TID-CMM's own constraints are computed, and R4 uses the pre-substitution TID-CMM score. This ordering must be stated explicitly in both specifications.

### 11.3 Change required to TID-CMM

Version bump to **v1.3**, non-breaking:

- IR domain sub-capabilities rewritten (weight unchanged at 10%)
- Substitution rule added to the scoring page
- Export schema extended with `detection_score_pre_substitution` for R4 consumption
- Cross-link added: "Response assessed in depth by TIR-CMM"

Existing v1.2 assessments remain valid and comparable at overall level.

---

## 12. Assessment flow — ten steps

Mirrors TID-CMM's ten-step wizard so the two tools feel like one product. Target duration: **60–75 minutes** for a rapid baseline.

| # | Step | Input | Output |
|---|---|---|---|
| 1 | **Import or declare context** | TID-CMM JSON export, or manual entry | Crown jewels, attack paths, priority actors, detection score |
| 2 | **What you run** | Asset class selection (A1–A8) | Active columns of the lattice |
| 3 | **What you must keep running** | Crown jewel → asset class mapping, RTO/RPO | Cell criticality tiers T1–T3 |
| 4 | **Who targets you and how fast** | Priority actors + breakout times | B(a) for tempo calculation |
| 5 | **Lattice scoping** | Auto-derived; assessor confirms N/A cells | In-scope lattice, 24–38 cells |
| 6 | **Containment options** | Per asset class: available primitives and tiers | Feeds CE domain, informs cell status |
| 7 | **Authority map** | Who may authorise what, when, with what latency | Feeds RA domain — the step that surprises people |
| 8 | **Lattice status** | RRS 0–3 per in-scope cell, with evidence and date | VRS, blind cells |
| 9 | **Capability scoring** | 58 sub-capabilities, 0–5, with evidence | Domain scores |
| 10 | **Tempo and results** | MTTD / MTTDecide / MTTC | Full report + ranked roadmap |

Step 7 is placed before step 8 deliberately. Assessors who map authority first score the lattice more honestly, because they have just discovered how many actions require an approval they cannot obtain at 03:00.

### 12.1 Assessment modes

| Mode | Duration | Depth |
|---|---|---|
| **Rapid baseline** | Half a day | Self-assessment; identifies the conversations worth having |
| **Structured assessment** | Two weeks | Evidence-backed, stakeholder-participatory, R3 fully enforced |
| **Continuous** | Ongoing | Lattice status maintained live; validation expiry automated; reassessed quarterly |

Identical to TID-CMM's modes.

---

## 13. Data model and interop contract

### 13.1 Principles inherited from TID-CMM

- **Entirely client-side.** No server calls, no analytics, no transmission. Non-negotiable — it is why practitioners will run it on real data.
- **Machine-readable model.** YAML/JSON definitions of domains, sub-capabilities, lattice, constraints published alongside the tool.
- **Open licence.** Model CC-BY-4.0, tooling Apache-2.0.
- **Offline parity.** Excel workbook with live formulas mirroring the tool exactly.

### 13.2 Import contract from TID-CMM

```json
{
  "schema": "tid-cmm/export/1.3",
  "assessed_at": "2026-08-16",
  "detection_score_pre_substitution": 2.34,
  "domains": { "TI": 2.6, "TM": 2.4, "DC": 2.1, "DE": 2.5,
               "AV": 1.9, "AA": 2.4, "IR": 2.2, "GV": 2.5 },
  "crown_jewels": [ { "id": "CJ-01", "name": "...", "asset_classes": ["A1","A7"] } ],
  "attack_paths": [ { "id": "AP-01", "actor": "...", "stages": ["S1","S3","S4","S7"],
                      "asset_classes": ["A2","A1","A3","A7"] } ],
  "actors": [ { "id": "TA-01", "name": "...", "breakout_minutes": 62 } ],
  "in_scope_techniques": [ { "id": "T1078", "status": 2, "mitigations": ["M1032"] } ]
}
```

### 13.3 Export contract to UTIOM

```json
{
  "schema": "tir-cmm/export/0.1",
  "overall": 2.31,
  "band": "L2",
  "band_capped_by": ["R5"],
  "domains": { "RP": 2.8, "RA": 1.9, "RE": 2.4, "CE": 2.5,
               "AO": 2.2, "FI": 2.0, "RV": 1.6, "RG": 2.3 },
  "vrs_cj": 0.41,
  "engineered_rate": 0.55,
  "proven_rate": 0.16,
  "blind_cells_t1t2": [ { "stage": "S3", "asset_class": "A1", "tier": "T1" } ],
  "tempo": [ { "actor": "TA-01", "breakout_min": 62,
               "mttd_min": 180, "mttdecide_min": 95, "mttc_min": 40,
               "containment_margin_min": -253, "tempo_ratio": 5.08 } ],
  "constraint_adjustments": [
    { "constraint": "R1", "domains": ["RP","CE","AO"], "effect": -0.31 },
    { "constraint": "R2", "domains": ["AO","CE"], "effect": -0.12 }
  ],
  "roadmap": [ { "rank": 1, "id": "RA-1", "impact": 480, "horizon": "90d" } ]
}
```

UTIOM's `roadmap.html` consumes both TID-CMM and TIR-CMM exports and produces the unified improvement plan across all three pillars.

---

## 14. Open questions for v0.2

1. **R4 basis.** Should `D` be TID-CMM's overall score, or the lower of its overall and its DC (telemetry) domain? The latter is harsher and arguably more correct — response depends most acutely on visibility — but risks double-penalising organisations already constrained by TID-CMM's C2.

2. **Lattice vs domain coupling.** The lattice currently constrains the band (R6) but does not feed the arithmetic. An alternative is to make the lattice a ninth pseudo-domain. Recommendation is to keep them separate, matching TID-CMM's treatment of VCS, but this should be tested against the worked example.

3. ~~**Threat modelling without TID-CMM.**~~ **RESOLVED (§8.4.1).** The prerequisite check scores threat modelling explicitly via PM-1 to PM-3 rather than assuming it, so a declared attack path from an organisation that has never modelled one no longer earns the same scope quality as an imported modelled path. No light TM gate was added to RP and no weight moved. What remains open is calibration: whether the six-of-eight answer threshold and the L4/L3 ceilings are set at the right level. Field data comparing prerequisite proxies against real TID-CMM scores would settle it.

4. **A8 (OT/ICS) depth.** OT response differs enough — safe-state, manual fallback, no reimaging — that it may warrant its own sub-capability set rather than being a column. D3FEND now maintains a distinct OT domain, which supports splitting it.

5. **Breakout time source.** Where an organisation has no actor-specific breakout intelligence, the model needs a defensible default. Proposal: use published industry breakout figures as a fallback with an explicit "estimated" flag, and never allow an L4 claim on estimated tempo.

6. **MTTDecide instrumentation.** Many case systems cannot distinguish "alert validated" from "containment authorised" without process change. The tool should ship guidance on instrumenting this, because the metric is only as good as the timestamp discipline.

7. **R1 dominance.** Validation (§8.8) shows R1 binding six of eight domains and subsuming R2 and R4 entirely. This is inherited behaviour — TID-CMM's C1 has the same property — and it is directionally the model's argument. But it is worth testing whether a ceiling of RV + 1.5, or exempting RP from R1, produces a more diagnostically useful spread without weakening the honesty mechanism. The independent-effect reporting rule mitigates but does not resolve this.

8. **Worked example publication.** §8.8 is a validation trace, not a published worked example. v0.2 needs the practitioner-facing version with the full 58-item score sheet and lattice, matching the presentation of TID-CMM's.

---

## 15. Immediate build sequence

| # | Artefact | Depends on |
|---|---|---|
| 1 | **This specification, reviewed and settled** | — |
| 2 | Machine-readable model (`tir-cmm-model.yaml`) | 1 |
| 3 | Worked example with full constraint trace | 2 |
| 4 | Assessment tool — single-file, client-side (`/assess`) | 2, 3 |
| 5 | Excel workbook with live formulas | 2, 3 |
| 6 | White paper | 1, 3 |
| 7 | Sites: `tir-cmm.com` (model) + `tir-cmm.xyz` (tool) | 4, 6 |
| 8 | TID-CMM v1.3 bridge update | 1 |
| 9 | UTIOM roadmap tool integration | 4, 8 |

---

*TIR-CMM is a module of UTIOM. It measures whether an organisation can act on what it detects, inside the time the adversary allows, with the authority to do so — and whether it can prove it.*