It came back low. Nobody questioned the score. The incident response team spent the first four hours of the incident trying to understand why a low-risk system was producing a high-impact breach.
The Score and What It Measured
Risk scores are models. Models are simplifications of reality. The simplification choices that go into a risk scoring model determine what the model can detect and what it will systematically miss. Most enterprise risk scoring models score against the same standard criteria — data classification, system exposure, compliance framework applicability, business criticality as defined by business owners. These criteria are reasonable proxies for risk in the environments the models were designed for. They are imperfect proxies in environments that have changed, and they are inadequate proxies for risks that the model's design did not anticipate.
The system that scored 2.3 out of 10 was a configuration management database used by infrastructure teams. It did not hold customer personal data, which would have elevated the data sensitivity score. It was not directly internet-facing, which kept the external exposure score low. It was not subject to PCI, HIPAA, or SOX controls, which kept the compliance score low. Its business criticality score reflected the infrastructure team's self-assessment: important but not mission-critical.
What the scoring model did not capture was the system's role in the broader architecture. The configuration management database held the network topology, credential stores, and infrastructure configuration for several hundred systems. Whoever had access to that database had a map of the environment and the keys to significant portions of it. The system's actual risk to the organization was not a function of the data it held — it was a function of what an adversary could do with the access and knowledge it provided.
Risk scoring models that measure what data a system holds and what regulations apply to it are measuring one dimension of risk. The dimensions they do not measure are sometimes the ones that matter most.
Why the Score Was Trusted
The score was trusted because the methodology was trusted, and the methodology was trusted because it was established, documented, and consistently applied. These are the properties of a legitimate governance process. They are not the same as the properties of a methodology that captures the right things. The trust in the score was not misplaced relative to the methodology. The methodology was misplaced relative to the risk.
This is the governance trap that risk scoring models create at scale. When hundreds or thousands of systems need to be scored, a consistent methodology is a practical necessity. The methodology enables comparison, prioritization, and defensible governance decisions. It also produces systematic blind spots wherever the methodology's criteria do not align with the actual risk drivers in the environment. Those blind spots are consistent, which makes them invisible in aggregate — the methodology produces scores that look plausible across the full population.
What the Model Missed
Architectural Risk Is Not in Most Scoring Models
The risk of a system is not only a function of its own properties. It is also a function of what access to that system enables. A system with low data sensitivity that provides access to the credentials or configurations of high-sensitivity systems has a risk profile determined by the second-order access it enables, not by its own data holdings. Most risk scoring models assess first-order properties. They do not model the architecture of access dependencies that determine what a compromise of the scored system would actually enable.
Threat Intelligence Is Not in Most Scoring Models
Risk is the product of likelihood and impact. Most enterprise risk scoring models assess impact through their standard criteria. They do not incorporate current threat intelligence that would inform likelihood: what attack techniques are active against the organization's sector, what systems those techniques target, and how the scored system fits into the current threat landscape. A configuration management database scored against static criteria six months ago was not scored against the specific attack pattern that the threat actor used. The methodology did not know about the pattern. The threat actor did.
Self-Reported Criticality Is Not Independent Assessment
Business criticality scores in most risk registers reflect business owner self-assessments. Business owners assess criticality relative to their own operational understanding, which is typically expressed in terms of what happens to their operations if the system is unavailable. They do not assess criticality relative to what an adversary could do with access to the system, which requires a different kind of analysis that most business owners have not been asked to conduct and most risk assessment methodologies do not request.
After the Score Failed
The incident produced a risk register review that found not one but several systems where the scoring model had produced scores that did not reflect the systems' actual risk significance. The common pattern was architectural: systems that scored low on the standard criteria but occupied positions in the environment that made them disproportionately valuable to an attacker — central access points, credential repositories, systems with broad read access to sensitive infrastructure configuration.
The review also found that the methodology had not been materially updated since its initial design three years earlier. The environment had changed significantly in those three years: cloud adoption had expanded the infrastructure footprint, a significant acquisition had added systems that were not designed with the existing environment's security architecture in mind, and the threat landscape targeting the organization's sector had evolved. The methodology had stayed static while everything it was designed to assess had changed.
A risk scoring model that was calibrated for the environment of three years ago is scoring the environment of today against yesterday's assumptions. The incident is the calibration event nobody wanted.
Rebuilding the Methodology
The organizations that have responded thoughtfully to this kind of failure have made specific changes that address the structural gaps the incident exposed. They have added architectural dependency mapping to the scoring criteria — assessing not only what data a system holds but what access to that system enables across the broader environment. They have integrated threat intelligence as a live input into risk scoring rather than a periodic addition to static criteria. And they have separated business criticality assessment from business owner self-reporting, adding an independent security perspective on what a system's compromise would enable.
None of these changes produce perfect risk scores. Risk scoring is inherently a model, and models are inherently simplifications. The goal is not a methodology that captures all risk. It is a methodology whose blind spots are understood, whose assumptions are documented, and whose outputs are treated as one input to risk decision-making rather than as a definitive assessment.
The risk score is a model output. Model it with the humility that requires.
Review your scoring methodology against your current environment. If the methodology has not changed since the environment changed significantly, the scores are measuring something that no longer fully exists.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.