Step 7 — detection and validation
Per in-scope technique: is a detection deployed, is its telemetry healthy, and has it been executed against and observed to fire within your stated window?
What this step establishes
The telemetry step establishes what you could see. This step establishes what actually fires, and what has been proven to fire. For every in-scope technique, Tier A first, the tool records the detection or analytic name, its rule identifier, whether it is deployed and enabled, the health of the telemetry it depends on and when that was last checked, where its alerts go, who owns it, when it was last validated and how, what the test showed, the named evidence artefact, and any notes or exceptions. Two optional fields carry the model’s own vocabulary: the detection class (decisive, corroborative, or hunting and context) and, for a 0 or a 1, whether that is a gap or by design.
How the answers are read
The tool reads the register with the meaning the Validated Coverage Score already gives each status. Nothing new is scored.
| Status | Meaning | What the register must contain |
|---|---|---|
| 0 | The required activity is not sufficiently observable | An answer exists and the technique’s required sources reach 0% of the estate on the telemetry step, or its telemetry is recorded as failed. A detection recorded against it is flagged, not counted: it cannot fire. |
| 1 | Telemetry visibility exists, but deployed detection is not evidenced | Reach above 0%, and any of: no detection deployed, deployed but not enabled, telemetry health failed or not checked, no named artefact, or a validation that showed the detection did not fire. |
| 2 | Functioning detection logic is deployed and evidenced | Deployed, enabled, telemetry healthy (degraded is flagged), and a named evidence artefact. Not validated within the window, or validated with a method or outcome missing. |
| 3 | Locally validated under the model’s evidence and recency requirements | Everything a 2 needs, plus a validation date inside the stated recency window, a qualifying controlled adversarial method (atomic test, adversary emulation, purple-team exercise, breach and attack simulation, red-team exercise, or a penetration test where the exact behaviour and the resulting detection are evidenced), and an outcome of fired as expected. A production true positive is recorded as valuable operational evidence but stays at 2, because the model defines 3 as validation by adversarial emulation; an unreviewed “other” method also stays at 2. |
| Not assessed | No answer recorded | The technique has no deployed / not deployed answer. It is shown as not assessed and is never converted into a 0 or a 1 — even where telemetry assurance reports the technique as blind. The two facts are shown side by side: the telemetry finding (required reach 0%) and the register finding (not assessed until an answer is recorded). |
What never earns a 2 or a 3. A telemetry source existing; a vendor saying it detects the technique; a product having taken part in ATT&CK Evaluations; a maturity question scored highly; a rule name without an artefact; evidence fields left empty. The register asks for the artefact because the artefact is the claim.
Order of reading. No deployed answer → not assessed. An answer with required telemetry reach of 0% → status 0. Only then do statuses 1 to 3 apply. The TIR-CMM export keeps carrying telemetry-derived 0 or 1 for techniques without register evidence, which is the established integration behaviour; exported telemetry status and register completeness are two different readings and the export’s notes say so.
Status 3 expires. The model requires a stated recency window and does not fix one; the tool records yours (180 days by default, 30 to 730) and applies it to every validation date. A validation outside the window keeps the technique at 2 and says so; it is never shown as current.
Working through 150 to 250 techniques
- Tier A first. The register opens on the techniques you marked as sitting on a path to a crown jewel. Tier B, Tier C and the whole set are one filter away, with a status filter and a search box.
- Results before completeness. Nothing here blocks the results page. Unanswered techniques are counted as not assessed in every view, and the Validated Coverage Score is reported only when every in-scope technique has an answer, because its denominator is the in-scope set.
- Bulk updates, where the evidence is genuinely shared. Select the techniques one exercise covered and apply the shared date, method, outcome, owner and artefact at once. A shared artefact is required before deployed or validation fields are applied in bulk; blank fields are left alone.
- Import and export. The register exports as CSV and imports the same columns back. The format is documented on the data model page and is the workbook’s
Detection registertab, column for column, so a register kept in a spreadsheet can be brought in rather than retyped.
What it feeds
The technique-assurance distribution and the Tier A path strip in Assurance at a glance; the detection status of each scenario step on the scenarios step; the detection and validation gaps card on the roadmap; and, only where the evidence meets the definitions above, per-technique status 2 or 3 in the TIR-CMM export. It changes no maturity score, no weight and no constraint.