1. The full technical report
This is the primary deliverable. It is the document your engineering team will work from during remediation. Every vulnerability discovered during testing should be documented as an individual finding entry with: a descriptive title, CVSS severity score with vector string, detailed proof-of-concept including HTTP requests, responses, and annotated screenshots, reproduction steps a developer can follow independently, and specific remediation guidance tied to your technology stack.
The technical report also includes a methodology section stating the testing approach (black-box, grey-box, white-box), frameworks followed (OWASP, PTES), tools used alongside manual testing, and the exact testing timeline. This methodology documentation is not optional. CBN auditors and PCI DSS assessors will ask for it.
Red flag: findings without proof-of-concept
If the technical report contains findings that lack request/response evidence and reproduction steps, those findings were likely generated by an automated scanner and included without manual verification. A report full of unverified scanner output is not worth the remediation time your engineers will spend chasing false positives. For more on the difference, see our piece on manual testing vs automated scanners.
2. The executive summary
The executive summary exists for people who need to understand your security posture without reading technical details: board members, compliance officers, investors conducting due diligence, and enterprise clients evaluating your platform as a vendor. It should be one to two pages, self-contained, and written in business language.
A quality executive summary covers: the scope of the engagement, the overall risk assessment, a severity breakdown (how many critical, high, medium, low findings), a plain-language explanation of the most impactful vulnerabilities, and a summary of remediation priorities. It should not be the technical report with the code removed. It should be written for the specific audience that will read it.
Does the executive summary stand alone?
Hand the executive summary to someone non-technical on your team. If they cannot understand the security posture of your product after reading it, the summary was not written for its intended audience. A good vendor writes the executive summary separately, not as an auto-generated abstract of the technical report.
3. The remediation roadmap
The remediation roadmap takes the findings from the technical report and organises them into a prioritised action plan. It answers the question every engineering lead asks after receiving a pentest report: "What do we fix first?"
A well-structured roadmap groups findings by priority tier, not just severity score. A critical-severity finding on an internal admin panel used by three people may be less urgent than a high-severity finding on your public-facing payment API handling thousands of transactions daily. The roadmap considers business context, exposure surface, and exploitability to establish a remediation sequence that makes operational sense.
It should include suggested timelines: critical findings addressed within 48 to 72 hours, high-severity within one to two weeks, medium within one sprint cycle, and low-severity findings tracked as technical debt. This structure gives your team a sprint-ready list rather than a flat dump of vulnerabilities sorted by CVSS score.
Red flag: no prioritisation beyond severity labels
If your vendor hands you a list of findings sorted by Critical → Low with no further prioritisation guidance, they have not considered your business context. A payment gateway and a lending platform with identical findings need different remediation sequences because their risk profiles are different.
4. The retest certificate
After your team remediates findings, the testing firm should retest. Not rerun a scanner. Manually re-execute the specific attack scenarios that originally produced findings and verify that the fixes hold. The retest certificate is the formal document confirming which findings were retested, the date of retesting, and the pass/fail status of each.
This document serves two purposes. Internally, it gives your engineering team confirmation that their fixes were validated by an independent party. Externally, it provides auditors and clients with evidence that remediation was not just claimed but verified. A finding status of "Remediated" without retest verification is an assertion, not evidence. For more on the retest process, see our article on what happens after a pentest.
Need a pentest that includes all five deliverables?
Scope Your Engagement5. The letter of attestation
The attestation letter is the document you share externally. Unlike the technical report, which contains sensitive vulnerability details, the attestation letter confirms the engagement happened without disclosing what was found. It typically states: the name of the testing firm, the scope of the engagement, the testing period, the methodology used, and a confirmation that the engagement was completed and remediation was verified.
This is the document your compliance team hands to CBN auditors during regulatory examinations. It is what you send to enterprise clients who require evidence of third-party security testing as part of vendor onboarding. It is what investors review during technical due diligence before a funding round. For pre-fundraise security considerations, see our guide on security before fundraising.
Red flag: a vendor who cannot produce an attestation letter
If your vendor says "just share the report," that is a problem. The technical report contains detailed vulnerability information and should never be shared broadly. A professional testing firm produces a separate attestation letter as a standard deliverable. If they do not offer one, ask why. If the answer is that they have never been asked, reconsider whether they have experience working with regulated fintechs.
What happens when deliverables are missing
When a vendor delivers only a technical report with no executive summary, no remediation roadmap, no retest certificate, and no attestation letter, you end up doing their work for them. Your compliance team creates the executive summary from scratch. Your engineering lead builds the remediation roadmap manually. Your legal team drafts some version of an attestation letter and hopes it passes scrutiny. And nobody retests anything because the engagement contract did not include it.
That is not a cost saving. That is a cost transfer. You paid for a penetration test and received a fraction of the deliverables. Before signing any engagement, confirm in writing that all five documents are included. At Simpa Labs, they are standard on every engagement.
Related reading
Blog: What to look for in a pentest report · How a Simpa Labs pentest works · What to expect from an engagement
Guides: Pentest report explained · How to book a pentest · Pentest pricing guide
Services: Penetration testing · Vulnerability assessment · Architecture review