DRAFT — This article is in progress. Content is placeholder only.
Most security assessments produce a list of vulnerabilities ranked by severity. CVSS scores, RAG ratings, high/medium/low classifications — the report tells you something is critical, but it rarely tells you what happens to your business if it gets exploited. For a team running bespoke technology, that gap between technical severity and business impact is where bad prioritisation decisions happen. This article sets out a practical way to close that gap.
Why CVSS scores are not enough
A CVSS score of 9.8 sounds alarming. And it might be — or it might be a vulnerability in a system that sits behind three layers of access control, handles no sensitive data, and is only accessible to three internal users. The score tells you how bad the vulnerability is in the abstract. It does not tell you how bad it is for your business.
Introducing the RROC™ framework
RROC stands for Revenue, Reputation, Operations, and Compliance. These are the four ways a security incident damages a business. Every security finding, no matter how technical, ultimately threatens one or more of them. A vulnerability in your payment processing flow threatens Revenue directly. A misconfiguration that could expose customer data threatens Reputation. A denial-of-service risk to your core platform threatens Operations. A control gap in your data handling threatens Compliance. Mapping your security findings to RROC dimensions gives you a business-impact view that technical severity scores cannot provide.
A practical prioritisation process
Start with your full findings list. For each item, identify which RROC dimensions it threatens and how severe the impact would be. Then apply a simple reachability filter. How easy is it for an attacker to actually exploit this? High business impact plus easy exploitation equals fix first. Low business impact plus difficult exploitation equals fix last, or accept the risk with eyes open.
What this looks like in practice
In one engagement with a major UK bank, we found that roughly half of the security work being done by their teams was addressing the wrong issues. Not because the issues were unimportant in the abstract, but because given the bank's actual threat profile and architecture, those risks were much lower priority than others that were being ignored. Applying a business-impact lens — asking "what happens to this business if this is exploited?" — redirected their security investment to where it actually mattered.
Communicating priorities to the board
The same analysis that helps you prioritise remediation also makes your security reporting more useful to your board and leadership team. Instead of "we have 47 open vulnerabilities, 12 of which are critical," you can say "we have three findings that pose meaningful risk to our Q3 revenue targets, and we are addressing them in this order for these reasons." That is a conversation a CEO or CFO can engage with.
Prioritisation is not just a technical exercise — it is a business decision. The RROC framework gives technical teams a way to connect security findings to the outcomes that matter to their organisation, and gives business leaders a language for engaging with security that does not require them to understand CVEs. If your current security process produces a long list of findings with no clear path forward, this is a problem Threatplane works on with clients every day.
Jonny founded Threatplane in 2017. With a background in offensive security, he has spent 15+ years helping organisations across defence, financial services, healthcare, and manufacturing understand and manage their technology risks.
Full bio →