A maturity score tells you how consistently your organization performs a set of practices; it also indicates how likely the process will perform in times of stress (e.g., an actual incident). It does not tell you how much money you stand to lose if those practices fail, and it does not tell you which gap to close first. Those are two different questions, and in my experience the industry has gotten reasonably good at answering the first one (risk of failure) while mostly ignoring the second (which first). This piece is about closing that gap: how a score actually gets assigned, and what a serious organization does with it once the assessment is filed away.
Earlier this year I wrote about reconciling the major maturity frameworks against each other, so I won't retread that ground here. This is about mechanics: how the scoring actually works, where it goes wrong, and how to turn a level into a funded, prioritized, financially defensible plan.
Three frameworks dominate OT maturity assessment, and they measure different things in different ways. Confusing them is the single most common error I see. (Full definitions for each live in our OT cyber risk glossary: C2M2, NIST CSF, and IEC 62443 all have dedicated entries; what follows is how each actually assigns a score, which the glossary doesn't cover.)
The Department of Energy's C2M2 (cybersecurity capability maturity model), currently at version 2.1, organizes more than 350 practices across ten domains covering both IT and OT: risk management, asset and configuration management, identity and access, threat and vulnerability management, situational awareness, incident response, third-party risk, workforce management, architecture, and program management [1]. Each practice gets scored on a four-point scale, fully implemented, largely implemented, partially implemented, or not implemented, and rolls up into a Maturity Indicator Level (MIL) from MIL0 to MIL3 for each domain separately. There is no single overall C2M2 score. An organization can sit at MIL3 in incident response and MIL0 in third-party risk at the same time, and that's the point: the framework is built to expose exactly that kind of unevenness rather than average it away.
The mechanic that matters most here is cumulative scoring. To earn MIL2 in a domain, you have to fully satisfy every MIL1 practice in that domain first, no partial credit, no rounding up [1]. One unmet foundational practice caps the entire domain regardless of how many advanced practices you've since layered on top. That rule exists specifically to stop organizations from claiming credit for sophisticated capabilities while the basics underneath them are still shaky. It also creates a reporting problem I took up directly in that earlier work (harmonizing maturity [9]): strict cumulative scoring gives no credit for real, formative progress inside a level, which is why the harmonized model introduces a "Developing" half-step (Level 1.5) to represent an organization partway through a level without violating the no-rounding-up rule [9]. Whichever convention you adopt, the discipline is the same: don't let a tidy number paper over an unmet fundamental.
NIST Cyber Security Framework (CSF) 2.0, released in February 2024, works differently and is worth naming precisely because it gets mistaken for a maturity model constantly [2]. It uses four Implementation Tiers, Partial, Risk Informed, Repeatable, and Adaptive, that describe the rigor of your governance and risk management process. NIST is explicit that these tiers are not a maturity ranking. An organization can be Tier 4 on governance and Tier 1 on actual detection coverage simultaneously, and CSF's own documentation says so directly. Most assessors who use CSF as a scoring tool overlay a 1-4 or 0-5 numeric scale on top of the tiers themselves, which is a reasonable adaptation, but it's an assessor's convention, not something NIST built into the framework.
IEC 62443 splits into two concepts that get conflated more often than any other pair in this field. Security Levels (SL), SL1 through SL4, rate the sophistication of adversary a system is built to resist, from casual or coincidental violation at SL1 up to a well-resourced, motivated attacker at SL4 [3]. Maturity Levels (ML), ML1 through ML4, borrowed from CMMI-SVC v1.3 (capability maturity model integration), rate the discipline of the process behind the security, whether it's ad hoc, documented and repeatable, standardized across the organization, or actively measured and improved [3]. The standard itself states there's no fixed relationship between the two. You could, on paper, build an SL4 system on an ML1 process, though it would be fragile in practice, since nothing sustains it. The 2024 edition of IEC 62443-2-1 added something genuinely new here: a four-level asset-owner maturity model, the first time the standard has offered a maturity scale specifically for the operator's security program rather than just the supplier's development process per 62443-2-4 [4].
Most of these frameworks were designed for self-assessment, and that design choice has consequences worth naming directly. A facilitated C2M2 self-evaluation can be completed in a single day. A credible multi-site risk assessment, by contrast, typically runs from a few weeks to a few months depending on site count and scope. In my experience scoping these engagements, it costs meaningfully more than a self-assessment, commonly in the tens of thousands of dollars for a mid-size single-site assessment. The reason to pay for an external assessment reduces bias and conflict of interest. It's that internal teams, understandably, tend to interpret ambiguous requirements in the direction that favors what they're already doing – optimistically or in a way that reduces criticism/scrutiny by their leadership (aka., fear).
The evidence gap between self-scoring and reality shows up clearly in the data. Fortinet's 2025 State of Operational Technology and Cybersecurity Report, surveying over 550 OT professionals, found that 81% of organizations now self-assess their maturity at the top two levels of a five-level scale (i.e., ML4, ML5), a sharp upward shift from prior years [5]. Set that against SANS's 2025 State of ICS/OT Security Survey, which found only 13% of organizations report full visibility across the ICS Cyber Kill Chain, with 42% reporting partial visibility and major gaps [6]. Those two numbers describe the same industry in the same year, and they don't agree with each other: four in five organizations rate their own program near the top of the scale, while roughly one in eight can actually see technical controls and visibility across their own kill chain. Feeling mature and being protected are not reliably the same thing, and any assessment program that skips independent validation is building on that gap without knowing it.
What separates the two groups isn't a mystery. The 2024 (CS)²AI-KPMG Control System Cybersecurity Annual Report found that 50% of high-maturity programs complete a control system cyber security assessment at least quarterly. Those self-reporting low-maturity OT cybersecurity programs, only about 19% assess quarterly, and that ~9% of low-maturity programs had performed no assessment at all [7]. About 24% of low-maturity programs have no control-system-specific security awareness training in place; while 41% of high maturity programs have separate IT and OT security training [7].
Getting a score is the easy part. What happens next usually breaks down into three activities, and only the third one is where most organizations, and most vendors, fall short. Where a maturity or security level (ML / SL) score gets used across a business, benchmarking, supplier assessment, board reporting, insurance, we've catalogued the full set of use cases separately; the focus here is narrower, on the three moves that turn a raw score into a decision.
The first is a prioritized remediation roadmap. This means ranking your gaps by risk versus effort rather than by how far each one is from its target level, and sequencing them with actual dependencies in mind. Deploying advanced anomaly-detection analytics before you've established a basic asset inventory is a common mistake here: the analytics generate noise nobody can interpret because there's no baseline to compare against, and the investment gets quietly ignored six months later.
The second is a budget case. A roadmap becomes fundable the moment each proposed project is tied to both a specific maturity movement and a risk rationale a board can follow. "We'll go from MIL1 to MIL2 in vulnerability management for this amount" is a defensible ask. "We'll improve our maturity score" is not, and boards have gotten considerably better at telling the difference.
The third is where the real gap in the industry sits: translating the maturity result into financial risk terms. A maturity score, on its own, cannot tell you what a specific control gap is worth in dollars. No framework was built to; that's by design, not a defect in any one of them. The FAIR Institute states this plainly: a maturity assessment doesn't describe how much risk an organization carries, and ordinal maturity scales don't count as risk quantification on their own [8]. FAIR and cyber risk quantification (CRQ) itself, decomposing risk into loss-event frequency and loss magnitude run through simulation, produces an actual dollar output, an annualized loss expectancy [8].
For OT specifically, this translation needs more than a generic controls questionnaire can supply, because OT loss is dominated by low-frequency, high-severity events, extended downtime, equipment damage, safety incidents, etc. OT cyber risk quantification needs actual telemetry from the environment. That telemetry-to-dollars translation is a good part of what drew me to the work we do at DeNexus: converting live OT network data, benchmarked against maturity including CMMI, NIST CSF and IEC 62443, into board-ready Expected Annual Loss and Value at Risk figures. The practical value of doing this well is that you can re-run the model after each proposed mitigation and see, in dollar terms, exactly how much risk it retires, which is the one thing an ordinal maturity score was never built to tell you. It's also, increasingly, the exact signal insurers are learning to underwrite against directly, a shift my colleague Neil Arklie covers in Redefining Underwriting: How Autonomous AI Agents Measure Insurance Risk.
The most common complaint is what practitioners sometimes call maturity theater: subjective maturity statements allow one to interpret on the optimistic side, while a third-party may rate lower. One rounds up, the other rounds down. A related challenge is the reaction of Executive leadership on the resulting maturity scores. Depending on the culture, staff may rate optimistically to avoid negative consequences from their Executives. Meanwhile, senior leadership sees middle-maturity often as ‘good enough’ and doesn’t seek higher maturity as there is limited financial justification to do so. Cyber risk quantification is the only technique that is capable of showing the incremental financial benefit of even the highest maturity improvements, as shared in my SANS 2026 talk on The Financial Value of Faster OT Incident Response. In this presentation I showed how there are still millions of annual estimated loss reduction at even the highest maturity top-ups. [10]
Another criticism is that aggregate, program-level scores can mask severe unevenness in one specific area, the same problem C2M2's domain-by-domain structure is explicitly designed to prevent, which is one argument for choosing a framework that resists averaging rather than one that produces a single tidy number.
None of this is a reason to abandon maturity assessment. It's a reason to treat the score as an input into something quantified, rather than as a finished conclusion. A framework gives you a shared vocabulary and an improvement path that a raw risk number alone can't provide. What it can't give you, by design, is the dollar figure that tells a board which gap to fund first.
Score honestly first, choosing the framework that matches your actual driver: C2M2 for an OT-native, energy-sector self-evaluation; the newly updated IEC 62443-2-1 if you're anchored to that standard already or facing supplier and zone requirements; NIST CSF as the shared governance language your board and auditors already recognize. Then validate before you believe the result, commissioning at least a targeted third-party review of the domains most tied to severe loss, recovery testing, segmentation, identity and access, since that's where the self-assessment optimism gap tends to hide. Then translate the validated score into money: build the risk-ranked gap register, and run the highest-severity gaps through a quantification model to produce an actual expected loss figure rather than a percentage-complete number. Fund the projects that retire the most modeled risk per dollar spent first, not the ones that move the maturity needle furthest. And keep re-measuring. If your maturity score climbs next year but your modeled expected loss doesn't move with it, that's the clearest signal available that the work has become maturity theater, and it's worth redirecting the spend before the next assessment cycle rather than after.
The score was never the point. What you do with it is.
This piece builds on our earlier analysis reconciling C2M2, NIST CSF, and IEC 62443 maturity frameworks, and on our OT vs IT Cybersecurity Learn article for foundational context on why OT risk requires a different lens than IT. For where a harmonized maturity score goes next inside an organization, see 8 Practical Use Cases for a Harmonized OT Cybersecurity Maturity Model; for how it becomes an underwriting signal specifically, see 5 Insurance Use Cases for OT Cyber Maturity and Redefining Underwriting: How Autonomous AI Agents Measure Insurance Risk. And for a real attack path this kind of assessment is meant to catch before it happens, see Inside One MITRE ATT&CK for ICS Attack Path.
A maturity score tells you how consistently you perform. It was never built to tell you which gap to fund first. The DeRISK Platform closes that gap — converting live OT telemetry, benchmarked against C2M2, NIST CSF, and IEC 62443, into board-ready Expected Annual Loss and Value at Risk. Re-run the model after each proposed control and see, in dollars, exactly how much risk it retires.
[1] U.S. Department of Energy, Office of Cybersecurity, Energy Security, and Emergency Response (CESER). Cybersecurity Capability Maturity Model (C2M2). Version 2.1, June 2022.
[2] National Institute of Standards and Technology (NIST). Cybersecurity Framework (CSF) 2.0. Feb. 2024, www.nist.gov/cyberframework.
[3] International Electrotechnical Commission (IEC). IEC 62443 Series: Security for Industrial Automation and Control Systems.
[4] International Electrotechnical Commission (IEC). IEC 62443-2-1:2024, Security Program Requirements for IACS Asset Owners. Aug. 2024.
[5] Fortinet. 2025 State of Operational Technology and Cybersecurity Report. 7th ed., 2025.
[6] SANS Institute. 2025 State of ICS/OT Security Survey. Nov. 2025.
[7] Control System Cyber Security Association International (CS2AI) and KPMG. The (CS)²AI-KPMG Control System Cybersecurity Annual Report 2024. 2024.
[8] FAIR Institute. FAIR (Factor Analysis of Information Risk) Standard.
[9] Tindill, Donovan. "Reconciling & Harmonizing OT Cybersecurity Maturity Models for Consistent, Defensible Reporting." DeNexus, 5 Feb. 2026, www.denexus.io/resources/harmonizing-ot-cybersecurity-maturity-models.
[10] Tindill, Donovan “The Financial Value of Faster OT Incident Response.” DeNexus presentation at SANS 2026 ICS Security Summit, 9 Jun. 2026, https://www.youtube.com/watch?v=b8P5fZ__jR8&list=PLJZcuc_E7ieo&index=13.