Home › Methodology › Scoring

Scoring reference

The weighted rollup, the order constraints are applied in, the Validated Coverage Score and the prioritisation arithmetic.

How TID-CMM calculates its results

One pass, in a fixed order. Every step of the calculation below is what the assessment tool and the workbooks actually do; nothing here is a second method or an approximation. The assessment shows the same calculation for your own answers: open How your result was calculated on the results screen for a per-domain trace of every weighted contribution.

1Recorded maturity answers. The level you recorded for each sub-capability, 0–5, with the evidence text you supplied.
2Applicability. A sub-capability outside your profile, or left unanswered, is removed from both the numerator and the denominator. It is not counted as zero.
3C3 — evidence ceiling. In strict mode a recorded 4 or 5 with no named artefact is counted as 3.
4C5 — inherited intent ceiling. In strict mode TI.2 is capped at 2 while the suggested adversary set has been accepted unmodified.
5Counted values. What remains after C3 and C5 is the value that enters the arithmetic.
6Weighted raw domain score. For each domain, Σ(sub-capability weight × counted value) ÷ Σ(weights of the applicable, answered sub-capabilities).
7C4 — intent ceiling. DC and DE may not exceed max(TI, TM) + 1.
8C2 — visibility ceiling. DE may not exceed DC + 1, using the DC value after C4.
9C1 — validation ceiling. No domain may exceed AV + 1, using the AV value after the ceilings above.
10Adjusted domain scores. The domain figures a report cites.
11Overall maturity. Σ(domain weight × adjusted domain score) ÷ Σ(domain weights of the scored domains). The raw overall uses the same weights over the raw domain scores.

Constraints only ever lower a score, they are applied mechanically rather than urged, and every adjustment is written into the constraint log on your result. The order matters: C4 feeds C2, and both feed C1.

Two coverage scores, on their own branches

Validated Coverage Score

Detection register → per-technique status (0 not observable, 1 visible, 2 detection evidenced, 3 validated in window) → VCS over the in-scope technique set.

Scenario Coverage Score

Scenario register → evidenced detection at two or more distinct stages with at least one locally validated → SCS over the scenarios with a valid denominator.

VCS and SCS are reported alongside maturity. Neither is averaged into the maturity score. A percentage is shown only where the denominator is valid.

Two further derived outputs

Exposure index. For each in-scope technique: ceiling = probability × impact × crown-jewel impact weight, and exposure = ceiling × (1 − visibility). The index is round(100 × Σexposure ÷ Σceiling) across every in-scope technique, including the ones you can already see. It is not part of the maturity score.
Roadmap priority. For each gap: (domain weight ÷ 100) × (sub-capability weight ÷ 100) × (target − counted) × 1000, sorted descending. It orders work; it does not change a score.

What influences what

What each thing you record actually moves. A blank cell means it has no effect on that output in the current implementation.

What you record	Maturity	Technique scope	VCS	SCS	Exposure	Roadmap	TIR-CMM export
Environment and platforms	via applicability profile	yes	yes, through scope and telemetry	yes, through scope	yes	yes	indirectly
Crown jewels	—	yes, Tier A marking	yes, through tiering	yes, scenario targets	yes, impact weight	yes	yes, with asset classes
Adversary selection	—	yes	yes, through scope	yes, through scope	yes, probability	yes	yes, names
Adversary provenance	yes, C5 on TI.2	—	—	—	—	yes, via TI.2	—
Maturity responses	yes	—	—	—	—	yes	yes, the score
Evidence text	yes, C3	—	—	—	—	yes	yes, via the score
Telemetry configuration	—	—	yes	yes	yes, visibility	yes	yes, technique status
Detection register	—	—	yes	yes, evidence basis	—	yes	yes, status 2 and 3
Scenario register	—	—	—	yes	—	yes	yes, as SC-n paths
Standards views	—	—	—	—	—	—	—
UTIOM view	—	—	—	—	—	—	—

The two views at the bottom are presentations of results you already have. They record no answer, change no number and add nothing to the export.

Rollup

domain_score   = Σ(sub_weight × sub_score) / Σ(sub_weight)     over in-scope sub-capabilities
overall_score  = Σ(domain_weight × domain_score) / Σ(domain_weight)

Sub-capabilities marked not applicable are excluded from both numerator and denominator. Scoping something out neither helps nor harms the score — it removes it.

Order of operations

The order is causal, not arbitrary: strategy directs telemetry, telemetry carries detection, and validation proves it. Each constraint caps the thing that depends on it, so they are applied in that sequence.

C3 at sub-capability level — a score of 4 or 5 with no named evidence becomes 3.
C5 at sub-capability level — TI.2 is capped at 2 while the suggested adversary set has been accepted unmodified.
Compute raw domain scores from the counted values.
C4 — cap DC and DE at max(TI, TM) + 1.
C2 — cap DE at adjusted DC + 1.
C1 — cap every other domain at adjusted AV + 1.
Compute the overall score from adjusted domain scores.
Report the unadjusted score, the adjusted score, and every adjustment.

Every constraint is a ceiling: it may lower a domain score and may never raise one. C2 in particular is measured against the already-adjusted DC, not the raw figure — against the raw figure it could restore a score C4 had just removed.

The constraints

ID	Name	Rule	Why
C1	Validation ceiling	No domain > AV + 1	An untested capability is an assumed capability. The one-level margin acknowledges a capability can be well-built before it is validated — but only just.
C2	Visibility ceiling	DE ≤ adjusted DC + 1	Detection logic cannot outperform its inputs.
C3	Evidence rule	4 or 5 without a named artefact → 3	In any process where an unevidenced claim scores the same as an evidenced one, assertion drives out evidence.
C4	Intent ceiling	DC and DE ≤ max(TI, TM) + 1	Sensors and content without architectural intent produce noise, not defence. Collecting more and writing more cannot substitute for knowing who you are defending against and how they would move.
C5	Inherited intent ceiling	TI.2 ≤ 2 where the adversary set was accepted from the suggested threat profile unmodified	TI.2 asks who you are defending against and how you know. If the tool answered it, you inherited the answer rather than producing it. A model that supplies its own input and then scores you on it is grading its own homework.

strict: false disables all of them. Use it only to see the raw self-assessment; never report a non-strict score externally.

What C5 changes in practice

C5 is the only constraint that reads provenance rather than scores. It is applied at sub-capability level, to TI.2 alone, because how the actor list was produced says nothing about the rest of an organisation's intelligence capability — capping the whole TI domain would punish capabilities the provenance is silent on.

Three values are recognised:

`actor_provenance`	Meaning	C5
`suggested`	Accepted from the suggested threat profile, unmodified	TI.2 capped at 2
`reviewed`	Suggested, then added to, removed from, or reasoned about	Not applied
`declared`	Chosen without using the suggestion	Not applied

The ceiling lifts on any engagement with the list: adding an adversary the suggestion missed, removing one that does not apply, or recording why one was accepted. All three are threat intelligence work. The constraint exists so that not doing that work cannot look identical to doing it.

What C4 changes in practice

An organisation with strong telemetry and a large rule estate, but no threat intelligence input and no attack-path modelling, is the case C4 exists for. With TI and TM at 0, both DC and DE are held at 1 however much has been spent on them. It is usually the single most uncomfortable number in an assessment, and the most useful.

Bands

Score	Band	In practice
0.00–0.99	L0 Absent	A build project, not an improvement project
1.00–1.99	L1 Ad hoc	Capability lives in individuals; it will not survive their departure
2.00–2.99	L2 Repeatable	The most populated band, and where spending most often outruns capability
3.00–3.99	L3 Threat-Informed	A credible target for most organisations
4.00–4.99	L4 Measured & Validated	Realistic only with a standing validation function
5.00	L5 Adaptive	Rare. Treat with scepticism unless the evidence is exceptional

Validated Coverage Score

VCS = Σ(status) / (3 × count(in-scope techniques))

Status	Meaning	Requires
0	No telemetry	The activity generates no record you collect
1	Telemetry only	Data exists and is queryable; nothing alerts
2	Detection logic exists	A rule or analytic is deployed and healthy, but unproven
3	Validated by emulation	Behaviour executed, detection observed to fire, within the recency window

Always report the in-scope count beside the score. Status 3 expires — a result older than your defined review window drops to 2.

Report alongside the domain scores, never instead of them.

The browser tool computes the score from its detection register only when every in-scope technique has an answer; a technique without one is reported as not assessed rather than as 0 or 1, and no partial rate is shown. The Scenario Coverage Score is applied as defined above the constraints: covered means detected at two or more distinct stages, at least one of them locally validated, and the percentage appears only over a register in which every scenario has an assessed step. Neither score is averaged into the maturity result.

Prioritisation

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

Mechanical by design: it prevents the roadmap being driven by whoever argued hardest. It produces the counter-intuitive but usually correct result that a two-level gap in a heavily weighted sub-capability outranks a four-level gap in a light one.

The ranking is a starting point, not an instruction. Dependencies matter — improving DE before fixing DC wastes effort, which is why C2 exists. Read the constraint log alongside the roadmap.

Setting targets

Set targets per domain, not globally. Defensible target for a well-resourced enterprise: 3.5–4.0 overall, with AV at 4.0+ so it stops being the binding constraint. For a smaller organisation, 2.5–3.0 over an honest, narrow in-scope set is a stronger position than 3.5 over a scope chosen to flatter.

Level 5 is not a target for most organisations. Treating it as one produces theatre.