Penetration testing report: samples and a buyer's checklist

By The PenTest Index · Sources checked October 9, 2026

A penetration testing report is the written record of a penetration test: what was tested, how, what the testers found, the proof, and how to fix each issue. No single standard sets the format, so quality varies a lot. Before you accept or share one, check that scope, dates, methods, evidence and retest status are all stated.

Here is the short version. The people fixing the issues need the full report. An auditor may ask for it too. Many customers only need an attestation letter or an executive summary, and you can ask which. If something you need is not in the report, find out whether it is missing from the document or missing from the test. The first takes an email. The second takes more testing.

What should a penetration testing report include?

A penetration testing report should say who tested and when, exactly what was in and out of scope, which roles were used, what limits applied, what was done by hand and by tool, and for each finding the proof, the severity reasoning, the fix and the retest status. The 12 checks below turn that into questions you can send.

We built this list from two published sources: the PCI Security Standards Council's Penetration Testing Guidance (version 1.1, September 2017, section 5) and OWASP's reporting structure. Both call their outlines suggestions. They are not rules, and neither is this.

Two rules make the list useful. First, a named exclusion and a blank are different things. If the report says "the API was out of scope" and you needed the API tested, that is a real gap. If the report never mentions the API, ask before you conclude anything. Second, nothing here averages out. A well-designed report with a missing API is still missing the API.

Think of a home inspection. You would expect the address, the date, the rooms the inspector could not get into, a photo of each problem and what to do about it. A page that says "the house has issues" is not an inspection report.

If your report is for a card-payment assessment, the PCI guidance lists a few more things to look for: segmentation test results, the tools used, clean-up steps after testing, and evidence that the tester is independent of the team that runs the environment. Your assessor decides what they need.

Report Check

Check 1

Who and when

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 2

Scope and exclusions

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 3

Roles and access

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 4

Limits

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 5

Methods

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 6

Testing story

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 7

Executive summary

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 8

Findings list

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 9

Proof for each finding

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 10

Severity reasoning

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 11

A fix for each finding

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

Check 12

Retest status

StatusNot checked yetYes, it's thereNo, it's missingCan't tellDoesn't apply to us

This report is for a PCI assessment

Copy questionsPrintClear

Missing from the report

Ask before you decide

Not checked yet

1. Who and when
2. Scope and exclusions
3. Roles and access
4. Limits
5. Methods
6. Testing story
7. Executive summary
8. Findings list
9. Proof for each finding
10. Severity reasoning
11. A fix for each finding
12. Retest status

Don't paste findings, passwords or system details anywhere on this page. This check asks for none.

Writing a report instead of receiving one? OWASP's reporting guide and the public reports library on GitHub are better starting points than this page.

Where can you see a sample penetration test report?

Several firms publish reports you can open without giving an email address. We read three of them on October 9, 2026 and ran them against the checks above. Open the one closest to what you need tested, then compare a second.

A sample shows you format and depth. It does not show the quality of testing you would get, and a template filled with example findings is not a real engagement. The three below come from different kinds of tests, so this is not a ranking. They are listed A to Z.

Notice that all three have dates that do not line up neatly: a cover date before the test dates, or a title month before the test month. That is harmless in a sample. In your own report, make sure you know which date is the testing and which is the document.

Open the Cure53 report (PDF)

Open the TCM Security sample (PDF)

Open the TrustFoundry sample (PDF)

TrustFoundry's sample page also offers network and cloud samples with no form. For more real reports, the public reports library on GitHub collects published reports from dozens of firms.

How to read a sample in ten minutes

1. Find the scope page. Is it specific enough that you could tell what was left out?
2. Open one high-severity finding. Could your engineer follow the steps?
3. Look for how severity was decided.
4. Look for limits: time, access, things that were blocked.
5. Look for what happens after fixes. Is there a retest section or a status for each finding?

If a provider will not show you a sample without a sales call, that tells you something too.

Does your report cover what your customer asked for?

Often the report is fine and the gap is between what was tested and what the customer asked for. The way to find out is to put the customer's request next to the report, line by line. Here is a made-up example.

Fictional example. No assessment was performed. MapleHelp is a small software company. A customer's written request says: test the support portal and the integration API, test with both a support-agent account and an administrator account, and have the tester confirm that any High findings were fixed. Testing in the staging environment is fine. A plain-language summary would be nice.

MapleHelp already has a report. It is version 1.0, issued September 21, 2026, for testing on September 14 to 18. It covers the staging support portal. It says the integration API was excluded. It does not say whether an administrator account was tested. It shows one High finding marked "fixed" by MapleHelp's own developers, with no tester check recorded.

The decision: this report does not yet meet the request, but MapleHelp does not need a whole new test. It needs three things from its current provider: the API tested, a straight answer on roles, and a retest record. An addendum can document work that was already done. It cannot turn an excluded API into a tested one.

The message MapleHelp would send:

Our customer requires the support portal and the integration API, testing with support-agent and administrator accounts, and tester verification of fixed High findings. Our report excludes the API and does not make role coverage or verification clear. Please send any existing records that settle those points, and quote only for the work that has not been done.

Copy provider question

This is the same method we use across the site, the PenTest Index Purchase Check: state the requirement, find the evidence, record the finding, and write the question that would change it. "Supported" means that one point is backed by the evidence. It is not a verdict on the provider or a promise your customer will accept the report.

If your own gap turns out to be a system that was never tested, write the scope down before you ask anyone for a price, so your current provider and any other you contact are quoting for the same job. Find My PenTest Match is our free scope checklist. You pick what needs testing, and it gives you the questions to settle and a checklist to copy or print. It asks for no contact details, and it does not pick a provider for you.

Find My PenTest Match

If all you need is a retest record or a clearer scope statement, the message above is the whole job. You are done.

What does a useful finding look like, and what do you fix first?

A useful finding names the exact place, shows the proof, explains the damage in plain terms, gives a specific fix and says where things stand now. If your engineers cannot act on a finding without calling the tester, the finding is not finished.

Here is a short made-up finding from the MapleHelp example. It is a teaching example, not real evidence.

And the executive summary that would go with it:

Testing of MapleHelp's staging support portal found a permission flaw that let a support-agent account export a workspace's member list, an action meant for administrators. The development team reports a fix, but tester verification is not recorded. The integration API was not tested, and it is unclear whether an administrator account was tested. This report does not yet cover the customer's full request.

Notice what the summary does. It says what happened, what it means and what is still open, with no jargon. That is the page your leadership and your customers will read.

On what to fix first: a severity score is one input. It is not the whole answer. Many reports use CVSS, the Common Vulnerability Scoring System, a 0 to 10 scale. FIRST, the group that maintains CVSS, says in its user guide that the base score measures severity and should not be used alone to assess risk. A Medium on the system that holds your customer data can matter more than a High on a test server. The PCI guidance says the report "should clearly document how the severity/risk ranking is derived." If yours does not, ask.

Then give every finding an owner and a date. A report tells you what to fix. Whether the provider will help you fix it, walk your team through the findings, or only retest is a contract question. Settle it when you compare quotes.

Is it a pentest report or a scan export?

Check the methods and the proof, not the title on the cover. A penetration test report shows what a tester tried and proved. A scan export lists what a tool flagged. The PCI guidance is blunt about this: "Merely reporting lists of vulnerabilities is not helpful in this endeavor and does not meet the intent of the penetration test."

Signs you may be holding a scan export:

• No steps to reproduce any finding
• No account of manual testing
• No mention of logging in or of user roles
• A long list of low-detail items with nothing about what they mean for you

A concrete case: Pentest-Tools.com publishes a sample from its website scanner. It is clearly labeled as a scanner report, and its scan settings show "Authentication: False". So that document, on its own, cannot tell you anything about what a logged-in user could do. That is a fact about that one scan, not about the company's separate human-led testing service.

Be fair in the other direction too. An automated or AI-led test can produce real evidence, and most human-led tests use tools. The question is never the label. It is what was covered, with what access, and what was proved. For more on the difference, see penetration testing vs vulnerability scanning.

Who should get the full report, and who gets a summary or attestation letter?

Give the full report to the people fixing the issues. Give your auditor what they ask for, which may be the full report. For customers and prospects, offer an attestation letter or an executive summary first and ask if they need more. The full report is a map of your weak points, so share it on purpose.

Not every provider gives you all four, and the names differ. Three examples from provider documentation, checked October 9, 2026:

• Cobalt's documentation lists five report types for its Comprehensive and In-House pentests: Customer Letter, Attestation Report, Attestation Letter, Full Report, and Full Report plus Finding Details. For its Agile pentests it lists one, an Automated Report. So the type of test you buy decides which documents you can hand over.
• TCM Security says it supplies a letter of attestation, a one-page executive summary and a findings list in spreadsheet form alongside the report.
• TrustFoundry says many of its clients share their reports or a letter of attestation with their own customers.

When a customer asks for "your latest pentest report", you are allowed to ask what they need. Copy this:

Would an attestation letter and executive summary meet your need, or do you require the full report? If the full report, which sections, and can we share it under NDA?

Copy customer question

Do not edit the tester's report yourself to make a customer version. Ask the provider for one. And store the report like any sensitive document: NIST's testing guide, SP 800-115, says assessment results should be stored securely with access limited to the people who need them.

If you do not yet know who will read the report, start with our questions for your report recipient.

Will your auditor or customer accept the report?

Only they can tell you, and the published rules say less about report format than most people assume. Ask the person who will receive the report what they need before you book the test, not after.

What we can say from the texts we read:

• Card payments (PCI). The PCI Security Standards Council publishes detailed report guidance, including a suggested outline and a checklist for people who receive a report. The same document says these are "only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests," and that it does not replace the standard itself. It was last revised in September 2017, so it uses the requirement numbering of that time. For today's requirement text, use PCI SSC's document library and your assessor.
• SOC 2, ISO 27001 and customer security reviews. We are not going to quote you a clause, because what matters in practice is what your auditor or customer asks for in writing. Get that request first. It usually comes down to four things: which systems, how recent, which document, and whether fixes must be retested.

Be careful with promises. Intruder's pricing page says: "If your auditor rejects the report, we refund the test in full - no questions, no fine print." (Checked October 9, 2026.) That is a refund promise. It is not a guarantee that your auditor will accept the report, and no provider can give you one.

If the report you already have meets the written request, you do not need to buy anything.

What proves a finding was retested, and when does the retest window close?

A fix is proven when the report ties the original finding to a recheck: who checked, on what date, on which version, by what method, with what result. A status that changed from "open" to "fixed" is not proof by itself. And the window to ask for a retest can close sooner than you expect.

Statuses mean different things. Read them this way:

The method matters. In the Cure53 sample above, fixes were verified by reviewing the code change. That may be exactly right for a source-code audit. If your customer expects the attack to be tried again against the running system, say so before the retest.

The PCI guidance suggests five parts for a retest report: a summary, the date of the original test, the date of the retest, the original findings and the retest results. It gives no fixed number of days. It says fixes "should be completed and retested within a reasonable period of time."

Providers do set deadlines, though. These are their published terms, each from the provider's own pages:

Here is why the start of the window matters. Say Astra reports your findings on January 12, 2027. Thirty days from then is about February 11, 2027, and that is the date you must request the rescan by. If your engineers plan to ship fixes in March, you are outside the window before you start. Ask for an extension in writing before you buy, not after. (This is our own date math on the published 30-day rule. Ask Astra for the exact cutoff on your account.)

With Cobalt, the thing to check is your contract end date, because the retest period can end 10 days before it. With any provider that states no window, ask the question below and get the answer in writing.

What retesting is included, how many rounds, when must we request it, what date starts that clock, and will the updated report show the method and result for each finding?

For how to compare these terms across proposals, see our quote guide.

What should you ask a provider about the report before you book?

Agree the report in writing at the same time as the scope. A sample shows you the format. Only the written agreement tells you what your purchase includes. Copy this and send it with your scope:

Please confirm the report deliverables for the scope we agree:

1. The report will name the exact applications, APIs, environments, versions and user roles tested, and what was excluded.
2. It will state the testing dates, what was done by hand and by tool, and any limits on access or time.
3. Each finding will include evidence, steps to reproduce, how the severity was decided and a specific fix.
4. Which documents we receive: full report, executive summary, attestation letter, findings export. Any extra cost for each.
5. Whether a walkthrough call and a period for questions or corrections are included.
6. What retesting includes: how many rounds, the deadline to request it, what date starts that deadline, any charge for an extension, and whether results go into an updated report.
7. The date we will have the final report, separate from the test start date.
8. Who may receive the report, how it will be delivered securely, and how long you keep the test evidence.

Please tell us anything that is excluded or charged separately. This request does not authorize any testing.

Copy report request

That last line is there for a reason. A list of requirements is not permission to test. Testing needs written authorization that covers the real targets and activities.

If you have already chosen a provider, send this to them directly. You do not need anything else from us.

If you are still working out what needs testing, the report request fits into the "Report needs and deadline" part of our scope checklist. Build the rest there, so every provider you contact answers the same brief and you can compare their answers side by side.

Find My PenTest Match

Ready to look at specific offers? Compare published offers, with prices, retest terms and sources.

More questions about penetration test reports

Does "no findings" mean we passed?

No. It means the testers found nothing within the scope, time and access they had. Read the scope and limits pages before you treat a clean report as good news. A clean report on half your system is half an answer.

How long is a penetration test report valid?

There is no expiry date printed on a report, and we found no single rule that sets one. The person asking for it decides how recent it must be, so ask them. Also ask yourself what has changed since the test. A report on last year's version of your app says little about this year's.

How long should a penetration testing report be?

As long as the scope and findings need. Of the samples above, the Cure53 report is 12 pages for two findings and the TrustFoundry sample is 30 pages for ten. Length is not quality. A short report that states scope, proof and fixes beats a long one padded with tool output.

Is a VAPT report the same thing?

VAPT stands for vulnerability assessment and penetration testing. Some providers use it for a report that combines scan results with manual testing. Check which parts were done by a person, using check 5 above.

Can we fill in a report template ourselves?

You can use a template to write up real, authorized testing. Filling one in does not show that testing happened, and it will not satisfy a customer who asked for an independent tester.

Sources and how we checked

We read published reporting guidance and public sample reports, then applied them to the questions buyers ask. We did not commission any of these tests, test the systems in the samples, or check any provider's testing quality. The MapleHelp example and the 12-point check are our own work. How we research offers is on our methodology page, and how the site earns money is here.

Guidance, read October 9, 2026:

• OWASP, Web Security Testing Guide: Reporting Structure (latest edition; it can change)
• PCI Security Standards Council, Information Supplement: Penetration Testing Guidance, version 1.1, September 2017, section 5. Supplemental guidance, not the text of the current standard.
• FIRST, CVSS v4.0 User Guide
• NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008

Sample reports, inspected October 9, 2026 (each shows reporting style only, not current services or the security of any system):

• Cure53, ExpressVPN VPN browser extension report, 2024
• TCM Security, internal penetration test sample report, 2025
• TrustFoundry, EasyTransfer application penetration test sample, 2020, and its sample reports page
• Pentest-Tools.com, Website Vulnerability Scanner sample report

Provider-published documentation, checked October 9, 2026 unless noted (what each company says about its own service):

• Astra, rescan rules; plans and pricing, checked October 7, 2026
• Cobalt, contents of a pentest report and retesting rules
• Intruder, pentest pricing
• Pentest-Tools.com, managed web app penetration testing
• TCM Security, What is a penetration testing report?

Provider terms change. If you spot something out of date, tell us and we will recheck it.