What TID-CMM measures
TID-CMM measures whether detection is driven by adversary behaviour, whether the telemetry exists to see that behaviour, and whether any of it has been proven to work. It does not measure how many rules you run.
The question the model exists to answer
Against the adversaries most likely to attack us, what proportion of their behaviour would we actually see — and how do we know?
Most security operations functions cannot answer it. The metrics normally reached for do not: a rule count measures activity, an alert volume measures noise, and a percentage of the ATT&CK matrix measures a mapping exercise against a catalogue that was never a requirements list. All three can improve while the answer gets worse.
What it measures instead
Three things, in the order they depend on each other.
Intent
Whether detection is directed by a prioritised threat profile and a model of how those adversaries would move through your architecture — rather than by whatever the tooling shipped with.
Visibility
Whether the telemetry exists, estate-wide and healthy, to record the behaviours that profile implies. Computed against the log sources ATT&CK's own analytics require, not asserted.
Proof
Whether the detection has been executed against and observed to fire, within a recency window — rather than assumed to work because a rule exists.
Three design decisions
Adversarial validation is a first-class domain
Atomic testing, breach and attack simulation, threat-actor emulation, purple teaming, penetration testing and red teaming are scored together as the evidence engine of the model — not as a footnote under testing. It is the domain that turns a claim into a fact, and it caps every other domain.
Threat modeling and attack path analysis is a first-class domain
Threat intelligence tells you what an adversary does in general. Attack trees and computed attack paths tell you what that behaviour looks like against your architecture, your identities and your crown jewels. Without that step, ATT&CK coverage is a generic checklist.
The assessment cannot flatter itself
Five integrity constraints are applied mechanically at scoring time. None can be argued with in a review, and none can raise a score. The five constraints.
Proportionality
The model is not one size. An applicability profile is derived from the environment you declare: a small organisation with no SOC is assessed against 22 essential sub-capabilities, a mid-sized one against 50, a large regulated enterprise against all 58. Choosing a lighter profile than your environment derives is allowed, and the model records the challenge rather than blocking it.
What it is not
- Not a certification. Assessments are self-declared and there is no accrediting body.
- Not a replacement for SOC-CMM, NIST CSF 2.0 or CTEM. It answers a different question, and maps to them — see below for exactly how far each mapping goes.
- Not a product requirement list. Where a capability needs tooling, the model names the class of tool and a free route to the same telemetry.
How far each mapping actually goes
Two of these are formal crosswalks: a mapping recorded on every one of the 58 sub-capabilities, machine-readable, and shipped in the datasets. The rest are comparative — they explain how TID-CMM relates to the framework without claiming a per-control mapping that does not exist. Both are useful; conflating them is how a maturity model acquires a reputation it cannot defend.
| Framework | Relationship | Coverage | What it means |
|---|---|---|---|
| NIST Cybersecurity Framework 2.0 | Formal crosswalk | all 58 | Every sub-capability names the CSF 2.0 subcategories it evidences. Use it to report detection maturity inside an existing CSF programme. |
| SOC-CMM v2.x | Formal crosswalk | all 58 | Every sub-capability names the SOC-CMM domain and aspect it corresponds to. SOC-CMM assesses the SOC as an operating unit; this asks whether it would see the adversary. |
| ISO/IEC 27001:2022 Annex A | Referenced | 1 of 58 | Referenced where an Annex A control maps cleanly, principally A.8.16. |
| Gartner Continuous Threat Exposure Management | Comparative positioning | 2 of 58 | CTEM asks whether an exposure is exploitable; TID-CMM asks whether the exploitation would be seen. |
| Elastic Detection Engineering Behavior Maturity Model | Comparative positioning | 1 of 58 | DEBMM covers engineering practice; TID-CMM covers whether that practice is aimed at the right adversary and proven against them. |
| MITRE Engage | Referenced | 1 of 58 | Supplies the placement and operationalisation vocabulary used by AA.7. |
| MITRE D3FEND | Not mapped | — | Listed in earlier releases as a crosswalk. No sub-capability carries a D3FEND mapping, so it is recorded here as unmapped rather than claimed. |
Counted from the model YAML when this page was built, so it cannot drift from what the datasets contain.