UTIOM, the Unified Threat-Informed Operations Model, holds that everything a security operations function does is incident response, and that detection is its first phase. TID-CMM is its detection module; TIR-CMM, the Threat-Informed Response Capability Maturity Model, is its response module and is published at tir-cmm.com.

If TIR-CMM exists, why does TID-CMM have an incident response domain?

Because the handoff belongs to both and to neither. The IR domain here measures the detection side of the interface — whether an alert reaches a responder reliably at any hour, and whether incidents feed back into detection — and it carries the lowest weight in the model at 10%. It is not a response capability assessment. TIR-CMM measures response itself across its own 58 sub-capabilities, consumes your detection maturity as an input constraint, and holds no detection domain at all. Run TID-CMM for whether you would see it, TIR-CMM for whether you could stop it.

TID-CMM was created and is maintained by Reza Adineh, a SOC architect. It takes no vendor funding and names no product as a requirement.

Home › About

About TID-CMM

TID-CMM is the detection module of UTIOM, created and maintained by Reza Adineh. Published model, reference data, a free official assessment tool, and no certification scheme.

TID-CMM is a capability maturity model for threat-informed detection, created and maintained by Reza Adineh. It measures whether an organisation's detection is driven by the behaviour of the adversaries most likely to attack it, whether the telemetry exists to see that behaviour, and whether any of it has been proven to work.

Think smarter, Stay Secure.

Where it came from

The model was first drafted in 2022, out of a recurring argument in security operations that never resolved: a detection programme could report rising coverage every quarter while nobody could say what it would actually catch. It was developed and used privately for four years before its first public release in August 2026.

That gap is worth stating plainly. Four years of private use is not the same as four years of independent scrutiny — the descriptors have been argued over by people who ran them, but the model has not yet been tested against organisations that had no hand in writing it. The weights in particular are a considered judgement, not an empirical finding, and the first sector benchmark data will almost certainly move some of them.

Why it exists

Most organisations cannot answer a simple question about their own security operations: against the adversaries most likely to attack us, what proportion of their behaviour would we actually see, and how do we know?

The metrics normally used to answer it do not. A rule count measures activity, not capability. An alert volume measures noise. A percentage of the ATT&CK matrix measures a mapping exercise against a catalogue that was never a requirements list. All three can rise while the answer to the question gets worse.

The model exists because that gap is not a measurement problem, it is an incentive problem. Every one of those metrics rewards the appearance of coverage, and none of them can distinguish a rule that has never fired on a true positive from a detection proven to catch a real intrusion in minutes. TID-CMM is an attempt to build a measurement that cannot be improved without the underlying capability improving.

Where it sits — UTIOM

TID-CMM is the detection module of UTIOM, the Unified Threat-Informed Operations Model.

UTIOM starts from a position that sounds provocative and turns out to be practical: everything a security operations function does is incident response. Detection is not a separate discipline that hands over to responders — it is the first phase of the response process, and the quality of everything downstream is bounded by it. You cannot respond to what you never saw, you cannot scope an incident with telemetry you never collected, and you cannot prioritise a response against a threat model you never built.

That framing has a consequence for how the phases are assessed. They cannot be assessed as if they were independent, because they are not. TID-CMM covers the detection phase in full, and it exists as a separate model rather than a chapter because the detection phase is where most programmes actually fail and where the most work lives.

TIR-CMM — Threat-Informed Response Capability Maturity Model — completes the pair. It covers what happens after a true positive: containment authority, blast radius, response tempo measured against adversary breakout time, and whether any of it has been rehearsed. TID-CMM asks whether you would see it. TIR-CMM asks whether you could stop it. Together they cover the operations lifecycle UTIOM describes.

RSMM — the platform underneath

RSMM, the Realistic SIEM Maturity Model, is the third model in the family and the one this model most often ends up pointing at. In UTIOM’s own words it covers “SIEM platform & operations — whether the platform detection runs on reliably serves the operation”. It is staged rather than averaged across five levels — Blame Collector, Alert Factory, Use Case Island, Detection Pipeline, Outcome-Driven SIEM — over dimensions covering data utility, detection content, alert quality, threat intelligence, engineering process and measurable outcomes, with cost and data economics, search and investigation experience, and portability and lock-in as extended dimensions. Its own description of the gating: “a level counts only when everything below it is satisfied too”.

The two models keep separate identities, separate scopes, separate versions and separate scores. TID-CMM assesses the detection capability — intent, visibility, evidence — whatever platform it runs on. RSMM assesses the platform and the operation around it. Neither substitutes for the other, and neither number converts into the other.

Where the two meet in practice

Operational relationship — not a formal crosswalk and not a score conversion. No sub-capability of this model maps to an RSMM level or criterion, and no RSMM result is read into a TID-CMM score, or the reverse. What follows is only the handoff people actually make between the two assessments.

A TID-CMM finding	What it becomes for RSMM	Direction
Required log sources are missing or unhealthy, so techniques read as blind or weak	A data utility requirement on the platform: the sources have to be onboarded, parsed and kept healthy before detection content can be written against them	TID-CMM → RSMM
Detections exist but are not evidenced or not validated	A detection content and engineering process requirement: content lifecycle, testing and the pipeline that carries a rule from idea to production	TID-CMM → RSMM
Detections fire but the output is not usable — volume, duplication, no context	An alert quality requirement, which is where RSMM measures whether the platform serves the operation	TID-CMM → RSMM
A platform limitation — retention, search, ingestion cost, lock-in — that prevents telemetry being collected or queried	Already an RSMM concern (data utility, cost and data economics, search and investigation experience, portability and lock-in); in TID-CMM it appears as the constraint that keeps a telemetry or detection score where it is	RSMM → TID-CMM

Read it in one direction at a time. A weak platform constrains what detection can achieve, and a detection assessment names the platform work that would lift the constraint — but a TID-CMM score is never raised because RSMM says the platform is good, and an RSMM level is never awarded because TID-CMM says detection is mature.

Why there is an IR domain here at all

A reasonable objection: if a whole model now measures response, why does this one still contain an incident response domain?

Because the interface between them is a real capability that neither model owns by default, and it is where the most avoidable failures happen. An alert that fires correctly into a queue nobody watches at 03:00 is a detection failure, not a response failure — the detection worked and the outcome was identical to having no detection at all. Equally, an incident that teaches the organisation nothing because no one asked "why did we not see this sooner?" is a detection failure that only becomes visible after the response is over.

So the IR domain here is deliberately narrow. It measures the detection side of the handoff: whether alerts reach a responder reliably at any hour, whether the path is measured, and whether every incident feeds back into the detection backlog. It carries the smallest weight of any domain at 10%, and it is not a response capability assessment.

TIR-CMM is the response capability assessment, across its own 58 sub-capabilities and its own containment lattice. It contains no detection domain at all — it consumes detection maturity as an input constraint, which is precisely what keeps the two complementary rather than overlapping. Run TID-CMM first if you are unsure; TIR-CMM will import its export.

Known overlap, stated rather than hidden. Four of the six IR sub-capabilities here — response planning, forensic readiness, containment and recovery, and exercising — reach further into response than the narrow framing above strictly justifies, and TIR-CMM now measures all four in far more depth. Narrowing this domain to the handoff alone is an open proposal for the next major version. It is recorded here because a maturity model that cannot name its own unresolved boundary is not holding itself to its own standard.

What it is not

It is not a certification scheme. Assessments are self-declared, there is no accrediting body, and any claim of a "certified TID-CMM level" should be treated as marketing.

It is not a replacement for the frameworks already in use. SOC-CMM assesses the SOC as an operating unit; TID-CMM asks whether it would see the adversary. NIST CSF 2.0 is the reporting layer, and every sub-capability crosswalks to it. Gartner's CTEM asks whether an exposure can be exploited; this asks whether the exploitation would be seen.

It is not a benchmark, yet. There is no sector data, because nobody has contributed any. That is the most useful thing an organisation could offer the model.

Who it is for

Detection engineers and detection leads, who get a structure for arguing about priorities with something other than opinion. SOC managers, who get a defensible answer to what the next investment should be. CISOs, who get a number that will not embarrass them when somebody tests it. Purple teams, who get their findings placed in a model where they change the score.

It is deliberately proportionate. A small organisation with no SOC is assessed against 22 essential sub-capabilities, not all 58 — the profile is derived from the environment declared, so the burden matches the estate.

Licence and independence

Three things ship under this project and “free to use” means something different for each, so the distinction is stated plainly rather than collapsed into “free and open”.

The published model — domains, sub-capabilities, level descriptors, weights, evidence criteria, crosswalks and scoring rules — and the reference datasets — the derived ATT&CK datasets, telemetry catalogue and schemas — are publicly accessible, and free to use only within the permissions on the licence page: assess with them, cite them and quote them with attribution. Public availability does not make them open source or openly licensed. Republishing them, publishing a derivative of them, or embedding them in another product needs written permission.

The free official assessment tool — the browser tool, its offline build and the Excel workbooks — is free for any use, explicitly including paid client assessment work, and needs no permission for that. It is not open source and is not licensed for redistribution or derivative tooling. A consultancy may assess its clients with it and charge for the engagement; it may not ship the tool as its own product.

The project takes no vendor funding and names no product as a requirement. Where a capability needs tooling, the model names the class of tool and a free route to the same telemetry, because "buy this" is not a maturity model.

Common questions

What is UTIOM?: UTIOM, the Unified Threat-Informed Operations Model, holds that everything a security operations function does is incident response, and that detection is its first phase. TID-CMM is its detection module; TIR-CMM, the Threat-Informed Response Capability Maturity Model, is its response module and is published at tir-cmm.com.
If TIR-CMM exists, why does TID-CMM have an incident response domain?: Because the handoff belongs to both and to neither. The IR domain here measures the detection side of the interface — whether an alert reaches a responder reliably at any hour, and whether incidents feed back into detection — and it carries the lowest weight in the model at 10%. It is not a response capability assessment. TIR-CMM measures response itself across its own 58 sub-capabilities, consumes your detection maturity as an input constraint, and holds no detection domain at all. Run TID-CMM for whether you would see it, TIR-CMM for whether you could stop it.
Who created TID-CMM?: TID-CMM was created and is maintained by Reza Adineh, a SOC architect. It takes no vendor funding and names no product as a requirement.