What Is a Penetration Test Report and How to Write One
You finish the engagement. You’ve run your scans, exploited misconfigurations, escalated privileges, and documented your steps. Now comes the part many testers underestimate — writing a report that actually gets used.
A penetration test report is the primary deliverable of your engagement. It communicates what you found, what it means, and what the client needs to do about it. A technically brilliant test loses most of its value when the report is unclear, disorganized, or written only for a technical audience. The report is what gets read in boardrooms, filed with auditors, and acted on by developers. Getting it right is a professional skill in its own right.
What Goes Into a Penetration Test Report
Every report serves two audiences simultaneously: executives who need to understand business risk, and technical staff who need to fix specific vulnerabilities. Structuring for both is not optional — it is how professional pen testers operate.
The standard structure used across the industry, aligned with the Penetration Testing Execution Standard (PTES) and referenced in the Canadian Centre for Cyber Security’s Skills Framework for penetration testers at cyber.gc.ca, includes the following components.
The executive summary sits at the top. This is a two-to-three page overview written for non-technical readers. It states the purpose of the test, the overall risk posture, and the most critical findings. It should be readable in under five minutes and free of jargon. The reader should walk away knowing whether their organization is in serious trouble or managing risk reasonably well.
The scope and methodology section follows. This defines what systems were in scope, what testing approach was used — black box, grey box, or white box — and what tools and frameworks guided the engagement. OWASP, NIST SP 800-115, and PTES are the most commonly referenced methodologies. Canadian clients operating under ITSG-33 or PIPEDA requirements will often need the methodology section to demonstrate alignment with recognized standards for audit purposes.
How to Document Your Findings
This is where most reports succeed or fail. Each finding needs to stand on its own. A weak finding entry gives the vulnerability a name, assigns a severity rating, and moves on. A strong finding entry tells a story: what was found, where it was found, how it was found, what an attacker could do with it, and what needs to happen to fix it.
For every finding, include the following elements. Start with a clear title — “Unauthenticated Remote Code Execution on Web Server” communicates more than “Critical Finding 1.” Follow with the affected system or component, the severity rating using a recognized scale such as CVSS, and the technical description. Then include your proof of concept — screenshots, command output, or code snippets that demonstrate the vulnerability is real and reproducible. End with a specific remediation recommendation tied to the affected technology or configuration.
Severity ratings deserve attention. CVSS scores give you a numeric baseline, but clients benefit from contextual risk ratings that account for their specific environment. A medium-severity finding on a public-facing authentication system may warrant higher urgency than a high-severity finding on an isolated internal host. Use your judgment and explain your reasoning.
The Remediation Section
The remediation section is what transforms a report from a list of problems into an action plan. Remediation recommendations must be specific and actionable. “Patch the server” is not useful. “Apply the vendor patch for CVE-2025-XXXXX to the Apache web server running on 192.168.1.10, and review all similar hosts in the same subnet for the same version” is actionable.
Where relevant, map findings to compliance frameworks. Canadian organizations under ITSG-33 controls, the CCCS Baseline Cyber Security Controls for Small and Medium Organizations, or the Cyber Security Readiness Goals for critical infrastructure will want findings mapped to specific control gaps. This saves compliance teams significant time and strengthens the business case for remediation budgets.
Group your recommendations into tiers: immediate actions for critical and high findings, short-term actions for mediums, and longer-term improvements for low-severity or systemic issues. This helps organizations prioritize without needing to interpret severity ratings themselves.
Professionalism and Confidentiality
A penetration test report contains detailed information about how to compromise your client’s systems. Handle it accordingly. Reports should be encrypted at rest and in transit. Delivery should follow the method agreed upon in the rules of engagement. In Canada, organizations subject to PIPEDA may have specific requirements around how security assessment data is stored and shared — confirm this with your client before the engagement starts, not after.
Use consistent formatting throughout. Number your findings. Use a colour-coded risk matrix that your client’s leadership will recognize. Avoid jargon in the executive summary but do not oversimplify findings in the technical section — your client’s developers and IT team need precision.
Proofread before delivery. Grammar errors and inconsistent severity ratings undermine confidence in your work. The report reflects your professionalism as much as your technical skill.
Building This Skill Through Certification
Report writing is a component of professional penetration testing training, not an afterthought. The Certified Penetration Testing Engineer (CPTE) program covers the full engagement lifecycle, including how to document findings clearly and deliver actionable reports to clients. For testers moving into consulting engagements, the Certified Penetration Testing Consultant (CPTC) builds on that foundation with client-facing skills, engagement scoping, and professional reporting standards aligned with the PTES framework at pentest-standard.readthedocs.io.
The technical skills get you the vulnerability. The report is what gets it fixed. In Canada’s security market, where organizations are under increasing pressure from CCCS guidance and evolving regulatory requirements, the testers who write clear, well-structured reports are the ones who get called back.
