Control maturity is not a discount coupon. In critical infrastructure, that assumption can turn a serious risk review into a comforting lie.
I have seen this mistake show up in a few forms. A team scores controls as “mature,” subtracts a neat number from the risk score, and walks away feeling better. The asset did not change. The blast radius did not shrink. The spreadsheet just got prettier.
That is why I am careful with the phrase Security Maturity Reduction Value, or SMRV. It is not a standard term in the major frameworks I checked. NIST SP 800-30 frames risk assessment around likelihood, impact, and mitigations from controls in place.
NIST’s risk management guidance says to assess whether controls are in place, operating as intended, and producing the desired results. ISA/IEC 62443 uses security levels, zones, and conduits for industrial systems. FAIR-CAM models how controls affect the frequency and magnitude of loss. None of those treat maturity as a free-standing subtraction from risk.
The way to think about it is simpler. Maturity should change control effectiveness. Control effectiveness should change residual risk. That is the line. Everything else is decoration.
Security Controls Reduce Exposure, Not Risk Reality
NIST SP 800-30 defines risk assessment as part of risk management and says it incorporates threat and vulnerability analysis while considering mitigations provided by security controls. That is a much tighter idea than “take the score and knock off a maturity value.”
NIST’s RMF guidance is even more practical. First, determine whether controls are in place. Then check whether they are operating as intended. Then decide whether they are producing the desired result. That sequence matters because a control that exists on paper may do almost nothing in a real incident.
ISA/IEC 62443 approaches the same problem from the OT side. It uses zones, conduits, and security levels to assess security performance in industrial automation and control systems. That makes sense in critical infrastructure, where an IT-style checklist often misses the actual attack path.
FAIR-CAM adds a useful angle. It treats controls as part of a system and measures how they affect loss frequency and loss magnitude. That is exactly the kind of model you want when a plant, utility, hospital, or transport network is involved. A strong control does not erase consequence. It changes the odds and the shape of the loss.
That distinction sounds small. It is not. It is the difference between disciplined risk scoring and wishful accounting.
How to Calculate Residual Risk Using Control Effectiveness
If an organization insists on using SMRV, I would not let it float around as a vague subtraction value. I would tie it to control evidence and make it part of residual risk calculation.
- Pick one scenario. Not an asset in general. A specific event chain.
- Score only the controls that affect that scenario. Remote access, segmentation, patching, logging, recovery, or identity controls, depending on the case.
- Rate each control with evidence. Not opinion. Not “we have a policy.” Evidence.
- Weight the controls. A weak segmentation layer may matter more than a polished awareness program.
- Convert weighted maturity into control effectiveness.
- Apply that to residual risk.
That is the clean version. It is also the version that survives scrutiny.
A simple formula is enough.
Weighted maturity = Σ(control maturity × control weight)
Control effectiveness = weighted maturity ÷ maximum possible score
Residual risk = inherent risk × (1 − control effectiveness)
That last line is the one I would defend in a room full of auditors. It keeps the model proportional. It does not pretend that a mature backup strategy makes an attacker less likely to enter the network. It reduces the damage after the attack lands.
That is the whole point.
Why Subtraction is the Wrong Instinct
Subtracting a fixed maturity value from inherent risk feels tidy. That is why people like it. It also causes trouble.
Here is the problem. A flat reduction assumes maturity helps every scenario in the same way. It does not. MFA might crush credential abuse and do almost nothing against a vulnerable internet-facing service. Segmentation might slow lateral movement and still leave the first foothold untouched. Recovery capability might reduce outage time without touching likelihood at all. A single reduction number hides those differences.
In critical infrastructure, that is risky thinking. The consequence is often safety, uptime, environmental exposure, or public service disruption. The score should reflect the scenario, not the comfort level of the reviewer. ISA/IEC 62443 leans into that by using security levels for specific zones and conduits, not a universal “maturity bonus.”
I would rather see a slightly harder model that stays honest than a slick one that oversells protection.
A Practical Example
Say a utility is reviewing remote access into an OT support network. The inherent risk is high because the asset is critical, the exposure is real, and a compromise could interrupt service.
The team scores the relevant controls. MFA is strong. Segmentation is partial. Privileged access is okay. Logging is decent but not tuned well. Recovery exists, but the drill evidence is thin.
Now the maturity score is no longer a vanity metric. It becomes evidence of how much the current control stack can really resist, detect, or absorb the event.
If the weighted control effectiveness comes out at 65 percent, and the inherent risk is 80 on a 0–100 scale, the residual risk is 28. That still deserves attention. It just deserves the right kind of attention.
That is the useful output. Not “we reduced risk by 17 points.” More like, “here is how much the current control set is actually buying us, and here is what remains exposed.”
How Treatment Decisions Should Follow
Once you have residual risk, treatment is straightforward. NIST’s risk guidance points toward risk-based decision-making, and NIST’s risk management framework says the senior official authorizes operation based on that risk view. That means the treatment call should follow the residual risk, the asset’s criticality, and the organization’s tolerance.
- Accept when residual risk is inside tolerance and monitoring is in place.
- Mitigate when the remaining exposure is still too high.
- Avoid when the scenario is too dangerous for the current operating model.
- Transfer only for the loss portion that can realistically be shifted.
That order matters. Mature controls do not automatically mean accept. In critical infrastructure, a highly mature control set can still sit on top of an ugly consequence profile. If the consequence is severe enough, the right answer is still mitigation.
The best way to use SMRV is to make it a documented, evidence-backed control effectiveness factor inside residual risk scoring. Use it to explain how much protection the current control set actually provides. Do not use it as a blanket deduction from inherent risk. That is the cleanest way to keep the model defensible, technical, and honest.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
