The two audiences every report must serve
A penetration test report that only speaks to developers fails in the boardroom. A report that only speaks to executives fails in the sprint backlog. Every quality report serves both audiences distinctly, and the separation should be structural, not just tonal.
The executive summary
This section exists for CTOs, compliance officers, board members, and investors. It should be one to two pages maximum. It covers: the scope of what was tested, the overall risk posture expressed in business terms, the count and severity distribution of findings, and a plain-language summary of the most impactful vulnerabilities discovered. An investor reviewing your security posture before a Series A does not need to see HTTP request headers. They need to know whether customer funds or data are at risk and what your remediation timeline looks like.
If the executive summary reads like a technical writeup with the code snippets removed, it was written by someone who does not understand the audience. Ask for it to be rewritten.
The technical findings section
This is the core of the report. Each finding should be documented as an individual, self-contained entry. Here is what each finding needs:
Finding anatomy: what every entry must contain
1. Title and severity rating
The title should describe the vulnerability in specific terms, not generic labels. "Missing object-level authorisation on /api/v1/transfers" is useful. "Authorisation issue" is not. The severity rating should use CVSS v3.1 or v4.0 scoring. CVSS provides a standardised, reproducible score based on attack vector, complexity, impact, and privilege requirements. If your vendor is using proprietary severity labels like "Important" or "Noteworthy" without a CVSS vector string, ask why. For more on how BOLA vulnerabilities score on CVSS, see our technical breakdown.
2. Proof-of-concept evidence
This is the single biggest differentiator between manual testing and automated scanning. A real pentest report includes evidence that the vulnerability was actually exploited, not theoretically possible. That means: annotated screenshots showing the attack in progress, full HTTP request and response pairs, step-by-step reproduction instructions a developer can follow independently, and documentation of the business impact observed.
If a finding says "SQL injection possible on login form" but provides no request payload, no response showing data exfiltration, and no reproduction steps, it was flagged by a scanner and never manually verified. That finding might be a false positive. Your developers will waste time investigating it, and real vulnerabilities might get deprioritised.
No proof-of-concept means no manual verification
If a finding entry lacks a PoC section with actual request/response evidence, that finding was likely flagged by an automated scanner and included in the report without human verification. Ask your vendor which findings were manually validated and which were scanner-generated. A quality vendor will distinguish between the two clearly.
3. Remediation guidance
Generic advice like "implement input validation" does not help an engineer who needs to ship a fix by Friday. Quality remediation guidance is specific to your technology stack, references the affected code path or endpoint, and provides a concrete implementation direction. It should tell your developer what to change, not just what concept to Google.
For example: "Implement middleware-level authorisation on /api/v1/transfers/{id} that validates the authenticated user's tenant_id matches the transfer's owner_id before returning the resource. Reject mismatches with HTTP 403." That is actionable. "Fix broken access control" is not.
4. Compliance mapping
If your fintech operates under CBN regulatory oversight, PCI DSS, or NDPA/NDPR requirements, each finding should map to the relevant compliance control it violates. This mapping turns a security report into a compliance document. When the auditor asks "how do you address PCI DSS Requirement 6.5.6?", you can point directly to the finding and its remediation evidence instead of scrambling to create a mapping after the fact.
Report sections beyond individual findings
Methodology statement
The report should state what methodology was used (OWASP Testing Guide, PTES, OSSTMM), the testing approach (black-box, grey-box, white-box), the tools employed alongside manual testing, and the testing timeline. This section gives the reader confidence that the engagement followed a structured process and provides auditors with the methodology documentation they require. For more on methodology, see our tools and methodology guide.
Scope confirmation
Explicitly state what was tested and what was excluded. If your vendor tested the web application but excluded the mobile app, that should be unambiguous in the report. If certain endpoints were out of scope due to production risk, document that. This prevents the false assumption that a clean report means your entire infrastructure was reviewed.
Retest confirmation
After remediation, the report should be updated with retest results. Each finding should carry a status: Open, Remediated, or Partially Remediated. The retest section should include the date of verification and confirmation that the original attack scenario no longer succeeds. A report without retest results is incomplete. For the full post-test process, see our article on what happens after a penetration test.
Need a pentest report that your engineers and auditors can actually use?
Get a Real Pentest ReportQuestions to ask your vendor before signing
Before you engage any penetration testing vendor, ask these questions about their deliverables:
- Will every finding include proof-of-concept evidence with full request/response pairs?
- Will the report use CVSS v3.1 or v4.0 for severity scoring?
- Does the report include a separate executive summary written for non-technical stakeholders?
- Will findings be mapped to relevant compliance frameworks (PCI DSS, CBN, NDPA)?
- Is retest included in the engagement, and will the final report reflect remediation status?
- Will you provide a letter of attestation for regulators and enterprise clients?
If the answer to any of these is no, reconsider whether you are buying a penetration test or a vulnerability scan with a markup. For help evaluating vendors, see our guide on the top pentest companies in Nigeria.
Related reading
Blog: How a Simpa Labs pentest works · 5 documents to demand after a pentest · Cheap scan vs real pentest
Guides: Pentest report explained · Tools & methodology · Assessment vs pentest
Services: Penetration testing · Vulnerability assessment · API security