Most vulnerability reports tell you everything is critical. Yours probably does too.

The firm had developed a novel vulnerability scoring system — the V-Score — that improved on CVSS and EPSS by incorporating real-time threat intelligence from researcher forums and social media feeds. Unlike static severity scores, the V-Score adjusted dynamically as the threat landscape changed, reflecting actual threat actor behaviour rather than theoretical vulnerability severity.

The V-Score was already in use with defence-sector clients. The next step was academic validation: a rigorous, independent demonstration of its effectiveness against a real environment. The firm approached a UK research university, who accepted the proposal and made available their OT security laboratory — a lab-scale water treatment facility used by PhD researchers specialising in critical systems security.

As the sole Business Analyst embedded in the R&D team, the role was to build the solution that would apply the V-Score to a real OT asset inventory and make the comparison visible to external academic stakeholders. The V-Score methodology itself was developed and validated separately by the data engineering team.

One further note on scope. The project was designed and delivered for a research-based OT environment, and it delivered what that context required. The stakeholders were satisfied with the output. But a contained laboratory setting and a live operational facility are not the same problem, and treating the methodology as directly transferable would be a mistake. Section 08 reflects on what would need to change in a live environment — not because the project fell short, but because understanding the boundary conditions of your own work is part of doing it properly.

CVSS assigns a severity score at the point a vulnerability is disclosed. It measures theoretical severity — attack complexity, privileges required, potential impact — without asking whether any threat actor is actively pursuing it, or whether the asset it sits on matters to the organisation. The score does not change unless the vendor updates it.

This creates a structural problem for any team trying to manage vulnerability risk in practice.

Treating severity as a proxy for risk produces backlogs that are unmanageable and remediation decisions that are systematically wrong. An asset with a maximum CVSS score and zero active exploitation carries less real-world risk than an asset with a moderate score that a ransomware group picked up last week.

In the water treatment laboratory, this problem was immediately visible. With 270 CVEs mapped across 17 legacy software components — many of them unpatched legacy systems the researchers could not update without disrupting ongoing work — a CVSS-driven approach would have generated a critical backlog no small team could meaningfully act on.

The work was structured across three sequential phases: building a reliable asset inventory, constructing the data model and pipeline, and delivering a vulnerability intelligence solution in Power BI that enabled direct scoring comparison.

The human machine interface hosted between 15 and 20 software applications including Windows CE, Siemens, and Oracle tools alongside OT-specific components. Many had incomplete asset information — missing version numbers, missing brand names, or both. Without accurate asset data, CPE IDs could not be assigned, and without CPE IDs, the vulnerability matching that underpinned the entire comparison was unreliable.

This was not just a data quality problem. It was a methodological risk: if the foundation was wrong, the 92% finding would be meaningless. Before writing a single line of code, the asset inventory problem was resolved through two agreed and documented assumptions.

The asset inventory was stored in Azure Blob Storage and processed through a three-layer medallion architecture in Azure Databricks using Python and SQL. The data model was designed and validated by the data architect before implementation began.

DAX measures were written in Power BI to calculate the percentage of vulnerabilities flagged as critical by each scoring system across the full 270-CVE dataset. The comparison produced a striking result.

Vulnerability management is often treated as a technical function — scan, score, patch. But the prioritisation of vulnerabilities is fundamentally a risk decision, and risk decisions require a different kind of reasoning than severity scoring alone.

The translation gap between vulnerability data and risk intelligence sits between the attack surface and asset levels. It is where technical findings either become actionable business decisions or get lost in noise. That translation — from 270 CVEs to 22 material vulnerabilities — was what the dashboard delivered. Not a technical output. A risk decision-support tool.

The approach was appropriate for a contained laboratory proof of concept with a clearly defined scope and academic stakeholders. In a live operational environment, four things would need to change.

The university stakeholders — including the head of computing, the OT security professor, and two PhD researchers — were impressed by both the V-Score comparison and the threat landscape extension built at the CTO's request, which visualised APT groups targeting water sector facilities using MITRE ATT&CK data and a Microsoft researcher-maintained APT dataset.

The partnership continued beyond the initial workshop. The work contributed directly to a peer-reviewed publication validating the V-Score methodology:

The data architect continues to use the project as a case study in procurement conversations. Findings ownership sat with the head of computing at the university. Remediation was out of scope — the project delivered the threat context needed for informed attack surface reduction decisions, not a remediation plan.