What a Penetration Test Report Should Contain
Published · 5 min read
The testing days of a penetration test end. The report is what stays. It is the document your engineers work from, the one your leadership reads to decide what to fund, and often the one your customers or auditors ask to see. A test that finds serious issues but delivers them in a vague or unusable report has wasted much of its value.
This article sets out what a penetration test report should contain, section by section, and why each part matters. It reflects how Veiliux structures its own reporting.
One document, two audiences
A penetration test report has to serve two very different readers. Executives need to understand risk in business terms without wading through request headers. Engineers need exact technical detail to reproduce and fix each issue. Splitting these into separate documents tends to mean one of them gets neglected.
Veiliux reports are written for both audiences in one document: an executive section first, followed by a technical section. Each reader can go straight to the part written for them, and both are describing the same findings.
The executive summary
The executive section should state, in plain language, three things: what an attacker could achieve against your environment, what that would cost the business, and which three actions would reduce most of that risk.
That last point is the most important. A summary that only says the environment has twelve high-severity findings does not help anyone decide what to do on Monday. A summary that says the three changes which would close most of the realistic attack paths gives leadership something concrete to approve.
Plain language, not jargon
The executive section should be readable by someone without a security background. If it needs a glossary to understand, it has failed its audience. Technical terms belong in the technical section.
Scope and rules of engagement
Every report should record exactly what was tested and under what conditions. At Veiliux this is agreed in writing during scoping: the asset inventory, rules of engagement, test windows and escalation contacts.
Recording scope in the report matters for two reasons. First, it tells readers what the results do and do not cover; a clean result on one application says nothing about another that was out of scope. Second, it gives auditors and customers the context they need to judge whether the test meets their requirements.
Attack chains, not just isolated findings
Real attacks rarely rely on a single critical vulnerability. They combine smaller issues. A medium-severity information disclosure is only interesting when it unlocks an authentication bypass, which in turn exposes an administrative function that reaches the database.
A good report documents those chains explicitly, because the realistic risk of an environment is almost never the sum of its individual issues. Reading each finding in isolation can make an environment look safer than it is. Showing the chain shows why a seemingly minor issue deserves a fix.
Per-finding technical detail
The technical section is where engineers spend their time. For each finding it should give enough to understand, reproduce and fix the issue without needing to contact the tester. In a Veiliux report each finding includes the following.
Affected assets
Exactly which hosts, applications, endpoints or accounts are affected. Without this, teams waste time working out where the problem lives.
Severity and exploitability rating
A CVSS score and an exploitability rating. Findings are ranked by exploitability and business impact, so the order of the report reflects what genuinely deserves attention first rather than a raw technical score alone.
Evidence
Proof that the issue is real. Where safe to do so, exploitation is carried through to proof, with screenshots, request and response pairs, and reproduction steps that your engineers can replay in a lab. Exploit-verified findings remove the false positives that make unverified reports hard to trust.
Remediation guidance
Guidance specific to your stack, not generic advice to apply best practice. Each finding should ship with a fix your engineers can apply.
References
Links to the relevant standards or public references, so teams can read further if they need to.
Coverage against recognised standards
Readers should be able to see what was tested against, because a report that does not say which standards were applied is hard to compare with any other. For web and API testing at Veiliux that means OWASP Top 10 and API Top 10 coverage, alongside business logic abuse, authentication and session attacks. For network work it covers external and internal testing and Active Directory attack paths; for cloud, AWS, Azure and GCP configuration; for mobile, local storage, transport security, runtime tampering and backend API trust on iOS and Android.
Stating coverage clearly helps auditors map the test to their own requirements and helps your team understand where the test went and where it did not.
The debrief
A report should not arrive as a cold attachment. Veiliux delivers executive and technical reporting with a live debrief for your engineering team. The debrief is where engineers can ask how an issue was found, check they understand the fix, and agree priorities with the people who did the testing.
The retest and the updated report
The most useful version of a penetration test report is often the second one. After you remediate, a retest should confirm the issues are actually closed. At Veiliux a retest is included at no extra cost: the relevant test cases are re-run and the report is reissued with the closed items marked.
This updated, shareable report is usually the artefact your customers or auditors want to see, because it shows not just that issues were found, but that they were fixed and verified.
A checklist for reviewing any report
When you receive a penetration test report, check that it has: a plain-language executive summary with prioritised actions; a clear statement of scope and rules of engagement; documented attack chains; per-finding affected assets, severity, exploitability, evidence, remediation and references; coverage against recognised standards; a live debrief; and a retest with a reissued report. If any of these are missing, ask why.