TIR-CMM vs NIST SP 800-61r3 — process guidance against a response measurement instrument

NIST SP 800-61 Revision 3, published April 2025, is process guidance restructured as a CSF 2.0 Community Profile — it tells you what incident response should achieve. TIR-CMM is a measurement instrument with 8 domains, 58 sub-capabilities and a 0–5 scale. Neither replaces the other. r3 carries no scores; TIR-CMM carries no procedures.

What is NIST SP 800-61r3?

NIST SP 800-61 Revision 3 is titled Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST published it in April 2025, with the release announced on 3 April 2025, under DOI 10.6028/NIST.SP.800-61r3. Authors are Alexander Nelson, Sanjay Rekhi and Murugiah Souppaya of NIST with Karen Scarfone of Scarfone Cybersecurity. Revision 3 supersedes SP 800-61 Revision 2, Computer Security Incident Handling Guide, published August 2012 and formally withdrawn on 3 April 2025 — a gap of nearly thirteen years between revisions.

Revision 3 is short and structural. Three numbered sections carry it: §1 Introduction, §2 Incident Response as Part of Cybersecurity Risk Management and §3 CSF 2.0 Community Profile for Cyber Incident Risk Management, with §3 splitting into §3.1 Preparation and Lessons Learned and §3.2 Incident Response. Three appendices follow — acronyms, glossary and a change log.

The substance of r3 sits in two tables. Table 2, the Community Profile part 1, covers the GOVERN, IDENTIFY and PROTECT Functions. Table 3, part 2, covers DETECT, RESPOND and RECOVER. Each row pairs a CSF 2.0 element and its description with a priority rating and a column of recommendations, considerations and notes. Priorities are three-valued: High means the element "functions as a core incident response activity for most organizations," Medium means it "directly supports incident response activities for most organizations," and Low means it "indirectly supports incident response activities for most organizations."

What changed from Revision 2, and why it matters

Revision 2 organised incident response as a four-phase circular life cycle: Preparation → Detection and Analysis → Containment, Eradication and Recovery → Post-Incident Activity. Revision 3 abandons that model. The r2 life cycle survives in r3 only as Fig. 1, labelled "Previous incident response life cycle model," and is replaced by Fig. 2 — "a high-level incident response life cycle model based on the six CSF 2.0 Functions, which organize cybersecurity outcomes at their highest level."

NIST explains the change in §2.1 by describing the conditions r2 was written for: "At that time, incidents were relatively rare, the scope of most incidents was narrow and well-defined, and incident response and recovery was usually completed within a day or two. Under those conditions, it was realistic to treat incident response as a separate set of activities performed by a separate team of personnel and to depict all incident response activities as part of a circular life cycle." Those conditions no longer hold, and r3 says so directly: incidents now occur frequently, cause far more damage and take weeks or months to recover from.

The new figure is not a relabelled circle. GOVERN, IDENTIFY and PROTECT sit on a bottom level, and r3 states that "the preparation activities of Govern, Identify, and Protect are not part of the incident response itself." DETECT, RESPOND and RECOVER form the incident-handling level, with continuous improvement running across the model rather than sitting at the end as a fourth phase. Describing r3 as though it still ran Preparation → Detection & Analysis → Containment/Eradication/Recovery → Post-Incident Activity is the single most common error made about the document, and it inverts its central design decision.

What Revision 3 deliberately is not

Revision 3 dropped almost all of r2's procedural detail on purpose. NIST states the reason plainly: "Because the details of how to perform incident response activities change so often and vary so much across technologies, environments, and organizations, it is no longer feasible to capture and maintain that information in a single static publication." Where r2 was a long handbook of attack vectors, checklists and sample scenarios, r3 is a compact profile pointing at CSF 2.0 outcomes and externally maintained references.

Revision 3 also contains no maturity model, no capability levels, no scale and no scoring arithmetic. The only ordinal in the document is the High / Medium / Low priority column, and priority ranks how central an element is to incident response for most organisations — not how well any given organisation performs it. Nothing in r3 lets two organisations produce comparable numbers, and r3 does not claim otherwise.

What does TIR-CMM measure?

TIR-CMM measures whether an organisation can actually stop an intrusion in time, and whether it can prove it. The model holds 8 domains with weights summing to 100 — RP Response Preparation & Readiness (10), RA Response Authority & Decision Rights (12), RE Response Engineering & Playbooks (16), CE Containment, Eradication & Recovery (14), AO Automation & Orchestration (12), FI Forensics, Evidence & Investigation (10), RV Response Validation & Exercising (14) and RG Response Governance, Metrics & Improvement (12). Under those domains sit 58 sub-capabilities scored 0–5, rolling into six bands from L0 Improvised to L5 Adaptive.

Three mechanisms give the score its teeth. The Containment Lattice crosses 8 attack-path stages against 8 asset classes for 64 cells, of which a typical scope is 24–38, each scored 0 to 3 for no option, manual only, engineered or proven. Scoring and constraints applies seven integrity constraints R1–R7 which only ever lower a score. Evidence acts as a ceiling rather than a conversion: VC0 assertion caps a sub-capability at 1, VC1 design at 2, VC2 implemented and tested at 4, VC3 repeatably validated at 5.

The distinctive measurement is temporal. TIR-CMM records MTTDecide — the interval between knowing and being authorised to act — separately from MTTR, on the argument that most of the loss sits in that interval and disappears once folded into a single figure. Tempo Ratio sets MTTD + MTTDecide + MTTC against a priority actor's breakout time; constraint R5 caps the band at L1 at a ratio of 2.0 or worse and at L2 at 1.0 or worse, and L4 and L5 are unreachable without supplied tempo evidence.

TIR-CMM vs NIST SP 800-61r3 at a glance

Do they overlap?

Overlap is real and TIR-CMM's standards alignment page maps it at domain level: RP to r3's preparation material under GOVERN, IDENTIFY and PROTECT, RA to governance and roles, RE and AO to response execution, CE to containment, eradication and recovery, FI to analysis, RV and RG to continuous improvement. Those groupings follow r3's own split between §3.1 and §3.2 rather than r2's phases.

The overlap is subject-level, not functional. Revision 3 names the outcomes and priorities that incident response should deliver, then hands the organisation a table of recommendations. TIR-CMM takes the same subject matter and asks how far along each outcome you actually are, on a defined scale, with a defined evidence standard, checked by constraints that cannot be argued with. A row in r3 Table 3 marked High priority and a TIR-CMM sub-capability scored 2 at VC1 evidence describe the same capability from opposite ends — what it should be, and what it demonstrably is.

TIR-CMM also treats r3 as an input rather than a competitor. Revision 3 is one of four anchors named in the specification — alongside MITRE D3FEND 1.5.0, RE&CT with its RA1000–RA6000 stages and over 300 response actions, and ATT&CK Mitigations — and its stated role is the governance crosswalk. Following r3 rather than r2 is a deliberate choice in the model, because a response maturity model built on the 2012 four-phase lifecycle inherits an incident shape that NIST itself has retired.

Where NIST SP 800-61r3 is stronger

Revision 3 is stronger wherever institutional weight matters. NIST is a federal standards body, r3 went through a public draft and comment cycle before its April 2025 release, and it carries a DOI and four named authors. Auditors, regulators and insurers recognise SP 800-61 by number, and many contractual clauses cite it directly. TIR-CMM is v0.2, authored by one person at UTIOM, with no standards body, no adoption claim and no external validation. Citing r3 in a board paper needs no explanation; citing TIR-CMM does.

Revision 3 is also broader on preparation and governance than TIR-CMM's response focus allows. Table 2 spans GOVERN, IDENTIFY and PROTECT where TIR-CMM's RP domain covers readiness in 7 sub-capabilities and stops. Revision 3 connects incident response to the whole cybersecurity risk management programme — the framing its title carries, and one TIR-CMM does not attempt.

Durability is r3's third advantage. Deferring volatile procedural detail to external references means r3 should age far better than r2 did over thirteen years, and a maturity model at v0.2 has no comparable track record.

Use SP 800-61r3 instead of TIR-CMM if you need authoritative guidance on what an incident response programme should contain, a document to cite in policy or contract, a structure that connects response to the wider risk programme, or a reference an auditor will accept without argument. TIR-CMM will not serve any of those purposes.

Where TIR-CMM is stronger

TIR-CMM is stronger on measurement, and only on measurement. Revision 3 gives no way to answer "how good are we." An organisation can adopt every High-priority row in Tables 2 and 3 and have no defensible statement about its own capability, because r3 supplies no scale, no evidence standard and no arithmetic. TIR-CMM supplies all three, and the constraints exist specifically to stop a self-assessment flattering itself: R1 holds every domain except RV to no more than RV + 1, R2 holds AO and CE to no more than RA + 1, R7 caps a Pulse assessment at L3 and any self-assessment without independent calibration and separation of assessor from approver at L4.

Speed against the adversary is the second axis, and r3 has no counterpart. Nothing in the document measures duration or compares response time against attacker tempo. TIR-CMM's Containment Margin subtracts MTTD + MTTDecide + MTTC from a priority actor's breakout time, and the model refuses an L4 claim without measured MTTDecide. Response authority is the related gap: r3 covers roles and responsibilities, but no framework in TIR-CMM's crosswalk measures decision rights, which is why RA carries a 12% weight of its own.

Perishability is the third. TIR-CMM expires a proven lattice cell after 12 months, and immediately on EDR swap, SOAR migration, IdP change, on-call change, owner departure, material architecture change or a change of managed provider. Guidance does not decay; capability does.

Can I use both?

Using both is the intended configuration. Revision 3 defines what incident response should achieve and how it fits cybersecurity risk management; TIR-CMM measures whether yours achieves it and how fast. TIR-CMM names r3 as its governance anchor, so the two align by construction rather than retrofit.

If you already run r3, here is where TIR-CMM slots in

Start from r3's Table 3 and take every row you have marked High priority under DETECT, RESPOND and RECOVER. For each, TIR-CMM asks the question r3 leaves open: at what evidence level, at what assessment depth, proven when, and inside whose breakout window. Run a Baseline assessment — 1–2 hours, all 58 sub-capabilities with evidence levels, the lattice scoped to your crown jewels, the authority map and response tempo — and read the output as a measured answer against your r3 adoption.

Three handoffs are worth setting up. Revision 3's containment and eradication material has a counterpart in the lattice blind-cell count, which names the stage-and-asset combinations where no option exists at all. Revision 3's escalation and roles guidance becomes measurable once MTTDecide is recorded, and R2 will show whether authority is the ceiling on your automation. And r3 places continuous improvement across the whole model rather than at the end, which maps onto RV and RG at 14% and 12% of the weight and onto R1, the rehearsal ceiling that usually turns out to be binding.

Which should you run?

If you do not yet have an incident response programme, read SP 800-61r3 first. A measurement instrument applied to nothing returns L0 and tells you what you already knew. Revision 3 will tell you what to build, and its High-priority rows are a reasonable build order.

If you have adopted r3 and want to know whether adoption produced capability, run TIR-CMM. That gap — adopted on paper, unproven under a clock — is the exact condition the model was written to expose, and r3 has no mechanism that would surface it.

If you need a document to cite for policy, contract or audit, cite SP 800-61r3 and do not substitute TIR-CMM. TIR-CMM carries no certification, no accreditation and no institutional backing, and a v0.2 model from a single author will not stand in for a NIST Special Publication.

If your question is "could we actually stop it, and are we faster than the adversary," run TIR-CMM. Revision 3 does not answer that question and does not claim to. Take Pulse at 20 minutes for the shape of the answer or Baseline at 1–2 hours for one you can defend, and check unfamiliar terms in the glossary. Both frameworks are free, and running one does not cost you the other.