How to Tell Your Board What Your Pentest Actually Found

You have a pentest report. It is 40 pages long, full of CVSS scores, and your board meeting starts in ten minutes. Nobody on that board wants to hear about a reflected XSS on a staging subdomain. They want to know if the company is in danger, what you are doing about it, and whether they should be worried.

This is the conversation most CISOs get wrong, not because they lack the answers, but because they walk in with a vulnerability report instead of a risk briefing. Those are two different documents, and only one of them belongs in a boardroom.

What the board is actually asking

Strip away the phrasing and every board question about a pentest collapses into three:

1. Could this hurt us? Not “is this a 9.8 CVSS score,” but could it lead to a breach, a regulatory fine, or a lost customer.
2. Did we know about it, and for how long? Boards are increasingly asking about time-to-remediate, not just finding counts, because that is what regulators and cyber insurers ask about.
3. What changes because of this? A pentest that produces the same recommendations as last year’s is a governance problem, not a technical one.

If your presentation cannot answer these three questions in the first two minutes, the rest of the meeting is noise.

Translate severity into business language, not CVE scores

CVSS was built to communicate technical severity between practitioners, not to inform a board that oversees the entire company’s risk posture. Directors do not know what a 7.5 means, and reciting scores in a boardroom signals that you have not done the translation work yourself.

Instead, group findings into three plain categories:

• Findings that could lead to a material incident (data exposure, unauthorized access to production, anything that touches customer data or core systems)
• Findings that increase risk but require additional conditions to exploit (misconfigurations, weak segmentation, missing hardening)
• Findings that are hygiene issues (outdated software with no known exploit path, minor information disclosure)

This is the same triage EliteSec applies when we scope and report engagements: severity is meaningless without business context. A critical finding on an isolated test server is not the same conversation as a medium finding on your payment processing path.

Framing remediation status honestly

Boards do not just want to hear that findings were “closed.” A closed Jira ticket and a fixed vulnerability are not the same thing, and directors who have sat through a breach postmortem know this. If your board asks for a retest confirmation and you cannot provide one, say so plainly. That is a more credible answer than a green dashboard nobody has verified.

We wrote about this gap in more detail in Finding Closed Is Not Finding Fixed: Who Actually Owns Remediation After a Pentest, and it is worth internalizing before you walk into the boardroom. The short version: remediation status should always distinguish between “a developer says this is fixed” and “a tester confirmed this is fixed.” Boards deserve to know which one they are looking at.

A 10-minute structure that actually works

You do not need 40 slides. You need four.

1. Scope and objective (1 minute): What was tested, why now, and against what standard.
2. Overall risk posture (2 minutes): The three-tier severity breakdown above, framed in business terms.
3. What changed since last time (3 minutes): Findings resolved and verified, findings still open and why, and any new risk introduced by changes to the environment.
4. What you need from the board (4 minutes): Budget, a policy decision, or simply their awareness. If there is nothing you need from them, say that too. Boards respect a CISO who does not pad the ask.

This structure works because it mirrors how boards already evaluate other forms of risk, financial, legal, operational. Security should not require a special mental model. It requires the same discipline applied to a domain most directors were never trained in.

The report is not the presentation

The pentest report is written for your team to act on. The board conversation is written to inform a governance decision. Conflating the two is why so many board security updates fall flat, either too technical to be useful or too vague to be credible.

If you are preparing for a board update and are not confident in how to frame residual risk, that is a good signal to bring in a second set of eyes before the meeting, not after a director asks a question you cannot answer.

Contact EliteSec if you want that second set of eyes before your next board meeting.