![\"The](\"https:\/\/krylosecurity.com\/blog\/wp-content\/uploads\/2026\/10\/penetration-test-report-example-sections-1.jpg\")
<\/figure>\n\n\n\n1. Executive summary<\/h3>\n\n\n\n
One or two pages, in plain language. It should answer four questions:<\/p>\n\n\n\n
- \n
- What was tested, and when?<\/li>\n\n\n\n
- How exposed are we overall?<\/li>\n\n\n\n
- What are the few issues that matter most, and what could an attacker do with them?<\/li>\n\n\n\n
- What should we do first?<\/li>\n<\/ul>\n\n\n\n
A sentence like “an attacker with a free customer account could download other customers’ invoices” is worth more than a chart of severity counts. The best summaries name business impact, not vulnerability classes.<\/p>\n\n\n\n
2. Scope and approach<\/h3>\n\n\n\n
This is the section auditors read first. It should state:<\/p>\n\n\n\n
- \n
- the exact targets: domains, IP ranges, applications, API endpoints, app builds,<\/li>\n\n\n\n
- what was out of scope,<\/li>\n\n\n\n
- the testing dates and environment (staging or production),<\/li>\n\n\n\n
- the approach: black box, grey box or white box, and which accounts were provided,<\/li>\n\n\n\n
- the standards followed, such as OWASP WSTG, the OWASP API Top 10, PTES or NIST SP 800-115,<\/li>\n\n\n\n
- any limitations, such as a feature that was down during testing.<\/li>\n<\/ul>\n\n\n\n
If the scope is vague, the report is weak evidence, however good the findings are.<\/p>\n\n\n\n
3. Findings summary<\/h3>\n\n\n\n
A table of every finding with its ID, title, severity and status. Severities are usually based on CVSS, sometimes adjusted for your environment. Read our guide to CVSS scores<\/a> if the numbers look arbitrary.<\/p>\n\n\n\n
4. Detailed findings<\/h3>\n\n\n\n
The core of the report. Each finding should be self-contained, so it can be pasted into a ticket and fixed by someone who never read the rest. A complete finding has:<\/p>\n\n\n\n
- \n
- title<\/strong> that says what is wrong in plain words,<\/li>\n\n\n\n
- severity<\/strong> with the scoring behind it,<\/li>\n\n\n\n
- affected asset<\/strong>: the exact URL, endpoint, host or app screen,<\/li>\n\n\n\n
- description<\/strong> of the weakness,<\/li>\n\n\n\n
- impact<\/strong>: what an attacker could actually do, in business terms,<\/li>\n\n\n\n
- steps to reproduce<\/strong>, so your team can confirm it and later confirm the fix,<\/li>\n\n\n\n
- evidence<\/strong>: requests and responses or screenshots, with sensitive data redacted,<\/li>\n\n\n\n
- remediation<\/strong>: a fix written for your stack, not a generic link,<\/li>\n\n\n\n
- references<\/strong>, such as the OWASP category or CWE.<\/li>\n<\/ul>\n\n\n\n
5. Positive observations<\/h3>\n\n\n\n
What held up. If the tester could not break your MFA or your file upload handling, say so. It tells you which controls are earning their keep.<\/p>\n\n\n\n
6. Appendices<\/h3>\n\n\n\n
Tools used, the list of hosts or endpoints tested, and any raw data that supports the findings without cluttering them.<\/p>\n\n\n\n
A sample finding<\/h2>\n\n\n\n
Here is what one finding looks like when it is written well. The details are illustrative and redacted.<\/p>\n\n\n\n
\n
KS-04: Customers can download other customers’ statements<\/strong><\/p>\n\n\n\n
Severity:<\/strong> High (CVSS 4.0: 8.7)<\/p>\n\n\n\n
Affected asset:<\/strong>
GET \/api\/v2\/statements\/{statementId}\/download<\/code><\/p>\n\n\n\nDescription:<\/strong> The endpoint returns a statement for any ID it receives. It checks that the caller is signed in, but not that the statement belongs to them.<\/p>\n\n\n\n
Impact:<\/strong> Any customer can download any other customer’s monthly statements, which include names, addresses, account numbers and transactions. Statement IDs are sequential, so all of them can be collected with a simple script.<\/p>\n\n\n\n
Steps to reproduce:<\/strong> Sign in as test user A and download one of A’s statements, noting its ID. Sign in as test user B and request A’s statement ID. The statement is returned with HTTP 200.<\/p>\n\n\n\n
Remediation:<\/strong> On the server, look up the statement together with the signed-in customer’s ID and return 404 if they do not match. Apply the same check to every endpoint that takes an object ID. Consider non-sequential identifiers as a second layer, not a replacement.<\/p>\n\n\n\n
Reference:<\/strong> OWASP API Security Top 10, API1:2023 Broken Object Level Authorization<\/p>\n<\/blockquote>\n\n\n\n
Notice what it avoids: no scanner jargon, no “may allow”, no copy-pasted paragraph about IDOR in general. A developer can fix it in an afternoon, and a manager can understand why it matters. For more on this class of bug, see our guide to broken access control examples<\/a>.<\/p>\n\n\n\n
Checklist: is this a good report?<\/h2>\n\n\n\n
Use this when you receive a report, or ask a provider for a sample before you buy one:<\/p>\n\n\n\n
- \n
- The executive summary names business impact, with counts as support.<\/li>\n\n\n\n
- The scope lists exact targets, dates and approach.<\/li>\n\n\n\n
- Every finding has steps to reproduce and evidence.<\/li>\n\n\n\n
- Remediation is specific to your technology.<\/li>\n\n\n\n
- Each severity comes with the reasoning behind it.<\/li>\n\n\n\n
- There is no unverified scanner output padding the findings.<\/li>\n\n\n\n
- Sensitive data in the evidence is redacted.<\/li>\n\n\n\n
- Critical issues were reported to you during testing, not first in the report.<\/li>\n\n\n\n
- A retest report is available once you have fixed the issues.<\/li>\n<\/ul>\n\n\n\n
What auditors and customers look for<\/h2>\n\n\n\n
If the report is going to a SOC 2 auditor, a PCI assessor or a customer’s security team, they will check three things before reading a single finding:<\/p>\n\n\n\n
- \n
- Independence.<\/strong> The testers did not build or run the systems they tested.<\/li>\n\n\n\n
- Scope match.<\/strong> The scope covers the systems in their audit boundary or contract.<\/li>\n\n\n\n
- Remediation evidence.<\/strong> High and critical findings were fixed and retested, or have a documented plan.<\/li>\n<\/ol>\n\n\n\n
Our page on penetration testing for compliance<\/a> covers what each framework expects.<\/p>\n\n\n\n
Frequently asked questions<\/h2>\n\n\n\n
Can I get a penetration test report template?<\/h3>\n\n\n\n
The structure above is the template: executive summary, scope and approach, findings summary, detailed findings, positive observations and appendices. What makes a report good is the quality of each finding, which a template cannot give you.<\/p>\n\n\n\n
Should we share the full report with customers?<\/h3>\n\n\n\n
Usually not. Share an attestation letter or the executive summary and scope, under NDA. The detailed findings are a guide to your weaknesses, so keep them inside the team that fixes them.<\/p>\n\n\n\n
How long after testing should the report arrive?<\/h3>\n\n\n\n
Most providers deliver within one to two weeks of testing ending. Critical issues should reach you during testing, not in the report.<\/p>\n\n\n\n
What is a VAPT report?<\/h3>\n\n\n\n
The same thing under a different name. VAPT stands for vulnerability assessment and penetration testing, and the report covers both the scanning and the manual testing. See vulnerability assessment vs penetration testing<\/a>.<\/p>\n\n\n\n
See our reports for yourself<\/h2>\n\n\n\n
Every Krylo Security report follows this structure, and every finding in it has been reproduced by a tester. Ask us what your report will include<\/a> when you book your scoping call, or read how we run the whole process<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
A walk through a penetration test report, section by section, with a redacted sample finding. Use it to judge a report you have received, or to know what to ask for before you buy.<\/p>\n","protected":false},"author":1,"featured_media":6023,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[94,92,6,93],"class_list":["post-7062","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-penetration-testing","tag-executive-summary","tag-penetration-test-report","tag-penetration-testing","tag-vapt-report"],"_links":{"self":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7062","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/comments?post=7062"}],"version-history":[{"count":1,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7062\/revisions"}],"predecessor-version":[{"id":7101,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/posts\/7062\/revisions\/7101"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/media\/6023"}],"wp:attachment":[{"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/media?parent=7062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/categories?post=7062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/krylosecurity.com\/blog\/wp-json\/wp\/v2\/tags?post=7062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Scope match.<\/strong> The scope covers the systems in their audit boundary or contract.<\/li>\n\n\n\n
- Independence.<\/strong> The testers did not build or run the systems they tested.<\/li>\n\n\n\n
- severity<\/strong> with the scoring behind it,<\/li>\n\n\n\n
- title<\/strong> that says what is wrong in plain words,<\/li>\n\n\n\n