Most people who buy a pen test never see the testing. They see the report. It’s what your developers work from, what your manager reads, and what your auditor asks for. So it helps to know what a good one looks like.
A bad report is a scanner export with a logo on it: 200 findings, no context, no idea what to fix first. A good one tells a developer exactly what broke, tells a manager why it matters, and tells everyone what happens next.
Sunvak Boreal writes reports for both audiences. Your engineers get the detail they need to fix things, and your leadership gets a clear read on the risk.
What Is a Penetration Testing Report?
It’s the formal record of a penetration test: what was tested, how, what turned up, and what to do about it. It usually covers the scope, objectives, methodology, testing dates, findings, severity ratings, evidence, business impact, remediation advice, and retesting needs.
What’s in a Good Report
The structure shifts with the type and scope of the test, but a professional report usually includes these parts.
1. Executive summary
This is for the people who will never read page 30. It states the purpose and scope, the overall findings, the biggest concerns, the business impact, and the top recommendations, without any jargon. If a busy executive reads one page, this is the one.
2. Assessment scope
What was tested: web apps, mobile apps, APIs, IP ranges, cloud environments, servers, domains, specific features, user roles. Just as important, what was left out. Without that, people assume the report covers things nobody touched.
3. Assessment objectives
Why the test happened. Maybe you needed to find exploitable vulnerabilities, satisfy a compliance requirement, check earlier fixes, or see how exposed a system was before launch.
4. Testing methodology
How the work was done, in general terms: information gathering, enumeration, manual testing, exploitation, privilege escalation, attack path analysis, and impact validation. It helps readers judge how thorough the test was.
5. Testing dates and environment
When the test ran and against what: production or staging, which application and API versions, which cloud and network environments. A finding from staging last spring means something different from one in production this week.
6. Risk rating and severity
Every confirmed vulnerability gets a rating, usually Critical, High, Medium, Low, or Informational. Ratings weigh exploitability, technical impact, data exposure, required privileges, user interaction, business impact, and affected assets. Some reports also use CVSS where it fits.
7. Vulnerability summary
A quick count of findings by severity, so management can see the overall picture in seconds.
| Severity | Number of Findings |
| Critical | 0 |
| High | 3 |
| Medium | 6 |
| Low | 4 |
| Informational | 5 |
8. Detailed findings
Usually the most important section. Each finding has a title, severity, affected asset and endpoint, a description, technical details, security impact, evidence, reproduction steps, a recommended fix, and references. The test is simple: could a developer who never saw the test understand the problem and reproduce it?
9. Affected assets
The URLs, API endpoints, IP addresses, domains, mobile components, cloud resources, servers, and network services each finding touches. This tells your team where the fixes go.
10. Technical evidence
The proof: screenshots, HTTP requests and responses, API calls, logs, command output, configuration evidence, and proof-of-concept results. Sensitive data in the evidence should be redacted where appropriate.
11. Proof of concept
Where it applies, a demonstration of how the vulnerability was validated. The aim is to show the issue is real and explain its impact without exposing more sensitive data than necessary. Think of a modified API request, or access to a resource the tester shouldn’t have been able to reach.
12. Reproduction steps
A short walkthrough. For a typical access control bug it might read: log in with the test account, call the affected endpoint, change the object ID, look at the response, confirm the access was unauthorized. These steps help developers understand the bug now, and verify the fix later.
13. Business impact
Technical detail tells you what’s broken. Business impact tells you why anyone should care: data exposure, account compromise, privilege escalation, financial loss, service disruption, regulatory trouble, reputational damage. A good report bases this on what testing actually showed, not worst-case guesses.
14. Remediation recommendations
Practical guidance on the fix: stronger authorization checks, updated software, corrected configurations, better authentication, least privilege, improved input validation, tighter API access controls, better logging. The best advice targets the root cause, not just the one symptom the tester happened to hit.
15. Attack path analysis
Sometimes the real story is how findings connect. An information leak, a loose permission, a vulnerable service, and a privilege escalation can each look minor alone and add up to a serious compromise together. This section shows how.
16. Security controls tested
Which controls were actually examined: authentication, authorization, network segmentation, encryption, session management, logging, rate limiting, cloud access controls, and so on. It gives context for what “no findings” in an area really means.
17. Limitations and constraints
A good report is honest about what it couldn’t do: out-of-scope systems, limited test accounts, restricted testing windows, rate limits, excluded third-party systems, production safety restrictions. This stops readers assuming coverage that wasn’t there.
18. Overall risk summary
A high-level view of the findings and their potential impact, to help you prioritize. It should reflect what was found, and it shouldn’t suggest that a pen test guarantees security. It doesn’t.
19. Retesting recommendations
Which findings should be retested after fixes, and why. Retesting shows whether the vulnerability is really gone, whether the fix holds, and whether the fix broke something else.
20. References
Supporting material such as the OWASP Web Security Testing Guide, OWASP API Security Top 10, OWASP ASVS, NIST SP 800-115, CVE records, CWE, CIS Controls, and vendor documentation.
Technical Report vs. Executive Report
Different readers need different things, and a full engagement often delivers both.
| Technical Report | Executive Report |
| Detailed technical findings | High-level security overview |
| Reproduction steps | Business impact |
| Evidence and screenshots | Major security concerns |
| Affected endpoints and assets | Finding summary |
| Remediation details | Strategic recommendations |
| Technical references | Management-focused information |
| Used by security and development teams | Used by management and leadership |
What Makes a Report Good?
A useful report is clear, so developers and security teams can follow it without guessing. It’s evidence-based, with proof behind each finding. It’s actionable, telling people what to do. It’s accurate, separating confirmed vulnerabilities from observations and potential risks. It’s prioritized, so the serious issues are easy to spot. And it’s reproducible, with enough detail for your team to see the problem themselves.
Report Types by Test
A web application report usually focuses on authentication, authorization, input validation, session management, and business logic. An API report often documents authentication, authorization, BOLA, data exposure, rate limiting, and API business logic. A network report may cover exposed services, segmentation, access controls, and infrastructure weaknesses. A mobile report can include authentication, local storage, network communication, and app configuration. A cloud report may cover configurations, identity and access controls, exposed resources, storage, and cloud-specific attack paths.
Why Sunvak Boreal?
Our reports are built so both sides of your organization can use them. They can include executive summaries, detailed technical findings, severity ratings, affected assets, evidence, reproduction steps, business impact, remediation recommendations, attack path analysis, retesting guidance, and security references.
The aim is to turn test results into something your security, development, infrastructure, and management teams can use to decide what to fix, and in what order.
Final Thoughts
A penetration testing report should do more than list vulnerabilities. It should explain what was tested, what was found, why each finding matters, how it was validated, and what to do next.
A clear report helps your engineers fix problems and helps your leadership understand the risk. If you’d like to see what ours look like, Sunvak Boreal is happy to talk it through.
[Get a Detailed Penetration Testing Report]
Frequently Asked Questions
What is included in a penetration testing report?
Usually the scope, objectives, methodology, testing dates, vulnerability findings, severity ratings, evidence, business impact, remediation recommendations, limitations, and retesting guidance.
Does a penetration testing report include screenshots?
It can. Screenshots and other technical evidence are often included to show how a vulnerability was found or validated.
Does the report include remediation recommendations?
Yes. Professional reports generally include guidance to help you fix the weaknesses found.
What’s the difference between an executive and technical report?
An executive report gives a high-level view of findings and business impact. A technical report contains the detailed findings, evidence, reproduction steps, and remediation information.
Does a report include CVSS scores?
It may. CVSS is often used to communicate severity, though the exact risk-rating approach varies between assessments.
Does a report guarantee my application is secure?
No. A penetration test assesses the systems and scope tested during a defined period. It can’t guarantee that every vulnerability has been found.
Is retesting included in the report?
The original report can identify which findings should be retested. A separate post-remediation verification report can then document whether the fixes worked.
Who uses a penetration testing report?
Security teams, developers, IT and infrastructure teams, compliance teams, risk managers, and business leaders, each focusing on different sections.