Hack The Box’s guide to the penetration test report format is written for the tester: how to take notes and which sections to cover. The person paying needs more: 8 sections including the retest results, 9 fields on every finding, a one-page summary a customer can read, and a signed agreement saying who authorized the test.
The penetration test report format: eight sections, in order
A penetration test report format has 8 sections, in this order: cover and confidentiality, executive summary, scope and authorization, methodology, findings summary, detailed findings, remediation and retest results, and appendices. The buyer’s test is simple: section 3 matches the signed agreement, and section 7 exists before the report is called final.
A penetration test report is the tester’s written record of what was tested, what was found and how to fix each finding; the version worth paying for also records what was retested and whether the fix held. How the test itself is scoped and run is a separate subject, covered in web application penetration testing, and this page sits under the wider guide to web app security for an AI-built app.
A pentest report template comes as a Word file, a PDF or a GitHub folder, and the file type changes nothing: a penetration test report template in any of them should carry the eight sections below. The last column of this pentesting report template is the one I added for the person paying, and it is my framing, not a standard’s.
| Section | What it contains | Who reads it | The buyer’s check |
|---|---|---|---|
| Cover and confidentiality | Client, tester, dates of testing, report version, distribution list | Anyone holding the file | The version and the distribution list are filled in, so you know which copy a customer saw |
| Executive summary | One page: what was tested, what matters, what is fixed | Founders, customers, auditors | It can be forwarded as is (the next section explains) |
| Scope and authorization | Targets by hostname, accounts and roles used, what was out, the dates, who authorized, deviations from the agreed plan | You, your lawyer, an auditor | It matches the signed agreement line for line; every deviation is listed |
| Methodology | The named standard followed and the test type: black, gray or white box | Your developer, an auditor | A standard is named and the test type matches what you paid for |
| Findings summary | One table: id, title, severity, status | Everyone | Every finding in the detail appears here, with a status |
| Detailed findings | One block per finding (the nine fields below) | Your developer | Each block has proof and a retest field |
| Remediation and retest results | What was fixed, when it was retested, what remains and who accepted it | You, customers, auditors | This section exists before the report is called final |
| Appendices | Tools and versions, the full list of tested endpoints, anything too long for the body | Your developer, the next tester | The endpoint list covers everything in scope |
The structure comes from two public sources. The Penetration Testing Execution Standard’s reporting section splits a report into an executive summary for the people who oversee the security program and a technical report that covers “the scope, information, attack path, impact and remediation suggestions of the test”, and it says that if objectives changed during testing, “all changes must be listed” in the summary, with the letter of amendment in the appendix. NIST SP 800-115 says in section 8.2 that “Internal reports should include test methodology, test results, analysis, and POA&M” (a plan of action and milestones), and in section 8.3 that “retesting the system will validate that the mitigation actions have been completed.” I give retest results a section of their own because a fix nobody retested is still an open finding.
The finding block: nine fields every finding carries
A pen test finding carries 9 fields: an id, a title, a severity with its scoring vector, the weakness class, the affected asset, a plain description, redacted proof, the business impact, and the fix with its retest status and date. A finding without proof or a retest field is not finished.
For the severity field, FIRST’s CVSS v4.0 specification maps scores to five ratings: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0), and it calls those ratings optional. What it does ask of anyone publishing CVSS data is “both the score and the vector string so others can understand how the score was derived.” A severity with no vector is an opinion you cannot check.
| Field | What goes in it | The mistake to reject |
|---|---|---|
| Id | A reference that stays the same from report to retest | New ids in the retest report, so nothing lines up |
| Title | The weakness, in words: what can happen to whom | The scanner’s rule name pasted as the title |
| Severity | The rating, the CVSS version and the full vector string | A rating with no vector |
| Weakness class | A CWE id or an OWASP category, named | No class, so nobody looks for the same flaw elsewhere |
| Affected asset | Hostname, route and the role used | ”The application”, with no route |
| Description | What is wrong, in plain words a developer and a founder can both follow | Scanner output pasted as a finding |
| Proof | What evidence is attached, with customer data redacted and secrets masked | Proof that contains real customer records |
| Business impact | What a real attacker gets, stated for this business | Generic impact text copied between findings |
| Fix, retest status and date | A change specific enough to act on, then the retest result and its date | A fix that says to sanitize input and nothing else; no retest column |
The third column is my working rule for sending a delivered report back to the tester, not an industry standard.
How to fill it in: the executive summary and the results
Two parts of the report do most of the work after delivery: the page a customer sees, and the findings your developer works from.
The penetration test executive summary: one page a customer can be shown
A penetration test executive summary is a single page a customer can be shown. It says what was tested and when, by whom and how, the findings counted by severity, the few that matter in business words, what is already fixed and retested, and what remains, with an owner and a date.
The six lines, in the order a reader wants them:
- What was tested, and on which dates.
- Who tested it, and by what method and standard.
- The count of findings at each severity.
- The two or three findings that matter, in business words.
- What has been fixed and retested as of the report date.
- What remains open, each with an owner and a target date.
A penetration testing executive summary gets forwarded to a customer’s security team, an investor’s advisor or an auditor, so hostnames, reproduction detail and anything else that would help an attacker stay out of it. Write it last, from the findings table, so every count matches the detail. PTES pitches this part at the people in charge of “the oversight and strategic vision of the security program”, which is the right reader to picture.
The common mistake is a summary that rates the overall posture as moderate and commits to nothing: no count, no open item, no date. When a customer’s security questionnaire asks for your latest test, this page is what you attach.
Pen testing results: how to read them and what to fix first
Pen testing results are worked in 5 steps, by my working rule: confirm each finding from its proof, order by severity and exposure, fix the whole class and not the one instance, get the retest in writing, and record accepted risks with a name and a review date.
- 01 Confirm each finding yourself from its proof before arguing about severity. If your developer cannot see the problem from the evidence, ask the tester for more before anyone debates the rating.
- 02 Order by severity, then by exposure (anything reachable without a login first), then by effort.
- 03 Fix the class, not the instance. One broken ownership check usually means the same check is missing on sibling routes, so search for them before calling the finding closed.
- 04 Book the retest inside the window the agreement gives, and get the result in writing for each finding.
- 05 Record every accepted risk with a named owner and a review date.
That order is my working rule. Pen test results also need a sense of proportion. Mine comes from code audits, which are not penetration tests: across the 21 third-party apps whose code I audited, only 58 of the 958 confirmed findings were critical, about 6 percent. I audited those 21 apps in June and July 2026, and they are a selected set, not a random sample, so the share says nothing about AI-built apps in general.
A finding from the same code audits shows why a retest carries a date. In a Q&A app I audited, a later migration dropped the “authenticated users can create questions” policy and replaced it with an INSERT policy that checks nothing. Anyone with no account could post a question under any real user’s id (readable from the open profiles table), and it showed on the public feed under that person’s name and badge.
The lesson I take from it: a control that was right in one migration can be undone by the next, so a retest result is true on its date and gets repeated after any change that touches the same control. A test that finds nothing covers the scope, the dates and the hours the agreement allowed, and says nothing past them.
A filled example: one finding and one summary for a small SaaS
This is an illustration with invented details, not a real engagement or a report I wrote: a five-person invoicing SaaS commissions a three-day gray-box test of its web app and API. The penetration test report example below fills in one finding and the summary page for that test.
Why this finding: 7 of the 21 third-party apps I audited had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. Those 21 apps were chosen for review between June and July 2026, not drawn at random, so the count tells you what to test first, not how common the flaw is. CWE lists two common names, IDOR and BOLA, as alternate terms for CWE-639, and notes that each can also cover other weaknesses.
| Field | Filled in (illustration) |
|---|---|
| Id | INV-AUTHZ-A |
| Title | Any logged-in customer can read another customer’s invoices |
| Severity | High. Illustrative vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, which scores 7.1 in FIRST’s calculator |
| Weakness class | CWE-639, Authorization Bypass Through User-Controlled Key; OWASP API1:2023 Broken Object Level Authorization |
| Affected asset | The invoice endpoint of the production API that takes an invoice id, called with the customer role |
| Description | A logged-in user could read another customer’s invoice by requesting an invoice id they do not own. The server checked that the caller was logged in, not that the invoice belonged to the caller’s account. |
| Proof | Two test accounts created for this test, in two separate customer workspaces; a redacted response in which account B’s request returned an invoice from account A’s workspace. No real customer data was touched. |
| Business impact | Any customer could read other customers’ names, amounts and billing details, the data customers pay this company to keep apart |
| Fix, retest status and date | Enforce ownership on the server for every route that takes an id, by checking that the logged-in user may act on that record, and add an automated test that requests another account’s id and expects a refusal. Retest: passed, with the retest date printed beside it. |
Three values in the vector carry the story: AV:N (reachable over the network, up to the whole internet), PR:L (the attacker needs only an ordinary low-privilege account) and VC:H (some restricted information is obtained, and it presents a direct, serious impact). The vector and its score are part of the illustration. The fix follows OWASP’s own advice for this class: check that the logged-in user may perform the requested action on the record in every function that takes a record id from the client, and “Write tests to evaluate the vulnerability of the authorization mechanism.”
The summary page for the same test, filled in with the same invented details:
| Line | Filled in (illustration) |
|---|---|
| What was tested and when | The web app and its API, over three working days |
| Who tested and how | An outside tester, gray box, with two customer test accounts, following the standard named in the methodology section |
| Findings by severity | One high, two medium, three low |
| What matters | Customers could read each other’s invoices; now fixed |
| Fixed and retested | The high finding and one medium, both retested and passed |
| What remains | One medium and three low, each with an owner and a target date |
If you want examples of penetration test reports written for real clients, the public-pentesting-reports repository on GitHub lists reports published by consulting firms and academic security groups. Vendors publish their own too: TCM Security and PurpleSec each offer a penetration testing report sample, and PurpleSec’s is dated January 2020. A pt report sample from a vendor shows the layout that vendor sells, so read it for structure. Hold any pentesting report example you find against the nine fields above, and check first for the proof and the retest columns.
The paperwork before the test: the pen test agreement and the rest
Section 3 of the report is copied from paperwork signed before anyone starts testing, so that paperwork decides what the report can say.
Pen test agreement, contract, SOW and rules of engagement: which document does what
Pen test paperwork is 4 documents, often folded into one: the agreement sets legal and commercial terms, the statement of work sets this test’s targets and price, the rules of engagement set how testing is conducted, and the authorization letter is the system owner’s signed permission.
| Document | What it settles | Who signs |
|---|---|---|
| Agreement or contract | Liability, confidentiality, payment, governing law | Both companies |
| Statement of work | This test: targets, dates, price, deliverables | Both companies |
| Rules of engagement | How testing is conducted: hours, contacts, allowed and forbidden techniques, data handling, when to stop | The test team leader and your senior management |
| Authorization letter | The system owner’s written permission, which the tester carries | Whoever owns or controls each target |
The map is my framing. The rules-of-engagement signatures follow NIST SP 800-115’s template, which says “the test team leader and the organization’s senior management (CSO, CISO, CIO, etc.) should sign the ROE” and adds that “A template may be provided as an appendix to the ROE to demonstrate report format and content.” That second line is the cue to attach the eight-section format above. The full one-page rules of engagement belong to the web application penetration testing guide linked earlier. A small firm may fold all four into a single penetration testing agreement (or contract), and that is fine if all four jobs are done.
Authorization is the clause that matters most, because it is what separates a test from unauthorized access under computer misuse law. In the United States, the Computer Fraud and Abuse Act, codified at 18 U.S.C. 1030, covers anyone who “intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains” information, including information from any protected computer. In the United Kingdom, section 1 of the Computer Misuse Act 1990 makes it an offense to cause a computer to perform a function with intent to secure access to a program or data when that access “is unauthorised” and the person knows it. My reading of what follows for a buyer: you can authorize testing only of what you own or control. Your hosting provider’s own testing rules apply on top, which the pen test article on this site covers for AWS. Third-party services such as the payment processor or the auth provider are out unless they agree in writing.
The twelve clauses to read in any penetration testing contract, each with what it protects the buyer from (my framing):
- Parties and authority to sign: the person signing can actually authorize testing of every target.
- Targets and exclusions: nothing is tested that you did not list, and the excluded systems are named.
- Dates and hours: no testing at your busiest hour without warning.
- Permitted and prohibited techniques: no denial of service and no social engineering unless the contract names them.
- Data handling: what proof may leave your systems, and how test data is stored, sent and destroyed.
- Confidentiality of the report: the findings are not shared outside the parties.
- Report ownership and recipients: you own the report and decide who receives it.
- Retest included, and its window: fixes get checked without a second negotiation.
- Deliverables and report format: the eight sections above, attached to the contract.
- Liability and insurance: what happens if testing breaks something.
- Incident handling: what the tester does if they find signs of a real breach, including when testing stops.
- Evidence retention and deletion: how long the tester keeps your data, and proof it is deleted.
A penetration test contract template from an online generator covers the legal boilerplate. The rules of engagement, the report format and the retest are specific to your app, so you and the tester add them. One naming trap: a search for penetration tester contract work returns job listings for testers, which is a different reader and a different page. This section is a reading guide, not legal advice; have a lawyer read the liability and governing-law clauses.
Penetration testing requirements and policy: where a requirement comes from, and what your own policy says
A penetration testing requirement comes from a standard that names it for those in its scope, an auditor’s control, or a customer’s contract, so the exact wording decides what counts. Your own penetration testing policy then states the trigger, the scope, who authorizes, who tests, how the report is kept, and the retest rule.
| Who asks | What their wording requires | Where it is covered |
|---|---|---|
| Card payments under PCI DSS | Required for organizations in its scope; the standard sets the details | PCI DSS penetration testing |
| A SOC 2 auditor, or a customer’s contract | Sometimes: it depends on the control the auditor tests and the contract clause behind the request | what is the pen test a customer or auditor is asking for |
| A customer’s security questionnaire | Whatever the question asks for; answer it from your executive summary | The executive summary section above |
| US federal systems under NIST SP 800-53 | Control CA-8, penetration testing, which SP 800-53B selects in the HIGH baseline only | NIST SP 800-53 Rev. 5 and SP 800-53B, below |
For the federal row, NIST SP 800-53 Rev. 5 states control CA-8 as “Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined systems or system components]”, and NIST SP 800-53B marks CA-8 in the HIGH baseline only, not in LOW or MODERATE. Pen test requirements are decided by the wording of the request: a line asking for a scan is met by a scan, and the difference is covered in pen test vs vulnerability assessment.
A six-line internal penetration testing policy, my working rule for a small team:
- What triggers a test: a date each year, and any significant change to the app.
- What is in scope by default: the production app, its API and its admin tools.
- Who authorizes: the named owner of the systems, in writing.
- Who may test: someone independent of the people who built it.
- How the report is stored and who may see it.
- The retest rule: every high finding retested before it is marked fixed.
The independence line echoes NIST’s wording for CA-8(1), which asks for testers “free from perceived or actual conflicts of interest with respect to the development, operation, or management of the systems” under test. A policy is a promise an auditor will check, so write the frequency you will actually meet.
How to verify the result
Pen test paperwork is verified with 6 checks: a signed authorization covering every target, a retest written into the price, the report format attached to the agreement, one high finding reproduced by your own developer, a retest status on every finding, and an executive summary that can be forwarded untouched.
- 01 Before signing: the authorization is signed by someone who owns or controls every target, and the hosting provider's testing policy has been read for each hosted target. Evidence: the signed page and the date of the policy you read.
- 02 Before signing: the retest and its window are written into the price. Evidence: the clause.
- 03 Before signing: the agreed report format is attached, with the nine finding fields. Evidence: the attachment.
- 04 After the report: your own developer reproduces one high finding from its proof alone, on a test account in staging or the agreed target. If they cannot, the proof field failed. Evidence: their note.
- 05 After the report: every finding shows a retest status and date, or an accepted-risk owner. Evidence: the findings table.
- 06 After the report: the executive summary can be forwarded as is, with no hostnames, no reproduction detail and no customer data. Evidence: the page.
Keep the signed authorization, the final report and the retest letter together, with access restricted to the people who need them. The checklist for what a report must contain on arrival is in the web application penetration testing guide.
In the Production Hardening Sprint, deliverable 3.10, targeted external penetration testing, is verified this way: “Record the five surfaces, authorized tests, findings, fixes, and retest outcomes. AxonBuild performs this targeted test.”
Where the sprint does this
In the sprint, we test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence (deliverable 3.10). The targeted security tests cover the five priority attack surfaces documented in the report, and the package also includes an OWASP review and a controls checklist with evidence. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables, and legal advice and certification are separate services. Every deliverable is listed in the published scope.
Common questions about pen test paperwork
What are some rules of engagement to agree for the penetration test?
Agree the testing hours, a contact on each side and a way to stop testing at once, the techniques that are off limits, what proof may leave your systems, and what the tester does if they find signs of a real breach mid-test. NIST SP 800-53 is plain about the timing: “All parties agree to the rules of engagement before commencing penetration testing scenarios.”
The full one-page version, with the scope document beside it, is in the web application penetration testing guide.
Is penetration testing a legal requirement?
It depends on the rule or contract you are under. PCI DSS requires it for organizations in its scope, NIST SP 800-53B selects control CA-8 only in the HIGH baseline for US federal systems, and a customer contract can require one. Separately, testing without the owner’s authorization can itself break computer misuse law, such as 18 U.S.C. 1030 in the United States and section 1 of the Computer Misuse Act 1990 in the United Kingdom; which rules apply to you is a question for your lawyer.
Who is responsible for pen testing?
The system owner. The company that owns the app commissions the test and signs the authorization, a tester performs it, and the owner fixes the findings and books the retest. On a small team that owner is the founder or the fractional CTO.
What is the last stage of a pen test?
The retest, and the updated report that records it. NIST SP 800-115 describes retesting as the step that validates the mitigation actions have been completed, so a finding is closed only when the report shows the retest result and its date.
The phases before that are set out in the web application penetration testing guide.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase