The Problem in Practice
Cybersecurity assessments have a recurring problem: a missing control gets identified, and almost immediately it becomes a high or severe risk finding. This happens across audits, maturity reviews, and gap assessments — often without any serious analysis of whether the absence of that control actually creates a meaningful threat to the organization. International frameworks like ISO 27001, ISA/IEC 62443, NIST CSF, and CIS Controls are valuable references, but they were never intended to be used as pass/fail checklists where every gap automatically becomes a risk statement.
In practice, technically valid findings lose credibility fastest when the risk rating cannot be connected to a scenario the business or operation actually recognizes.
The more common causes are structural: assessment timelines that do not allow for deep contextual analysis, limited involvement from system owners and process owners during the review, over-reliance on framework checklists as the primary evaluation tool, and a tendency to conflate control gaps with risk conclusions without completing the analytical steps in between.
What should happen looks more like this:
Missing Control → Vulnerability or Weakness → Threat Scenario → Business Impact → Risk Evaluation
Each step requires a judgment call. The absence of a control creates a potential weakness. That weakness may or may not be exploitable in a realistic threat scenario. Even if it is, the business impact depends on what systems are involved, how critical they are, what compensating controls exist, and what the organization's recovery capabilities look like. Risk only emerges at the end of that chain — not at the beginning. Skipping those steps does not make the assessment faster. It makes the assessment less useful.
Control Gaps and Risk Are Different Things
The language used in cybersecurity assessments is often imprecise. Control gaps, vulnerabilities, findings, weaknesses, and risks get used interchangeably, even though they represent distinct analytical concepts.
- A control gap is the absence or incomplete implementation of a safeguard.
- A vulnerability is a weakness that could, under the right conditions, be exploited.
- A threat scenario is a plausible event that takes advantage of that weakness.
- Risk is the potential business impact of that scenario, weighted by likelihood and consequence.
The distinction matters practically. Consider segregation of duties in an operational environment. An assessment might note that a single engineer holds combined administrative access across the control system network, historian, and remote access infrastructure without independent oversight. Calling that “high risk” tells management almost nothing. It does not explain what that engineer could realistically do, whether monitoring or approval mechanisms exist, or what the operational consequence would be if something went wrong.
A more useful statement would be: a single engineer maintains combined control over the process control network, data historian, and remote access systems without independent oversight or compensating review mechanisms — creating conditions where unauthorized changes or unapproved configuration modifications could occur without detection, with potential impact on process availability and safety system integrity.
That statement establishes the scenario, identifies the exposure, and gives management something they can evaluate against their operational context.
Context Changes Everything
The same control gap can represent very different levels of risk depending on the organization, the environment, and what else is in place. Several factors genuinely affect how a gap translates into risk: the criticality of the affected systems, operational dependency, the regulatory environment, threat relevance to the specific industry and geography, staffing constraints, compensating controls, monitoring and detection capabilities, and management's defined tolerance for residual risk.
Consider disaster recovery in an industrial setting. An assessment might observe that a facility lacks formal DR capability for certain systems and classify it as severe risk. But if those systems are non-critical utilities with manual fallback procedures, modest recovery time objectives, and low production dependency — the business risk is materially different from what a severe label implies. The observation may be valid. The risk rating may not be.
Smaller operational sites present a similar challenge. A single-facility manufacturer with a small engineering team may not achieve ideal segregation of duties across OT and IT systems — not through negligence, but because the headcount does not exist to support it. Flagging this as a critical finding without evaluating the actual exposure and compensating controls in place may not add meaningful insight. What matters is whether monitoring, approval workflows, or other mechanisms reduce the residual risk to a level consistent with the organization's operational requirements.
Maturity Does Not Mean Maximum
There is a related problem in maturity assessments: the assumption that every control domain should progress toward the highest possible maturity level, and that anything short of that represents inadequate security posture.
Cybersecurity supports operations — it does not replace them. That means security investment has to be proportional, calibrated to actual threat exposure, operational dependency, regulatory obligations, and management's defined risk tolerance. Not every environment needs the same level of control maturity. A critical production system in a regulated facility has different requirements than a non-critical internal network segment. Treating them identically wastes resources in one direction while potentially under-resourcing the other.
Higher maturity also has a cost:
- Additional operational complexity,
- Maintenance burden,
- Governance overhead,
- Implementation expense.
Organizations may reasonably conclude that certain domains are well-managed at a procedural level — defined ownership, documented processes, periodic reviews — and that pushing further adds overhead without meaningfully reducing risk. That is not poor governance. It is proportional governance.
It is also worth distinguishing between mandatory regulatory requirements and voluntary international standards. Regulations establish floors that organizations must meet. Frameworks like ISO 27001 or ISA/IEC 62443 provide structured guidance that requires interpretation based on context, applicability, and risk exposure. Assessments that treat voluntary framework conformance as a compliance obligation create confusion about what is actually required versus what represents good practice.
Who Owns the Risk Decision
Assessors identify gaps and describe exposures. Management decides what to do about them.
The determination of acceptable risk, remediation priority, maturity targets, and treatment decisions belongs to management — not the assessor. Risk decisions involve balancing operational requirements, business priorities, implementation cost, threat exposure, resilience objectives, and regulatory obligations. Assessors contribute the technical picture. Management provides the business judgment.
This means the assessor's job is not to define what the risk appetite should be. It is to translate technical observations into scenarios that management can actually evaluate. An assessment that produces a list of high-severity findings without explaining the business scenario behind each one has not given management what they need to make good decisions.
What a Mature Assessment Looks Like
Before assigning a risk rating to any finding, four questions should be answerable:
- Is the control applicable to this organization, environment, and system?
- What realistic scenario does its absence create?
- What business or operational impact could that scenario produce?
- Is the residual risk, after accounting for compensating controls and organizational context, within management-defined tolerance?
If those questions cannot be answered, the assessment has identified a gap. It has not established a risk. Mature cybersecurity assessments are not measured by how many findings they surface or how severe those findings are rated. They are measured by how accurately they reflect actual operational exposure — and how effectively they support the decisions that management needs to make.