Penetration Test Executive Summary Examples: Three Written Out

A good penetration test executive summary says what was tested, what an attacker could actually achieve, which findings combine to make that possible, what to fix first and what the client does well, in words a director can repeat. Below are three written out in full, for a web application, an internal network and a cloud account, each followed by why it works, so you can see the structure doing its job rather than read a description of it.

The principles behind them are in writing a pentest executive summary that gets read. This post is the worked version. The clients, dates and finding numbers are invented; the shape is the point.

What all three have in common

Each summary has the same five parts, in the same order, because it is the order a reader thinks in:

1. What was tested. The system, the dates and the position the testers worked from, in a sentence or two.
2. The outcome. What an attacker could achieve, stated as a result rather than as a count of findings.
3. The chain. Which findings combine to make that outcome possible, by their number in the report, and why the combination is worse than its parts.
4. What to fix first. In order, starting with the change that breaks the chain.
5. What is working. Specific defences that held, so the client knows what not to undo.

The third part is the one most summaries skip. Individually rated findings are honest about each weakness, but a reader who sees three mediums concludes there is nothing urgent, when the three together may be the most serious thing in the report.

Example one: a customer web application

We tested the customer portal and its mobile API between 6 and 17 October 2026, as an attacker on the internet with no account and as a signed-in customer, using two test accounts provided for the purpose. The portal holds customers’ personal details and payment history.

An attacker on the internet could take over customer accounts knowing nothing more than a list of email addresses. Three findings make this realistic rather than theoretical: the sign-in page accepts unlimited password attempts (finding 2), the password policy accepts common passwords such as Password1 (finding 4), and two-factor authentication is offered to customers but never required (finding 5). Each is rated medium on its own; together they put every customer who reuses a weak password at risk. Separately, a signed-in customer could read any other customer’s statements by changing a number in the page address (finding 1, high), which needs no guessing at all.

We recommend, in this order: fixing the statement access check, which is one change to how the portal confirms who owns a statement; limiting sign-in attempts per account and per source; and requiring a second factor at least before payment details change.

The portal’s defences against injection were strong, and we found no way to run code or commands on it. Sessions ended on sign-out and expired after inactivity, and its transport security follows current guidance.

Why it works:

• The outcome comes first and is something a director can picture: accounts taken over, not “weaknesses in authentication”.
• Three mediums are shown as one problem, with the reason the combination matters, so nobody files them as housekeeping.
• The high is kept apart from the chain, because it stands on its own and needs no help.
• The fixes are ordered by what they stop, and the first is described by its size, so the reader knows it is quick.

Example two: an internal network

Between 3 and 7 November 2026 we tested the head office network from a laptop connected to a network point in a spare office, as an attacker who had gained a foothold inside the building or on a single workstation.

From that position we gained full administrative control of the Windows domain within two days, which in practice means control of every server and workstation and the data on them. No single weakness made this possible. The network still uses a legacy name lookup that gives users’ password hashes to anyone who answers it (finding 1); several of those passwords were weak enough to recover offline (finding 3); a service account used for backups had far more privilege than its job needed (finding 2); and the same local administrator password was set on every workstation (finding 4). Removing any one of these would have slowed us; removing the backup account’s excess privilege would have stopped this route outright.

We recommend first reducing the backup service account to the rights it needs and giving it a long random password, then switching off the legacy name lookup, and then giving every workstation its own local administrator password, which Windows can manage automatically.

Detection was a strength. The security team noticed our activity on the second day and asked us about it, and endpoint protection blocked two of our first attempts outright.

Why it works:

• It says what domain control means in practice, because “domain administrator” means nothing to most boards.
• The chain is told as four plain facts, each with its finding number, so a technical reader can go straight to the detail.
• It names the one fix that breaks the route, which is the most useful sentence in the report for whoever sets priorities.
• It credits the security team specifically, which is both fair and a reason for them to read the rest.

Example three: a cloud account

Between 20 and 24 October 2026 we reviewed the configuration of the production cloud account with read-only access, tested its internet-facing services, and searched public sources for anything belonging to it.

Customer documents stored in the account could be downloaded by anyone on the internet who knew or guessed a file name, because one storage bucket allows public reads (finding 1, high). The exposure is larger than that finding suggests on its own: file names follow a predictable pattern based on the customer number (finding 3), and an access key for a deployment user, published in a public code repository, still works and can list the bucket’s contents (finding 2, critical). Together they mean the whole collection could be copied, not just individual files.

We recommend first deactivating the exposed access key and reviewing what it has been used for, then removing public access from the bucket and serving documents through short-lived signed links, and then moving deployments to short-lived credentials so that no long-lived key exists to leak.

Most of the account was well configured. Administrative access requires a second factor, audit logging is on in every region, and production and development are kept in separate accounts.

Why it works:

• The first fix stops the harm today: deactivating a working key closes the route at once, before the slower changes to the bucket and the deployments.
• It explains why a high finding is worse here than its rating, without re-rating it, which keeps the findings honest and the summary accurate.
• The good practice it names is specific enough to be checked, which is what makes it credible rather than polite.

When nothing serious was found

A clean result deserves the same structure, with the outcome stated plainly:

We found no way for an attacker on the internet to reach customer data or take control of the application during ten days of testing, as an unauthenticated user and with accounts at each of its three roles. The five findings in this report are rated low or informational; the two worth doing soon are listed below.

Then say what was exercised and what was out of scope, so the result is not read as a guarantee. Inventing concern to justify the fee is obvious to every technical reader, and a client told the truth about a good result comes back.

What to leave out

• A severity tally as the headline. “2 high, 5 medium, 9 low” describes the report, not the risk. It can sit in a small table after the prose.
• Every finding. Name the ones that drive the outcome and leave the rest to the body.
• Scores and vectors. They belong on each finding, where a reader can check them; see penetration testing severity levels for how the ratings themselves are decided.
• Tool names and jargon. “Legacy name lookup” works for a board; the protocol names belong in the finding.

Where findings chained, the steps themselves belong in an attack narrative after the summary; writing the attack narrative in a pentest report covers it, and how to write a penetration test report covers the order the whole report is best written in.