A board pentest report should fit on one page, keep proven findings and unconfirmed ones in separate sections, and end with the decisions the board is being asked to make. Below is a template you can copy. It works for a human-led test, an AI-assisted one, or a mix. The rest of the post explains each field and what to leave out.
What the board needs from a pentest
A board does not triage findings. It oversees risk, sets risk appetite and allocates money and people. A pentest report for the board should help it do those things, and nothing else.
That reduces to three questions. What have we confirmed is exposed? Is it getting better or worse? What do you need from us?
Some board security packs answer a fourth question nobody asked: how busy was the security team? Counts of tests run, tools deployed and issues logged describe activity. They do not describe exposure.
The template
Copy this into your board pack. Fields in square brackets stay blank until you fill them from your own reports. Do not estimate a field you cannot fill. Write "not measured" instead.
# Penetration testing: board summary, [PERIOD]
**Headline:** [One sentence. The most important confirmed exposure and what is
being done, or "No proven high-severity findings open."]
## 1. What was tested
| Tested this period | Not tested this period | Method |
|---|---|---|
| [assets / applications] | [out of scope, not reached, or stopped early] | [human-led / AI-assisted, human-supervised / both] |
## 2. Proven findings (reproduced, with stored evidence)
| Severity | Open at start | Opened | Closed (retest with evidence) | Open at end | Oldest open | Owner |
|---|---|---|---|---|---|---|
| Critical | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| High | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| Medium | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
## 3. Needs review (not yet confirmed; a workload, not a risk count)
| Items awaiting review | Oldest item | Expected cleared by |
|---|---|---|
| [ ] | [ ] | [date] |
## 4. Trend (same scope, last three periods)
| Measure | [Period -2] | [Period -1] | [This period] |
|---|---|---|---|
| Proven critical + high open at end | [ ] | [ ] | [ ] |
| Median days to close a proven high | [ ] | [ ] | [ ] |
| Retests passed / attempted | [ ] | [ ] | [ ] |
Scope note: [did scope change between periods? If yes, say the trend is not like-for-like]
## 5. Decisions requested
1. [Decision], yes or no, by [date]. If no decision: [consequence].
2. [Decision], yes or no, by [date]. If no decision: [consequence].
## 6. Assurance
Evidence for each proven finding is held in [system] and is available to
[audit committee / internal audit] on request.
Prepared by [name, role]. Testing performed by [team / vendor].
That is the whole page. If it runs to two, cut from section 1 first.
Why proven and needs review never share a number
This is the rule that matters most. Add confirmed and unconfirmed findings into one total and the board will remember the total. If some of those items later turn out to be nothing, the next report shows a drop that was never a fix. If they turn out to be real, the first report understated them. Either way, the board learns to distrust the number.
A proven finding is one with stored evidence that it reproduces. In Arxiis that has a precise meaning. A finding is labelled proven only when its evidence binds to a record in the tamper-evident, hash-chained execution ledger. Anything else is labelled needs review, and report language is scrubbed of claims the evidence does not support. Our proof spine page describes the mechanism. For a human-led test, ask the tester for the same split: reproduced with evidence, or not.
Section 3 then reports the unconfirmed items as what they are, a workload. The board should see that the queue exists and is being cleared. It should not see those items scored by severity, because nobody has confirmed the severity yet. Our post on why we let our AI say "I don't know" explains why that label is an output, not a caveat.
How to fill each section
Headline. One sentence, written last. Name the most important confirmed exposure and what is being done about it. If nothing proven is open at high severity, say so plainly. Do not use the headline for activity.
What was tested. The "not tested" column matters as much as the tested one. A board that sees only what was tested will assume everything was. List assets out of scope, assets testing did not reach, and any run that stopped early. With Arxiis, a run stopped by its budget or time watchdog produces a partial report that says so. Describe it as partial coverage on this page too.
Proven findings. Use your own severity scale, the one engineering already works to. "Closed" means a retest produced evidence that the finding no longer reproduces. A closed ticket is not a closed finding. "Oldest open" is the column boards act on, because it shows where remediation is stuck.
Trend. Three periods is the minimum for a trend. Keep scope the same, or say clearly that it changed. A rise in open findings after a new application entered scope is not deterioration. It is coverage. If you test on a cadence, our post on continuous penetration testing covers how to keep periods comparable.
Assurance. One line saying where the evidence lives and who can ask for it. The board does not need to read evidence. It needs to know evidence exists and that an auditor can check it. With Arxiis, that is each engagement's tamper-evident execution ledger. Store the final hash somewhere your own team controls. Post 15 covers what counts as penetration testing evidence.
Decisions to ask for
A board report without a decision is an update. Updates have their place, but they do not use the board for what it is for. Decisions a pentest result typically supports:
- Accept a named risk for a fixed period, with an owner and a review date.
- Fund remediation, when a proven finding needs engineering time the roadmap does not have.
- Extend scope, when an asset in the "not tested" column should be tested.
- Set or change the testing cadence for an asset.
- Change a supplier, when a vendor cannot show evidence for its findings.
Write each one as a yes-or-no question with a date. Then add what happens if no decision is made. Boards respond to consequences stated plainly.
An illustrative example, with placeholders rather than real figures: "Approve [N] engineering weeks to close the proven high-severity finding on [application] before [date]. If no decision: it stays open past the policy deadline and is reported as an exception next period."
What to leave out
A board pack is read by more people than the security team, and it travels further. Leave these out:
- Technical detail. No payloads, request bodies, exploitation screenshots or reproduction steps. That belongs in the technical report, under access control.
- Unconfirmed items scored by severity. They sit in section 3 as a count.
- Raw tool output and scanner totals. Volume is not exposure.
- Activity counts presented as outcomes: tests run, hours spent, requests sent.
- Vendor benchmark scores. They describe a tool on a public benchmark, not your estate.
- Scoring vector strings and internal identifiers the board cannot act on.
- Fear framing. The board should leave knowing what is confirmed, not what might happen.
Before it reaches the board
Walk the draft through with the engineering owners named in section 2 first. Every owner should have agreed their row, their dates and any decision that depends on them. A board that hears an owner dispute a date in the meeting stops trusting the page.
Decide, too, which committee sees it. Some boards delegate detailed security oversight to an audit or risk committee. In that case the committee gets this page and the full board gets the headline and the decisions.
What a one-page report hides
A single page compresses. "One critical" can hide whether it sits on the payments API or a test server, so name it in the headline if it matters. A needs-review count can hide one item that will turn out to be serious, so watch the age column. And "what was tested" is a list, not a coverage percentage, because a percentage needs a denominator most estates do not have.
The template does not remove those limits. It makes them visible. So ask one question of your next board pack. Is the "not tested" column longer than the board expects, and have they ever been shown it?
How often to send it
Match the report to the board's own calendar, not to the testing calendar. If tests run more often than the board meets, roll the period up and report the latest state of each proven finding.
Send the same page to the same audience each time. A board learns to read a format. Changing the layout every quarter makes trends harder to see than the numbers themselves.
Keep the detailed findings, the evidence and the retest records with the security team and the audit or risk committee. The board page should point to where they live, so any director can ask for them.
If a period produced no new proven findings, still send the page. "Nothing new was proven, and here is what was tested" is a useful statement for a board to hear.
Frequently asked questions
What should a board pentest report include?
One page with what was tested and not tested, proven findings by severity with ages and owners, and items awaiting review shown separately. Add a trend over at least three periods on the same scope, the decisions requested, and a line on where the evidence is held.
Should unconfirmed pentest findings go in a board report?
Yes, as a separate count of items awaiting review, with the age of the oldest item. They should not be added to the proven total or scored by severity, because nobody has confirmed them yet.
What should be left out of a pentest report for executives?
Payloads, reproduction steps, exploitation screenshots, raw tool output, scanner totals, activity counts, vendor benchmark scores and identifiers the board cannot act on. Those belong in the technical report.
How do you show pentest trends to a board?
Use at least three periods on the same scope. Track proven critical and high findings open at period end, median days to close a proven high, and retests passed against retests attempted. If scope changed, say so, because the trend is no longer like-for-like.
What does proven mean in an Arxiis report?
A finding is labelled proven only when its evidence binds to a record in the Arxiis tamper-evident, hash-chained execution ledger. Anything else is labelled needs review and is reported separately.
See it on your own stack.
Arxiis runs a coordinated crew of specialist agents through a full engagement in hours, not weeks. Every finding is CVSS-scored, MITRE ATT&CK-tagged and auto-mapped to RBI CSF, CERT-In and nine more frameworks — and every command lands in a tamper-evident ledger. It runs entirely on your own infrastructure.
