Maturity

What it is

Maturity tracks how far along your program is against named, published maturity frameworks — C2M2, CISA's Zero Trust Maturity Model, CIS Controls Implementation Groups, and others — on their own ordinal scales (Tier 1→4, IG1→IG3, MIL0→3), current vs. target, per model. It is a separate system from the Posture Score: Posture Score is CMDash's own A–F signal blend, updated continuously; Maturity is program-level positioning against external, citable frameworks that a board or an auditor already recognizes, updated by snapshot.

Seven built-in models ship in the gallery, each with a mandatory provenance block (publisher, source document, license) shown before you adopt it: Cybersecurity Capability Maturity Model (C2M2) (U.S. Department of Energy, MIL0–MIL3, ten domains), CISA Zero Trust Maturity Model 2.0 (Traditional→Optimal), CIS Controls v8.1 Implementation Groups (Center for Internet Security, IG1→IG3, mapped across the 18 CIS Controls), NIST CSF 2.0 Implementation Tiers (Tier 1 Partial→Tier 4 Adaptive), and three CMDash-published models — Human Risk Maturity, Identity & Access Posture Maturity, and Resilience Maturity — carrying the same provenance format as the external ones.

When to use it

Use Maturity when a board, a customer, or an assessor wants your program positioned against a named framework they already recognize — C2M2 for an energy-sector customer, Zero Trust Maturity Model for a federal one — rather than (or alongside) CMDash's own Posture Score. Enable a model, confirm the seeded baseline, and set target levels per dimension; the roadmap view then turns the gap into an ordered plan. Use the four specialized modules below (ATT&CK coverage, Detection mapping, Vuln SLA, Human risk by BU) when you need a deeper, telemetry-backed view of one specific maturity concern rather than the general current-vs-target ladder.

Before you start

Enabling a model runs a one-time baseline seed from the control evidence you already have in CMDash — it does not ask you to fill in a maturity ladder from scratch. Every seeded dimension is labelled SEEDED — "derived from your controls, confirm", a distinct, weaker status than ATTESTED, OBSERVED, or VALIDATED.

How to

Enable a model and confirm the baseline

1. Go to Overview → Maturity. Review a built-in model's provenance (publisher, source document, license) before enabling it — these are shown up front, not buried in a drill-down.
2. Click Enable. CMDash seeds a one-time baseline from your existing control evidence; every seeded dimension shows the amber SEEDED badge until you (or an ADMIN+) confirm or correct it.
3. Open a dimension's drill-down to see exactly which controls fed a SEEDED value, their status at seed time, the weight each contributed, and whether it arrived directly or through a crosswalk chain.
4. Set a target level per dimension. The overall rollup number is withheld, not faked, below 50% dimension coverage — a freshly-enabled model that has only assessed a handful of dimensions shows those honestly rather than headlining a composite score too early.

Read the ladder, the cap, and an exception

• An effective-ordinal cap: a dimension can show "current: Level 3" while its effective level is capped lower (a small amber dot on the ladder) when something constrains it below what the raw evidence alone would claim — the cap indicator sits next to the level it applies to, never silently absorbed into the number.
• A dimension under an active exception (accepted risk) renders as a visible chip — "Excepted — <reason>, expires <date>" — linking to Exceptions, never as a blank row indistinguishable from an unassessed one.

Capture and compare snapshots

1. Snapshots are immutable and captured automatically on a nightly cadence, plus on demand with Capture snapshot.
2. Open History on a model to see the rollup trend over time and a side-by-side before/after comparison between any two snapshots.

Generate and read the roadmap

1. Open Roadmap on an enabled model for a fully deterministic, ordered improvement plan built from your current-vs-target gaps — no AI in the critical path.
2. Every ranked item cites its own gap ("current → target") and, where relevant, a cost-source citation into the Landscape atlas, rendered verbatim rather than paraphrased.
3. Dimensions under an active exception are listed separately, under "Accepted risk," rather than folded into the ranked plan.

Build a custom model

1. Go to Maturity → Custom Maturity Model Builder (OWNER/ADMIN only) when none of the seven built-ins fits your program.
2. Define your own levels and dimensions. A saved custom model appears in the main gallery alongside the built-ins.

Use the group/portfolio rollup

1. OWNER/ADMIN on a multi-entity or MSP account can open Maturity → Group rollup to see each child organization's own maturity aggregated into per-entity cards plus a group total.
2. This view adds no scoring of its own — every number is reused verbatim from that child's own Maturity page.

Use the four specialized modules

Each renders an unknown or unmapped state as its own distinct state — never collapsed into a zero or a green checkmark:

• ATT&CK coverage (Maturity → ATT&CK coverage) — a heatmap of MITRE ATT&CK techniques against your controls and detections. Every cell renders one of four states, not three: covered, partial (mapped but not satisfied — claimed but not implemented, no fresh detection covers it), and uncovered, itself split into two shades — a technique no control has ever claimed, versus one that is claimed but unmet.
• Detection mapping (Maturity → Detection mapping) — a human review queue for detection rules (Sentinel analytics rules, Splunk correlation searches, Elastic detection rules) a sync could not confidently technique-tag from vendor metadata alone. Each row shows why it's queued and offers an AI-assisted or heuristic guess for your confirmation — never applied silently.
• Vulnerability management SLA maturity (Maturity → Vuln SLA) — a percentile-based drill-down of how consistently your program closes vulnerabilities within SLA, always shown with its source(s), data freshness, and the full table of vulnerabilities the aggregate was computed from.
• Human risk by business unit (Maturity → Human risk by BU) — a per-business-unit breakdown of the Human Risk model's signals. A business unit small enough that naming its score would be identifying renders as a full row reading "Suppressed for privacy" with the exact reason — never omitted, never a bare 0.

Common questions

Does Maturity replace the Posture Score? No. They are separate systems with no shared scoring. Posture Score is CMDash's continuously-updated A–F blend; Maturity is program-level positioning against external, citable frameworks, updated by snapshot.

Does Maturity affect my CMMC, NIST, or other compliance framework tracking? No — see Compliance Frameworks. The two systems share no scoring and answer different questions.

Can I compare an ordinal across models — is MIL2 the same as IG2? No. A model's ordinal is not comparable across models — MIL2 on C2M2 and IG2 on CIS Controls measure different things on different scales, and CMDash does not attempt to normalize them into one number.

Are the roadmap's cost citations a quote? No. Every cost figure the roadmap cites into the Landscape atlas is a reference range for a planning conversation, not a vendor quote.

Related

• Posture Score
• Landscape
• Exceptions
• Planning, Budget, and Initiatives