From CVE list to board report: how do you filter cyber noise for the board?
Published on June 12, 2026 · Updated on August 4, 2026
Every security officer knows the moment: the quarterly report for the board is due, and the source is, say, an export with more than a thousand 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. The risk to your organisation only follows from exposure and business impact. 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 therefore actively undermines the board's ability to fulfil its NIS2 oversight role.
| What the technology delivers | What the board needs |
|---|---|
| Thousands of open findings with CVSS scores | The handful of 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 almost 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 usually ranks above a higher CVSS score without known exploitation. The final order depends on context, because exposure, exploitability and EPSS/KEV do not carry equal weight in every situation; see which vulnerability to fix first.
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 typically reduce to just a handful. 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 has its own layout, with stable indicators that are comparable quarter over quarter. A workable 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 | A handful of 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. A line like "time-to-remediate for critical findings dropped from 21 to 14 days" gives the board direction and pace, and that is steering information. Second: end every block with an explicit decision question or the statement that no decision is needed. Leave that decision question out and you risk the board tuning out.
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 provides evidence that supports the file Article 20 of the directive calls for. 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, with a fresh measurement.
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 is one every recipient can verify for themselves. The report itself is digitally signed (PAdES) and carries an RFC3161 timestamp, so any later change becomes demonstrable: a measurement you can recheck.
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 on top of OpenKAT, the open-source scanner from the Dutch government to which founder Edward Hasekamp contributes as a collaborator: 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 collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.