Why counting vulnerabilities is different from managing risks
A vulnerability scan often produces an impressive picture: dashboards full of alerts, risk scores and CVE numbers, summarised in reports running to dozens of pages with hundreds of findings. This creates urgency and sometimes a sense of losing control. Red labels reinforce that impression.
Yet the number of vulnerabilities found says little on its own about the actual business risk. A vulnerability scan shows what is technically visible: systems with issues, outdated components, vulnerable dependencies or configurations that could be improved. Valuable information, but it does not tell you which finding could be exploited today, which vulnerability poses the greatest risk in this particular environment or what deserves priority first.
Many organisations measure more than ever. They use scanners, dashboards, monitoring, audits, penetration tests and periodic assessments. Yet all that information does not automatically lead to better decision-making. In some cases, the opposite happens: the more signals are available, the harder it becomes to determine which ones really matter.
On paper, there is then plenty of insight. In practice, there is no clear basis for action. There are enough reports, but the order of priority is unclear. There are enough findings, but not enough interpretation. Everyone can see that something needs to happen. What should happen first and why is not always clear.
In cybersecurity in particular, that uncertainty leads to the wrong priorities and therefore a real increase in risk.
The problem is not that nobody is looking
It would be too easy to conclude that organisations do not take security seriously enough, that IT teams are systematically behind on patching or that lack of time, complexity and lack of oversight prevent systems from being managed properly. Usually, the situation is more nuanced.
Most security teams know very well that vulnerabilities need attention. But vulnerabilities do not always fall under the ownership of administration teams, so findings sometimes remain unaddressed in practice. They work in an environment where almost everything seems urgent at once. Old systems must keep running because they are connected to critical processes. Applications cannot simply be switched off because customers or employees depend on them. Suppliers have their own schedules. The business wants speed. Change windows are limited. Meanwhile, the list of findings grows faster than teams can work through it.
Someone looking at such a list from outside may see a maintenance backlog. Someone working within it sees a daily balancing act between risk, capacity, continuity and feasibility.
Vulnerability management is therefore rarely only a technical issue. Above all, it is a matter of priorities. Not: is this vulnerability on a list somewhere? But: does this vulnerability pose a risk in this specific environment that deserves priority now?
That assessment is often insufficient. Not because of unwillingness, but because many processes are still designed around collecting and classifying vulnerabilities. A finding receives a score, then a priority, then a ticket. That provides structure, but it is not the same as risk management.
An attacker looks at things differently. They do not think in dashboard order, but in usable routes: where can I get in, where can I move next and what does the access gained offer? This may involve data, disruption, extortion or a foothold from which more becomes possible later. Sometimes such a route starts with a critical vulnerability. Sometimes with something that looks much less serious on paper. Sometimes through social engineering, stolen accounts, a forgotten external system or a combination of small configuration errors.
The distinction matters. A vulnerability scan detects a technical deviation. An attacker looks for a usable opportunity.
A score is a starting point, not a final decision
Risk scores are useful. Without classification, vulnerability management quickly becomes unworkable. But a score does not provide the full context.
In practice, a critical vulnerability on an internal test system with no external access often poses less risk than a medium-severity vulnerability in a publicly accessible application containing customer data. An externally accessible administration environment with a weak configuration can be more urgent than a theoretically more serious vulnerability on a well-isolated system. Many ransomware attacks also start not with a CVSS 10 vulnerability, but with stolen credentials, a forgotten VPN account or a publicly accessible system that nobody has actively managed for months.
It helps to distinguish between different layers.
There is the technical finding that a system or application is vulnerable. There is exploitability: whether exploitation is practically possible, whether exploit code is available and whether the vulnerability is being actively exploited. There is exposure: whether the system is accessible to someone with malicious intent. There is impact: the consequences if exploitation succeeds. And there is likelihood: the chance that these factors will come together in practice within the organisation's specific context.
Accessibility plays a major role here. A vulnerability may be technically serious, but without a realistic route to the system, the practical risk remains limited. Conversely, a vulnerability with a lower technical score can become urgent when the system is directly accessible from the internet, forms part of a critical chain or exploitation leads to remote code execution. In practice, risk is determined not only by the severity of the vulnerability, but above all by the combination of exploitability, exposure, accessibility and impact.
Many organisations get stuck because these layers become mixed up. A vulnerability is treated as serious because its technical score is high, while exposure is limited. Or the reverse: a finding appears moderate, but sits on a system accessible from the internet that provides access to sensitive processes.
Current threat intelligence also changes priorities. A vulnerability takes on a different urgency when it is known to be actively exploited, when working exploits or proof-of-concept (PoC) code are available, or when it aligns with attack techniques frequently seen at that time. The question is then no longer about theoretical severity, but whether the vulnerability is an attractive target in practice.
This is also reflected in the assessments made by organisations such as the NCSC, which consider not only CVSS scores but also factors such as active exploitation, internet accessibility, existing mitigations
and the realistic likelihood of exploitation within a specific attack path.
The technical characteristics of a vulnerability are therefore only one side of the story. At least as important are where the system sits, who can access it, what data is behind it, what connections exist, whether exploitation is realistic and whether the vulnerability can be combined with other findings.
Sometimes a finding points to something larger than the individual technical problem. If the same type of vulnerability keeps recurring, it may indicate an underlying cause: unclear ownership, temporary systems quietly becoming permanent, missing process agreements or security teams being involved too late in development and administration. Resolving the individual finding is then useful, but not enough. The organisation becomes structurally more resilient only when the cause behind the pattern is also addressed.
This is the difference between information and insight. Information says what was found. Insight says what it means for the organisation. That second step is where the real value emerges: not by simplifying technical information, but by placing it in the context of the environment, the business and the likely attack scenario.
Board-level direction requires translation
In recent years, cybersecurity has definitively shifted from a technical topic to a board-level one. NIS2 plays a major role in this, as digital resilience has become more explicitly the responsibility of boards and senior management. DORA does the same within the financial sector. The GDPR also remains relevant whenever personal data, data breaches and reporting obligations are involved.
But legislation is not the only reason. Customers, regulators, auditors, partners and investors increasingly ask about demonstrable resilience. They want to know whether risks are understood, whether measures work and whether an organisation can explain why particular decisions were made.
Cybersecurity therefore affects not only IT, but also continuity, reputation, customer trust and commercial capability. In some markets, demonstrable resilience directly contributes to trust, customer retention and winning new work.
At the same time, a new problem emerges. Directors are held responsible for digital risks, while the information they receive is still often organised technically. They receive reports, overviews and dashboards, but these do not automatically enable them to provide direction.
A director does not need to know CVE numbers. They do not need to know which port is open or why a particular dependency is outdated. But they must be able to explain why some risks are addressed first and others deliberately left until later.
If a customer, auditor or regulator asks tomorrow how the organisation manages digital risks, “we had a scan carried out” is not a strong answer. A better answer concerns the decisions made based on that scan: which systems are business-critical, which vulnerabilities are actually exposed, which findings can be exploited in practice and which measures demonstrably reduce the risk.
This requires translating technology into board-level language: not reducing it to red, amber and green, but getting to the core. What could happen? How likely is it? What is the potential damage? And what do we do first?
Only then does cybersecurity become manageable. Not because the board understands every technical detail, but because it can direct priorities, risk and responsibility.
The most dangerous vulnerability is not always at the top
Many organisations rely on lists, scores, dashboards and classifications. That brings order to a complex problem. But attackers do not follow that order.
An attacker does not automatically choose the highest-scoring finding. An attacker chooses the route that works. Sometimes that is a known critical vulnerability. Sometimes a forgotten subdomain. Sometimes an old account. Sometimes a combination of mediocre configurations. Sometimes a test environment once put online temporarily and never removed.
Identity increasingly plays a major role in this. Many modern attacks revolve not only around vulnerable software, but around access: accounts with excessive permissions, weak MFA configuration, service accounts usable more broadly than intended or old permissions that were never removed. In such a scenario, the vulnerability is not in a single CVE. It lies in the route made possible by configuration, permissions, accessibility and insufficient detection.
Vulnerability management without an attacker's perspective therefore remains limited. You know what was technically found, but not what can be exploited in practice.
By an attacker's perspective, we do not mean making security more complicated than necessary. It means assessing vulnerabilities for accessibility, exploitability, possible next steps and what an attacker could obtain or disrupt. Only then does it become clear which findings really deserve priority.
Ultimately, an organisation does not only want to know how many vulnerabilities it has. It wants to know which vulnerabilities could actually affect it. Which findings could cause real harm? Which measures reduce risk fastest? Where is the team busy with security, but not with the right priorities?
This calls for a different way of looking at things. Not more dramatic, but more realistic.
From a snapshot to a continuous picture
A good, scenario-driven penetration test remains one of the most powerful ways to make this visible. Not because a penetration test is simply a more extensive scan, but because it shows how vulnerabilities behave in practice.
A penetration test reveals which assumptions are wrong, which measures are less effective than expected, which findings suddenly become more significant in combination and which route an attacker would probably choose. That is the value of manual testing and specialist interpretation.
But not every penetration test delivers that level of insight. Its value depends heavily on quality, scope, timing and how far the assessment is designed around scenarios. A checklist penetration test can be useful, but does not provide the same insight as a test that actually examines attack paths, realistic exploitability and underlying causes.
Moreover, a penetration test always remains a snapshot.
Modern IT environments change continuously. Applications are modified. Cloud environments grow. New systems come online. Suppliers gain integrations. Old test environments remain accessible after all. What posed no risk last month may be visible again today. What was configured correctly during a penetration test may become vulnerable again after a change.
Periodic testing alone is therefore not enough. But neither is continuous scanning alone.
The value lies in the combination. Penetration tests provide depth. Continuous monitoring provides currency. Threat intelligence provides urgency. Validation provides meaning. The attacker's perspective helps determine what truly deserves priority.
This explains why mature security programmes are increasingly moving towards exposure management: continuously understanding, prioritising and validating risks from the perspective of a realistic attack. This brings together attack surface management, vulnerability management, threat intelligence, application testing and validation.
This is where the difference emerges between a list of findings and real insight into risk.
When hundreds of vulnerabilities remain open, it is rarely fair to identify a single party to blame. IT often has too little capacity and too many dependencies. Security teams see the risks, but are not always in a position to enforce priorities. The board is formally responsible, but often does not receive information in a form that allows it to provide effective direction. The business wants speed and continuity, but sometimes underestimates what technical debt means over time.
Everyone holds part of the puzzle. Nobody automatically has the complete picture.
The question of blame is less interesting than the question of responsibility. That responsibility begins when an organisation stops being satisfied with a list of findings and wants to understand what those findings mean.
This is not about an extra classification column or a new dashboard. It is about substantive interpretation: which risks are real in this environment, which are mainly theoretical, which systems are business-critical, which attack paths are plausible and which actions demonstrably deliver the greatest risk reduction?
This calls for a different way of working. No longer merely collecting, classifying and forwarding vulnerabilities, but assessing them in relation to the environment, the business and the realistic attack scenario.
Only then do real priorities emerge. Without those priorities, security teams often remain busy, but not necessarily effective.
The better opening question
Every organisation has vulnerabilities. That is neither news nor a disgrace. Anyone who uses systems, develops applications, manages cloud environments or forms part of complex chains of suppliers and service providers has vulnerabilities. The relevant question is not whether they exist, but which ones really matter.
That is the difference between a technical overview and risk management. A technical overview shows what was found. Risk management shows what it means, what needs to happen first and why.
A good conversation about vulnerabilities therefore does not start by asking which tool is used. Nor by asking how many findings remain open. Not even by asking whether a penetration test was carried out recently.
It starts with a more honest question: does the organisation have a sufficiently clear picture of its real risks? Not just on paper. Not just in a dashboard. Not just as an export from a scanner. But viewed from the perspective of someone seeking to misuse what is visible, accessible or incorrectly configured.
If the answer is no, that is not a criticism. It is a starting point.
Perhaps that starts with a scenario-driven penetration test. Perhaps with continuously mapping the external attack surface. Perhaps with application testing or reassessing existing findings based on practical exploitability.
But do not start with more noise. Start by understanding what an attacker sees today.
Because 340 vulnerabilities on a list are a nuisance. But they are not the real problem.
The real problem is that nobody can say with certainty which of them is dangerous today.
That is exactly where we start at SECWATCH.