Governance, Risk & Compliance / Deep Dive

Security Maturity Models

Security maturity models evaluate the consistency, repeatability, governance integration, and continuous improvement of an organization's security practices. Measuring maturity requires selecting the appropriate model for the scope: broad process maturity (CMMI), domain-specific capability (C2M2), software supply chain integrity (SLSA), application security practice growth (OWASP SAMM), peer benchmarking against observed practice (BSIMM), or resource-tiered safeguard baselines (CIS Implementation Groups). NIST CSF Tiers sit alongside these without being a maturity scale at all.

The Security Maturity Model Comparison Matrix

CMMI: The Foundational 5-Level Maturity Archetype

The 5-level maturity scale derived from the Capability Maturity Model Integration (CMMI) forms the foundational architecture for domain-specific security maturity models:

Maturity moves from ad hoc practice to measured continuous improvement

1. Level 1 (Initial): Practices are ad hoc, undocumented, and dependent on individual heroism.
2. Level 2 (Managed): Basic project-level discipline exists; processes are planned and tracked.
3. Level 3 (Defined): Processes are documented, standardized, and integrated across the enterprise.
4. Level 4 (Quantitatively Managed): Process performance is measured statistically against quantitative quality goals.
5. Level 5 (Optimizing): Continuous process improvement is driven by statistical feedback and root-cause analysis.

C2M2: Department of Energy Capability Model

Developed by the U.S. Department of Energy, the Cybersecurity Capability Maturity Model (C2M2) evaluates practices across 10 security domains using three Maturity Indicator Levels (MILs):

• MIL1 (Initiated): Initial practices are performed, but remain ad hoc or inconsistently documented.
• MIL2 (Performed): Practices are executed consistently according to documented procedures and policies.
• MIL3 (Managed): Practices are governed by policy, deliberately resourced and staffed, with responsibilities assigned and effectiveness evaluated — institutionalized rather than merely repeatable. Note that this is an institutionalization bar, not the statistical-control bar that CMMI Level 4 sets; the two scales are not interchangeable at the same number.

An organization can operate at MIL3 in Incident Response while remaining at MIL1 in Third-Party Risk Management. This domain-level breakdown identifies precise investment targets.

OWASP SAMM: Software Assurance Maturity Model

OWASP SAMM evaluates an engineering organization’s software security practices across 5 business functions comprising 15 security practices:

Fifteen practices across five functions, each scored on its own — not a sequence

Each practice is scored independently. SAMM’s own benchmark documentation describes the four levels as Level 0, no activity or focus on application security for that practice; Level 1, initial understanding and ad-hoc implementation; Level 2, increased efficiency and effectiveness in executing it; and Level 3, comprehensive mastery and implementation of the practice at scale. SAMM does not give these levels names, so labels borrowed from CMMI — “optimizing”, “unperformed” — are not SAMM’s and tend to import the wrong bar: Level 3 is about coverage and effectiveness at scale, not about automation or statistical control. SAMM does not mandate Level 3 across all practices; organizations define target levels based on application risk profiles.

Building Security In Maturity Model (BSIMM) covers similar ground from a different direction: instead of prescribing target practices like SAMM, BSIMM is a descriptive, data-driven benchmark built by observing and aggregating the security activities actually performed at a large set of real firms. It answers “what do comparable organizations do,” while SAMM answers “what should this organization do next.”

CIS Implementation Groups: Resource-Tiered Baselines

Unlike C2M2 or SAMM, CIS Implementation Groups index safeguards according to organizational resources and threat exposure:

Each implementation group builds on the safeguards below it

• IG1: Essential cyber hygiene required for all organizations regardless of size.
• IG2: Expanded safeguard coverage for enterprise environments managing sensitive customer data.
• IG3: Full 153-safeguard baseline protecting critical infrastructure against advanced persistent threats (APTs).

NIST CSF Tiers: Governance Integration, Not Maturity

NIST CSF 2.0 defines four Implementation Tiers: Tier 1 (Partial), Tier 2 (Risk Informed), Tier 3 (Repeatable), and Tier 4 (Adaptive).

CSF 2.0 does not present the Tiers as a maturity scale. It says they “characterize the rigor of an organization’s cybersecurity risk governance and management practices” and describe “a progression from informal, ad hoc responses to approaches that are agile, risk-informed, and continuously improving.” The explicit disclaimer belongs to the previous edition: CSF 1.1 stated that Tiers “do not necessarily represent maturity levels,” and that sentence was dropped in 2.0 rather than restated. Treating the Tiers as a maturity ladder remains a misreading either way, but it is worth citing the right edition for it.

Each Tier carries two separate descriptions: Cybersecurity Risk Governance, corresponding to the Govern Function, and Cybersecurity Risk Management, covering the other five Functions. CSF 1.1’s Tiers had a third element, External Participation, covering how actively an organization shared information outside itself; CSF 2.0 removed it as a separate Tier dimension, so a description of the Tiers built around external threat-intelligence sharing is describing the 1.1 model. An organization operating at Tier 2 may maintain robust technical controls while deliberately keeping risk governance informal.

SLSA: Software Supply Chain Build Integrity Levels

The SLSA Framework (v1.2) defines Build track levels specifically for software supply chains:

• Build L0: No requirements — unmanaged build process with no provenance or integrity guarantees.
• Build L1: Requires provenance to exist and be distributed. The build platform is not yet required to be hosted — it may be an individual’s workstation — and the provenance need not be authenticated. This level does not require the build itself to run from an automated script (that producer requirement was removed in the v1.0 specification).
• Build L2: Adds two requirements on top of L1: the provenance must be authentic and verifiable (SLSA recommends, but does not mandate, a digital signature as the mechanism), and all build steps must run on a hosted build platform — shared or dedicated infrastructure, not an individual’s workstation.
• Build L3: Requires the build platform isolate build steps from unintended external influence and protect signing keys against tampering — this is narrower than a fully hermetic (network-isolated) build, which SLSA treats as a separate, future-direction property.

The v1.x specifications replaced the earlier v0.1 numeric 1–4 scale with this track-based scheme; v1.2 itself is the release that approved a second track, the Source track, covering how source revisions are authored, reviewed, and managed. Build Environment and Dependency tracks remain in development. So “SLSA level” alone is ambiguous in two directions at once — across specification versions and across tracks — and a compliance statement should name both, for example SLSA Build L3 (v1.2). This page covers the Build track; see SLSA & Build Provenance Attestations for the provenance schema and verification detail.

Primary references

• OWASP SAMM v2.0: Software Assurance Maturity Model — OWASP SAMM — verified the 5 business functions, 15 practices, and the Level 0–3 descriptions.
• BSIMM16: Building Security In Maturity Model — BSIMM Official — the current edition, published February 2026; verified BSIMM’s descriptive, observation-based construction.
• SLSA v1.2: Supply-chain Levels for Software Artifacts — SLSA Official and Build track requirements — verified the L0–L3 requirements, that authenticity “SHOULD” use a digital signature rather than mandating one, and that hermetic builds are a future direction rather than an L3 requirement.
• SLSA v1.2 change summary — What’s new — verified that v1.2’s headline change is the approved Source track.
• CMMI V3.0: Model Quick Reference Guide — ISACA
• DOE C2M2 v2.1: Cybersecurity Capability Maturity Model — C2M2 — verified the 10 domains and the MIL1–MIL3 definitions.
• NIST SP 1302: Quick-Start Guide for Using the CSF Tiers — NIST CSRC — verified that each Tier has separate Cybersecurity Risk Governance and Cybersecurity Risk Management descriptions.
• NIST Cybersecurity Framework 2.0: CSWP 29 — NIST CSF 2.0 — verified the section 3.2 wording on what the Tiers characterize.