From CVE list to board report: how do you filter cyber noise for the board?
Published on June 12, 2026
Introduction
Every security officer knows the moment: the quarterly report for the board is due, and the source is an export with 1,400 open findings. Too many to show, too important to leave out. The temptation is to take the safe route — a bar chart with counts per severity category — but that does not answer the question the board actually has: are we running unacceptable risk, and are we doing the right things?
In our article for CISOs we described why a vulnerability list is not board-level evidence. This article takes the next step: how do you practically filter out the noise, and what does a board report look like that can actually be steered on?
The gap between technical vulnerabilities and business risk
A CVSS score measures the technical severity of a vulnerability — not the risk to your organisation. That difference is the core of the filtering problem. A "critical" vulnerability on an internal test system without sensitive data is less relevant to the board than a "medium" finding on the customer portal that carries your primary revenue.
Reporting unfiltered creates two problems at once. The board gets used to big red numbers that never lead to an incident (alarm fatigue), and when there is an acute threat, the contrast to make that clear is missing. Cyber noise is therefore not just inconvenient — it actively undermines the board's ability to fulfil its NIS2 oversight role.
| What the technology delivers | What the board needs |
|---|---|
| 1,400 open findings with CVSS scores | The five risks that affect continuity, data or chain position |
| Counts per severity category | Trend: are we getting faster or slower at remediation? |
| Scan results of known systems | What appeared new or unknown this period |
| Technical descriptions per CVE | Decision questions: accept, budget or escalate? |
Filtering the noise: prioritisation based on exploitability
The practical solution is a filtering funnel with three questions, in this order:
1. Is the vulnerability actually exposed? A vulnerability on a service reachable from the internet weighs fundamentally more than the same vulnerability behind a VPN. This is why the external attack surface is the logical starting point of any prioritisation: it is exactly what an attacker sees of your domain.
2. Is the vulnerability exploitable? Not every CVE with a high score is abused in practice. Two freely available sources make this measurable: the KEV catalogue from the US CISA (vulnerabilities for which exploitation has actually been observed) and EPSS (a score estimating the probability of exploitation within 30 days). A finding that is internet-facing and in the KEV always ranks above a higher CVSS score without known exploitation.
3. Does the vulnerability affect a critical process? Link the remaining findings to the processes they affect: customer portal, invoicing, primary services, personal data. This is the step that translates technology into board language — and the only step nobody but your own organisation can take.
What passes all three filters is the list for the board report. In practice, hundreds of findings reduce to five to ten. The rest does not disappear — it is handled routinely within the agreed remediation deadlines — but it no longer burdens the board.
How do you build an effective NIS2 dashboard for the board?
A board dashboard is not a shrunken version of the security dashboard. It has its own layout, with stable indicators that are comparable quarter over quarter. A proven setup in five blocks:
| Block | Content | The board question it answers |
|---|---|---|
| Attack surface | New or unknown domains, services and systems this period | Do we know our own outside? |
| Top findings | The 5–10 filtered risks, with owner and deadline | Where are we really at risk now? |
| Remediation performance | Time-to-remediate per category, findings outside SLA | Is our control working? |
| Risk acceptance | Which risks we consciously accept, why and until when | Which decisions are ours to make? |
| Supply chain | Findings at or via suppliers and external connections | Are we meeting our supply-chain duty of care? |
Two additional lessons from practice. First: report trends, not snapshots — "time-to-remediate for critical findings dropped from 21 to 14 days" is steering information, "43 findings are open" is not. Second: end every block with an explicit decision question or the statement that no decision is needed. A report without a decision question trains the board not to pay attention.
Under NIS2 this dashboard has a second function: it is evidence in itself. A board that can demonstrably show it discussed and decided on these five blocks every quarter has exactly the file that Article 20 of the directive presupposes — see also our NIS2 roadmap for public-sector boards.
The condition underneath it all: reliable source data
One warning to conclude. A dashboard is only as good as its source data. Whoever filters on exposure must have the external attack surface continuously and completely in view — including the forgotten subdomains and test environments that appear in no register. And whoever reports remediation performance must actually re-verify remediation, not tick it off based on a ticket status.
That is exactly where evidence-first monitoring makes the difference: every finding is traceable to a dated observation, and remediation is validated by measuring again. The resulting report does not have to be believed — it can be verified.
Conclusion
The road from CVE list to board report is not a summary but a filtering process: exposure, exploitability, business impact. What remains, you present in a fixed dashboard with trends and decision questions. The board thus gets exactly what NIS2 asks of it: enough insight to steer, without drowning in technology.
Exposentry automates the bottom of that funnel: continuous monitoring of your external attack surface, findings with traceable evidence and reports you can incorporate directly into your board report. See the plans and pricing or start with a first scan.
Sources
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
- FIRST, "Exploit Prediction Scoring System (EPSS)" — first.org
- NCSC, "Vragen die je als bestuurder kunt stellen aan de CISO" — ncsc.nl
- EUR-Lex, Directive (EU) 2022/2555, Article 20 — eur-lex.europa.eu
Written by Edward Hasekamp, founder of Exposentry and core maintainer of the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides NL-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.