Pentest Executive Summary Example and Template
Quick answer. A pentest executive summary states what was tested and when, the overall risk, the top findings in business terms, their status after retest, and what was not tested. It ends with the decisions leadership must make.
Video transcript
Most people who see a pentest report never read the findings. The executive summary is the page they read, and done badly, it alarms them or tells them nothing.
Leaders need five answers. What you tested and when, how exposed you are, what an attacker could do, what is fixed or open, and what was not tested.
Give one overall rating with a one sentence reason. FIRST, which maintains CVSS, says Base scores should not be used alone to assess risk.
In a fictional example, Acme Exchange rates High. A withdrawal flaw that skipped the two factor check is fixed and retested. Unreviewed production deploys stay open, with an owner and a date.
Then say what was not tested, like Acme's mobile apps, hot wallet signer and custodian. Otherwise a clean result on half the system reads as a clean system.
Avoid counts without context, jargon, and stale status that never says whether fixes were retested. Past about a page, it stops being a summary.
End with an ask. Acme's summary requests two engineer-weeks for the CI fix and confirmation of a Medium risk acceptance.
Read the full article for the copy-ready template. Or book a system review: an hour with a Guardian engineer, then a written summary of what stood out.
Not everyone who sees a pentest report will read the findings. A board, a bank partner or a listing team wants to know what was tested, how bad it is and whether it is fixed.
The executive summary is that page. Written badly, it either alarms people or tells them nothing.
Below: what published guidance says it should contain, a worked example for a fictional crypto exchange, and a template to copy.
What Executives Need
PTES writes the executive summary for "those who are in charge of the oversight and strategic vision of the security program."
The OWASP Web Security Testing Guide likens it to "the elevator pitch of the report." Its advice: "Focus on the business impact and leave out technical details for now."
Those readers need five answers:
- What did we test, when, and why?
- How exposed are we overall?
- What could an attacker actually do to us?
- What is fixed, and what is still open?
- What did the test not cover?
A board report rolls this up across all your security work. See our board report template.
Structure of a Good Summary
From PTES, OWASP and NIST SP 800-115 guidance, a good summary has six parts:
| Part | What it says | Where the guidance comes from |
|---|---|---|
| Scope and window | Systems tested, dates and the test's objective | OWASP: objective, plus scope and timeline from its introduction |
| Overall risk | One rating, and why | PTES: risk ranking or profile |
| Top findings | Three to five, each with its business impact | OWASP: key findings in a business context |
| Remediation status | Fixed and retested, open with a date, or accepted | NIST: plan of action and milestones |
| Not tested | Exclusions and limits on the test | OWASP: limitations, from its introduction |
| Recommendations | Strategic next steps and the effort they take | PTES: recommendation summary, roadmap |
Overall risk
Give one rating and say why in a sentence. PTES puts the overall risk ranking in the executive summary, "identified and explained."
Do not lead with a CVSS number. FIRST, which maintains CVSS, says Base scores measure severity and "should not be used alone to assess risk."
Business impact
Translate each finding into what it could cost: customer funds, downtime, a regulator's question or a partner's trust.
OWASP names "possible compliance issues, reputation damage" as examples of the business context to give.
Remediation status
Report status after the retest, not before. NIST notes testers can verify a fix only by repeating the original test.
What was not tested
OWASP lists limitations to state: out-of-bounds areas, broken functionality, lack of cooperation, time, access or credentials.
The UK's NCSC adds that a well-scoped test can give confidence in what it tested "at the time of the test." Say when that was.
Sample Summary: A Fictional Exchange
This example is fictional. Acme Exchange, its systems and its findings are invented to show the format.
Engagement. Gray-box pentest of Acme Exchange, ten business days of testing, with source access and test accounts for every role.
Objective. Find any path from an outsider or a customer account to other customers' funds or data.
Scope. Customer web app, public trading API and the production cloud account. Withdrawals and signing were tested in staging, on test keys.
Overall risk: High. Testers found one path to customer funds; it is fixed and retested. One High finding is still open, with an owner and a date.
Top findings.
| Finding | Business impact | Severity | Status |
|---|---|---|---|
| New withdrawal addresses skipped the 2FA check | A stolen session could empty that customer's balance | Critical | Fixed, retested |
| Read-only API keys could cancel orders | A leaked key could disrupt a customer's trading | High | Fixed, retest booked |
| CI could deploy to production without review | One stolen developer token could ship malicious code | High | Open, fix due in three weeks |
| Login rate limits applied per IP only | Password guessing from many IPs goes unthrottled | Medium | Risk accepted, monitored |
Not tested. Mobile apps, the production hot wallet signer and its keys, the third-party custodian, social engineering and denial of service.
Recommendations.
- Require 2FA on every change to where funds can go.
- Require a second reviewer on every production deploy.
- Test the mobile apps before launch.
Decisions needed. Approve two engineer-weeks for the CI fix. Confirm the Medium risk acceptance at the next risk meeting.
That is the whole summary. Evidence and reproduction steps belong in the technical report. For what an exchange test should cover, see crypto exchange pentesting.
Common Mistakes
- Counts without context: "14 findings" says nothing without severity and status.
- CVSS as risk: FIRST says Base scores should not be used alone to assess risk.
- Jargon: OWASP says to "avoid jargon and negative speculation."
- Hidden exclusions: a clean result on half the system reads as a clean system.
- Stale status: say whether fixes were retested, and when.
- No ask: end with the decisions or budget you need.
- Too long: past about a page, it stops being a summary.
Copy-Ready Template
Fill in the brackets. Keep it to about one page.
- Engagement: [tester], [testing dates], [black, gray or white box].
- Objective: [the question the test answered].
- Scope: [systems], [environments], [source access: yes or no].
- Overall risk: [Critical, High, Medium or Low], because [one sentence].
- Top findings: [finding], [business impact], [severity], [status].
- Remediation: [n fixed and retested], [n open with owners and dates], [n accepted].
- Not tested: [exclusions], [limitations].
- Recommendations: [two or three strategic changes], [effort].
- Decisions needed: [approvals, budget, risk acceptances].
- Next test: [date, or a trigger such as a launch].
Planning the retest or the next round? See how long a pentest takes and what a Web3 pentest costs.
How Guardian Can Help
Guardian's pentests cover web apps, APIs, cloud and SDKs, tested by your contract auditors for exploitable paths to funds.
Engagements also cover browser extensions and offchain automation such as keepers, relayers and threshold signers.
Each is scoped by what it tests: a web app by what a user can actually do in it, an API by endpoint count and the roles behind them.
Not sure what your next test should cover? Book a system review: an hour with a Guardian engineer, then a written summary of what stood out and what a first ninety days would cover.
Frequently Asked Questions
How long should a pentest executive summary be?
No standard sets a length. OWASP likens it to an elevator pitch, and PTES writes it for those overseeing the security program. About one page is a practical target, with detail left to the technical report.
Should an executive summary include CVSS scores?
Not as the headline. FIRST says CVSS Base scores measure severity and should not be used alone to assess risk. Give a plain overall rating with the reason, and keep CVSS vectors in the technical findings.
What is the difference between the executive summary and the technical report?
The summary tells leaders what was tested, how exposed they are, what is fixed and what they must decide. The technical report holds the evidence, reproduction steps and fixes for each finding.
Should the summary say what was not tested?
Yes. OWASP lists limitations to state, such as out-of-bounds areas, lack of time and lack of access or credentials. Without them, a clean result on part of a system reads as a clean system.
Sources
- PTES: Reporting (mirror of pentest-standard.org)
- OWASP: Web Security Testing Guide v4.2, Reporting
- NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008)
- FIRST: CVSS v4.0 User Guide, document version 1.2 (November 14, 2025)
- NCSC: Penetration testing (published August 8, 2017; reviewed January 10, 2022)
- Guardian: Penetration Testing
- Guardian: System review
Plan your next pentest with Guardian
Guardian pentests web apps, APIs, cloud and SDKs for exploitable paths to funds, scoped by what each engagement covers.