Mountain Maturity Communication Model

What This Is For

Security maturity scores are precise for the people who built them and opaque to everyone else. A board member who hears “we’re at a 2.4, trending toward 3.0” has no framework for judging whether that’s fine or alarming. The Mountain Maturity model translates a NIST CSF-style 1–5 maturity scale into a five-stage climbing narrative that non-technical stakeholders grasp immediately, without first learning what a maturity framework is.

Use it when the audience is a board, an executive team, or anyone who needs to understand where a security capability stands and what it will cost to move it, without wanting the underlying framework explained first.

The Maturity Ladder

1 — Basecamp: Starting Location

Scope, owner, first controls, plan and timeline approved. You’ve started the climb. You’re not exposed yet, but you’re not moving.

2 — Switchbacks: Getting to Table Stakes

Hard uplift in progress; partial coverage/adoption; known gaps with owners and dates.

Signals: stabilizing to a reliable, repeatable baseline; ≥80% coverage of in-scope assets; SLAs and quarterly reporting live; at least one external validation. Examples: ISO readiness uplift (control mapping, evidence pipelines), expanding EDR coverage.

3 — Marked Route: Getting to Best Practices

Our standardized, repeatable way above table stakes; externally defensible.

Signals: a documented “our way” pattern; ≥90% coverage; key steps automated; periodic external validation; consistent results across teams. Examples: WAF program with policy-as-code; PAM with JIT + break-glass audit across prod/non-prod.

4 — Summit Standard: Getting to Best in Class

Security as a product differentiator. InfoSec co-owns design and roadmaps; secure defaults, user experience, and customer trust are engineered — not bolted on.

Signals: zero-day response ≤1 day, critical ≤7 days (measured and reported); product-integrated security features are first-class; product and security co-owned OKRs; outcome KPIs met three consecutive quarters; threat-led design; third-party attestations aligned to customer asks; paved paths/SDKs and automated policy checks for engineers.

5 — Closed Terrain: Out of Scope

Requires new mandates or controls. Not part of the current ascent plan. Regulator-constrained.

Verb Mnemonic

Start → Stabilize → Standardize → Lead → Exclude (Basecamp → Switchbacks → Marked Route → Summit Standard → Closed Terrain)

The Key Distinction (3 vs. 4)

• Marked Route (3): “Best practices — repeatable and defensible.”
• Summit Standard (4): “Best in class — security co-creates the product and customer experience.”

Or, crisper: 3 = Standardize (prove we’re good) → 4 = Productize (make security a customer feature).

Promotion Gates (3 → 4)

All must be true:

1. Product and Security co-owned OKRs and a standing backlog slot
2. Threat models drive feature stories
3. Outcome KPIs met three consecutive quarters
4. External attestation aligned to customer asks
5. Paved engineering paths with automated policy checks

Mountain Composition

What defines the altitude (business risk): impact to brand, mission, and customers; potential and active threats (external and internal); regulatory responsibilities; customer requirements; attack surface; program maturity (as one input); risk management strength; control effectiveness.

Altitude (risk) = threats + obligations + exposure − (maturity × controls × risk management)

Foundation layer: Business Priorities & Objectives — drives which routes get climbed and how fast. This sits beneath the maturity levels, not on the ladder itself.

Climbing risks and dynamics: a moving target (threats, customer asks, and regulations evolve); gravity (stop advancing and you slip back — control drift); unseen hazards (unknown vulnerabilities, supply-chain issues, vendor incidents); terrain (technical debt, dependencies, legacy patterns); environmentals (macro-economics, hiring constraints, vendor changes).

Steps to climb: manage risk (prioritize by altitude and urgency); define and accomplish objectives (quarterly uplift plans tied to levels); measure outcomes (coverage, MTTR, block rate, audit pass); sustain (owners, budget, re-verification cadence).

Worked Example: Running the Board Presentation

Adapted from real use in board maturity presentations:

1. Show the mountain, not the number. Open with the mountain and one dot per capability, positioned at its current level — not a table of scores. The board should see in five seconds which capabilities sit at Basecamp versus Marked Route.
2. Annotate altitude on the same slide. “Customer data handling — high altitude (regulatory + breach exposure)” versus “Internal tools — low altitude (limited customer impact),” so the board understands why one capability reaching Summit Standard matters more than another.
3. Talk about the climb, not the score. “We moved identity from Basecamp to Switchbacks this quarter — 82% of production systems now under consistent MFA, SLAs live, first external validation complete. The goal is Marked Route by Q3.” That’s a story a board follows; “identity is at 2.1, was 1.8” is not.
4. Name the climbing risks for the quarter. “Terrain risk in network segmentation — three legacy systems can’t support microsegmentation without redesign. We have a plan and a 90-day timeline.” Named risks with owners are manageable; unnamed risks become governance failures.

The reframe this produces: when a board asks “what does it cost to get to Marked Route across everything?”, the answer isn’t a number pulled from a maturity estimate — it’s “that depends on the altitude we choose to operate at, which is a business decision,” followed by cost scenarios at different altitudes. That shifts the conversation from reporting a score to helping the board choose which mountain it’s climbing.

Limits

• This is a communication layer, not a replacement measurement system. The underlying NIST CSF-style maturity assessment still has to happen; this model translates it, it doesn’t generate it.
• It requires real signals per level to stay honest. The ladder above lists concrete signals (coverage percentages, external validation, KPI streaks) for each level deliberately — presenting a level without the signals behind it turns the mountain into the same unfalsifiable number it was meant to replace.
• Not every audience needs the metaphor. Auditors and framework-literate stakeholders want the NIST CSF numbers directly; the mountain is for the room that doesn’t.
• One iteration, not yet externally validated. This is a v1 synthesis, used in real board settings but not yet reviewed outside that context.

Status

This framework page is in editorial review, not yet approved for public release — the source write-up it’s drawn from hasn’t been published on the site. See DECISION-LOG for the approval this needs before status moves to published.