Board members don’t care about vulnerability management, but do they care about risk. Read our CSO/CISO guide on how to engage them in terms they understand.
back to BLOG

Reporting to the board: How to talk about vulnerability management

James Harrison

Cybersecurity has often been little more than an afterthought for board members, either a box ticking exercise for compliance, or to make sure all bases are covered after a newsworthy breach. If there’s little technical knowledge at board level, many were happy to throw money at the problem and leave it to the CTO, CISO or IT team to handle.  

But times have changed. Threats are becoming more sophisticated as the attack surface and vendor ecosystems have expanded. And despite significant investment in cybersecurity, the frequency and severity of attacks has not decreased.

As a result, board members are taking more interest in cybersecurity. They want assurance and expect to see a return on their investment in security solutions. So, it’s never been more important to measure, manage and communicate your security programme and controls to the board.

Your role as security leader

Whatever your job title, if you’re responsible for the cybersecurity of your organization, one of your main roles is to make sure the board understands the organization’s cyber risk. But to do this effectively, you need to be able to convey security risks in business terms and help the board understand how cybersecurity impacts the company directly.  

But with no standard framework, it’s no surprise that many CISOs and CTOs create their own custom reports, tailored to their specific organization. This guide has been designed to help you understand what and how to report to a board in various scenarios. We’ll explain what the board is looking for, how to simplify the complexity, and how to choose the right cybersecurity frameworks and metrics.  

Agree your ‘risk appetite’

Firstly, make sure the board accepts that there is always risk. Even the strongest cybersecurity posture is not free of risk. Before you know how much effort and resources you can invest, first you need to understand the board’s ‘risk appetite’ - what’s the worst that could happen if you get hacked? This is not the same for every organization and so the answer will shape how much you get to play with and set expectations.

Ask the board what worries them, since the answers will help you understand their priorities and perception of cybersecurity. They might not understand the risk, your vulnerabilities or what threats you face. If so, you’ll need to go back to basics and explain the threats themselves – such as phishing attacks which could result in malware that infects your data, or how an employee that fails data protection protocols could cause a data breach. Then explain how vulnerabilities are the gaps or weaknesses in your systems that make these threats possible.  

Alternatively, they might be well aware of your vulnerabilities and the risks they pose, and have precise ideas about what their tolerance for security risk should be, given other strategic objectives. But be warned: execs and boards who don’t accept there is always a residual risk may not be the right organizations to work for!

Define the cyber risk

If the business has gone to the trouble of hiring a CISO or invest in a robust security program, it’s unlikely the board wants to reduce its tolerance to risk – there’s a big difference between addressing the OWASP Top 10 and accepting low or even ultra-low-level risk.  

Ultra-low relates to high-security government institutions when you’re not willing to accept any risk posed by nation state-backed threat actors, zero day vulnerabilities, or where exploitation can result in physical harm – so it unlikely to be relevant to a business like yours.  

But you do need to work with the board to understand what the right level of security looks like for your organization, and how much investment, effort and resource that will require. For example, your board may decide not to acquire a company because the security risk is too great. They could choose to control, mitigate and reduce the impact of a threat by investing in security tools and expertise. They can transfer the risk by taking out cyber insurance. Or they can accept the risk and potential impact of business interruption with a contingency budget.

Moving to operational

Many security leaders and CISOs rely on “maturity models” designed around functional areas to give an overview of the strengths and weaknesses of your cyber security. These structure the information in a way that gives both a snapshot of a particular point in time, and progress over time. However, even the National Cyber Security Centre (NCSC) admits there’s no one size fits all model, and advises you to make a custom framework or use a template – here are some useful examples:  

These vary in depth and detail, but they have common themes, so choose one that suits your organization. Use the assessments to give yourself a score in each area. Use it as a living document that you can update as your understanding and needs change and the business evolves.  

It can be useful to present to exec teams monthly with any changes or impacts, and then present a high-level version on a quarterly basis to the board.

All these templates suggest you assign scores and set targets upfront. For example, if you want to score a 4 across all functional areas, then you can present these to the board as red/amber/green. If you score a 0 or 1 it’s red, 2 or 3 it’s amber, and 4 or 5 is green. Plotting these across a dashboard will instantly show progress over time as well as a heat map of where any problems still lie.

Check your cyber hygiene

For businesses, cyber hygiene requires a two-pronged approach to address both technical and nontechnical issues. Technical issues center on security controls, or countermeasures that reduce risks. Nontechnical issues are the policies and procedures that guide how you manage your cyber security, including employee training and security awareness.

Maturity models can also help you structure and strengthen your cyber hygiene, but in terms of understanding what maturity level you’re at – this is where your tools can help you.  

Traditional tools tell you how many vulnerabilities you have, but what’s important is whether the process is working. Are you fixing vulnerabilities on a regular cadence; are you fixing criticals within the specified SLA? It doesn’t matter if one came up yesterday if it’s going to be fixed in 24 hours. Don’t confuse your reporting to the board with state-of-play vs. state-of-process.

The overall numbers are meaningless: you can’t stop the tide, so don’t report on “how many vulnerabilities we have”; this is of no use to the board. Vulnerability management tools like Intruder will help you focus on what’s important to save you time and effort.

For example, what if you’ve got an old box sitting in the corner that can’t be upgraded and is a stain on your cyber hygiene? The right vulnerability management tool can help by uncovering and adding mitigation reasons to vulnerabilities like these, which you can present separately in your report. We’ve written a guide to help with vulnerability assessment reporting.

Break it down or consolidate?

Depending on the size of your business, you could break down your report into separate business units but it’s probably more useful for the board to see a consolidated view. Try giving each functional area an overall score and record why you’re scoring it that way, so you can see what needs to be addressed.

Give the board the right information so you don’t overwhelm them or leave them unsure about where to focus. They just need assurance that your security function works — not a complete digest of what the team is doing.  

Two processes critical to this are the monitoring, alerting, and escalation of incidents (how your team knows that something has gone wrong, and how quickly the correct people know) and the response (what your security team does if there’s a breach).  

However, you should also report any significant gaps, what’s the potential impact, whether to accept them, or if you need further resources to address them. Explain how your team scans for and assesses emerging risks, and what those risks might be.  

Reassure them that they are addressed methodically and in good time, and that you practice good cyber hygiene. And if not, what resources you need to do so.

Keep it simple and on point

Different types of meeting require a different presentation style and set of metrics. If you’re meeting the board for the first time, the board will want to hear your assessment of the current state, what’s working, what needs to change, what your goals are, and what you need to get it done.  

It’s key to show that you have command of the situation, and more importantly, a vision for the future. This is an opportunity to build rapport and trust. The success of everything else you might report to the board flows from this early investment in your time.  

If you’re reviewing budgets, the board will want to see results related to business outcomes. In annual planning and strategy meetings, you’ll need to show you’re in sync with the needs of the business and its strategic priorities.  

For example, if one of the goals is to have 50% of digital assets move to the cloud, you should present a plan to facilitate that by de-risking the process. In monthly or quarterly status updates, the board wants to hear what you’re prioritizing and why. Do you have the personnel and budget to execute on everything that needs to be done?  

When vulnerabilities hit the headlines  

When a vulnerability does hit the headlines, event-driven board meetings can be stressful, but if you’ve done your tabletop exercises, you should be ready. Be prepared to succinctly speak in non-technical language about what happened, what it means, and how it can be solved.  

Don’t avoid the questions – your board should trust you. If you’re using a vulnerability scanner like Intruder, you can show that you’ve identified any vulnerabilities and emerging threats because it provides reports and guidance that’s easy to export, understand and action. Peace of mind is priceless, so when there is an issue, you can reply to the board that there’s no need to panic.

Keep your reporting up-to-date

Threats and vulnerabilities change constantly. Either new threats emerge, new technologies pose new challenges, regulations change, or the company shifts to new operations.  

No single, static report to the board can encompass all those things for long. Your report to the board therefore should always be a conversation as much as a structured report. The conversation should guide what that structure should be – not vice-versa. And the conversation should always start with the question:

“How well protected are we, and is that protection enough?”

Why not see how Intruder can be a core part of your cybersecurity program? It's powerful but designed for simplicity, with easy to understand and action reporting - ideal for your state-of-play reports to the board. Start your free trial today or get in touch for more information.

Release Date
Level of Ideal
Before CVE details are published
Limited public information is available about the vulnerability.

Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.

Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Day of CVE publish
Vulnerability information is publicly accessible.

Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.

Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
First week since CVE publish
Vulnerability information has been publicly available for up to 1 week.

The likelihood that exploitation in the wild is going to be happening is steadily increasing.

Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
Between 1 week and 1 month since CVE publish
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

We’re starting to lose some of the benefit of rapid, automated vulnerability detection.

Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
After 1 month since CVE publish
Information has been publicly available for more than 31 days.

Any detection released a month after the details are publicly available is decreasing in value for me.

Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.

With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:

These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.

We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.

In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.

Figure 11: Percentage chance of delay for critical vulnerabilities

So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.

I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.

What can we take away from Figure 12?

Figure 12: Release delay year-on-year (lower is better)

With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.

The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.

Written by

James Harrison

Recommended articles

Ready to get started with your 14-day trial?

try for free