Sample pentest report: what you receive when the test ends

The report has two parts that are read separately. The executive report says in business terms what we tested, what stayed out of scope and what exposure we found. The technical report documents each finding so IT can reproduce it and fix it without calling anyone.

It is signed by the person who agreed the scope and led the test. Every finding is confirmed by hand before it goes into the report. A tool alert that nobody could confirm is not reported as a finding. From signed contract to report takes 2 to 4 weeks.

Prices start at USD 5,000 per defined scope: an external network of up to 16 active public IP addresses, or one web application or API with up to 2 roles and 20 endpoints. The retest is part of that price.

In the sample, the client is Example Credit Union, a made-up company. The scope is its external network and its online banking. These are the parts of the document:

• Cover page: company, authorized scope, test dates, document version and who signs.
• Executive report: the exposure in two or three paragraphs, the findings table by severity and what to fix first.
• Scope and method: which systems were in scope, where we tested from, what stayed out and why.
• Technical report: one page per finding, with evidence, steps, impact and fix.
• Retest: the status of every finding after we test the fixes.

This is how the sample summary reads. Everything below is made up.

"From March 3 to March 14 we tested the external network of Example Credit Union, with 12 public IP addresses, and its online banking, with two user roles. We tested with written authorization and inside the agreed windows. Operations were not affected."

"The most serious finding lets an online banking user send a transfer to a third-party account without the second factor the credit union requires for that kind of transaction. An attacker who gets a member's password could move money without the second factor. We recommend fixing it before anything else."

"On the external network we found a remote access service running a version with a publicly known vulnerability. We did not exploit it beyond confirming the version, because the scope excluded changes in production. The other findings are medium, low or informational."

The table is the first thing the board reads and the part that gets copied into the remediation plan. Every finding keeps the same ID in the report, the plan and the retest. The ID says where the finding is: EXT for the external network and WEB for the application.

Every finding gets a page with the same fields. This is WEB-01 from the sample.

What we found: when the user sends a transfer, the application asks for the second-factor code. If the request is sent again with one parameter changed, the server accepts the transfer without checking the code.

Evidence: the full requests and responses, with the time of each, and screenshots from the test user's screen. Member data and credentials are blacked out. We used only the test accounts the credit union gave us.

Steps to reproduce: the exact numbered sequence, so IT can see the problem for itself in the test environment.

Impact: who can use the flaw, what they need first and what they can do. Here, anyone with a member's password can move money to another account without the second factor.

Suggested fix: check the second factor on the server for every third-party transfer, without trusting what the browser sends, and log failed attempts.

Rule reference, where one applies: for a bank in El Salvador, NRP-32 Articles 22 and 23 require the additional factor for electronic transfers to third parties. For other clients the page cites whatever rule or standard applies to them.

When IT has fixed the findings, we test the fixes again. The retest is included in the price and runs within 90 days of the report. Each finding ends up in one of two states: fixed or open. Accepting a risk is the client's decision, not the tester's.

The sample retest looks like this:

The report is evidence. The client decides how to present it. Toukan is not an auditor, a QSA or a regulator, and it does not issue compliance opinions.

• PCI DSS: the PCI Security Standards Council's penetration testing guidance asks for a qualified tester who is organizationally independent of what is tested. It does not require any specific certification.
• SOC 2: the criteria do not prescribe a penetration test, but auditors and enterprise customers often ask for a recent report and proof that findings were fixed.
• El Salvador: NRP-23 Article 20 i) asks the institution to send a results summary within ten business days of receiving the provider's report, and a remediation plan thirty business days later.
• Guatemala: JM-98-2025 Article 18 asks for internal and external penetration tests, with the result recorded in a technical report.
• Honduras: CNBS Circular 025/2022 Article 24 asks for intrusion tests run by third parties.