Why C2M2 and not something else
The Cybersecurity Capability Maturity Model Version 2.1 was published by the US Department of Energy in June 2022 and is publicly available. It was built for operators of industrial and operational technology environments. Three properties matter here: it can be referenced openly, its Maturity Indicator Levels progress on institutionalisation rather than on control count, and its domain structure maps onto how an industrial organisation is actually run.
CMMI is a reference point only. Its ad-hoc-to-optimising progression is public and widely understood, but the practice text and the appraisal are ISACA's and are not ours to use. NIST CSF Tiers are deliberately not crosswalked, because NIST states plainly that CSF 2.0 Implementation Tiers are not intended to be maturity levels, treating them as one would misrepresent the source.
C2M2 v2.1 defines four MILs, MIL0 through MIL3, and applies them independently to each domain. Its progression includes both implementation of domain practices and the management characteristics that institutionalise them. An IO domain is not a renamed C2M2 domain, and IO's levels are not renamed MILs: IO separates accountable execution, sustained cadence, governance, verification and adaptation because those states produce distinct evidence and distinct remediation decisions. This is an IO design choice, not a correction to C2M2.
The rules this map operates under
These are absolute and they constrain what appears below.
Direction of claim. Always our evidence speaks to this practice. Never you comply with this practice. Compliance is an assessor's determination. IO is not an assessor and says so on every page where the crosswalk appears.
Identifiers only. Practice and domain identifiers are referenced. Framework text is never reproduced, paraphrased closely, or embedded in a report.
Informed by, not aligned with. The words aligned, compliant, certified and assessed against do not appear in any IO output referencing C2M2.
No inherited maturity. A C2M2 MIL is not derived from an IO level and an IO level is not derived from a MIL. The two models measure different things on different evidence. What the map provides is a reading aid, not a conversion.
Domain-level correspondence
C2M2 Version 2.1 organises into ten C2M2 domains. IO holds evidence across eight IO domains. The two vocabularies collide on the word domain, so this reference never uses it unqualified. The correspondence is many-to-many, and stating it at domain level is honest in a way that a practice-level table would not currently be.
| C2M2 DOMAIN | IO DOMAINS HOLDING RELEVANT EVIDENCE |
|---|---|
| Asset, Change and Configuration Management | Assurance & Compliance · Resiliency |
| Threat and Vulnerability Management | Threat Detection |
| Risk Management | Policy & Governance · all IO domains via the register |
| Identity and Access Management | Threat Detection · Human Risk |
| Situational Awareness | Threat Detection |
| Event and Incident Response, Continuity of Operations | Resiliency |
| Third-Party Risk Management | Third-Party Risk |
| Workforce Management | Human Risk |
| Cybersecurity Architecture | No IO evidence. Not covered. |
| Cybersecurity Program Management | Policy & Governance |
| No direct correspondence claimed | Physical Security |
Three entries deserve attention rather than being read past.
Cybersecurity Architecture has no IO evidence. Architecture is a design property, largely assessed from documentation and review rather than from execution records. IO holds no signal that speaks to it. It is listed so the gap is visible rather than absent.
Risk Management maps to everything and to nothing in particular. The IO risk register spans all eight domains, so the domain correspondence is structural rather than specific to one IO domain.
Physical Security is an IO domain but is not presented as having a direct one-to-one correspondence with a C2M2 domain in this reference. Physical-to-digital access and incident evidence may help a reader navigate C2M2 Identity and Access Management or Event and Incident Response practices where relevant, but IO does not claim that this constitutes C2M2 coverage, alignment, assessment or a maturity result.
What is not published yet
A practice-level map does not exist. Building one requires deciding, for each C2M2 practice, which specific IO measure speaks to it and how strongly, and that is a judgement exercise that has not been done. Publishing a practice-level table before doing that work would produce exactly the false precision this model is designed to avoid.
Until it exists, the honest position is: IO evidence is organised in a way that a C2M2 assessor can navigate, and IO does not claim to produce a C2M2 result.
How to use this in an assessment
If you are preparing for a C2M2 self-evaluation, IO's contribution is evidence rather than scoring. For a given domain, IO can produce the execution records, owners, dispositions, dates, verification outcomes, that support or fail to support an assertion you make. The assertion remains yours. So does the MIL.
Source
US Department of Energy, Cybersecurity Capability Maturity Model, Version 2.1 (opens in a new tab), June 2022. The DOE model and its self-evaluation tools are the authoritative source; summaries and commercial crosswalks are secondary.