BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: A penetration test report has two audiences: executives who need to understand the business risk and engineers who need to close the vulnerabilities. Most reports contain an executive summary, a technical findings section, and a remediation roadmap. Reading the executive summary tells you the overall picture. Reading the technical findings tells you exactly what was found and how to reproduce it. Using the report means assigning ownership to every finding, setting remediation timelines matched to severity, and verifying closure before the next test or audit. Reports that are filed without a structured remediation process produce compliance documentation but do not improve security.

Key Takeaways

• The executive summary is the section designed for non-technical readers. It describes the scope of the test, the overall risk picture, the most significant findings in business impact terms, and the prioritized remediation focus areas. Board members, executives, and auditors who need a high-level understanding of the test results should read this section.
• Severity ratings in penetration test reports reflect real exploitability in the tested environment, not generic CVSS scores from a vulnerability database. A finding rated critical means the tester successfully exploited the vulnerability and demonstrated material impact. This is different from a scanner flagging a critical CVE that has not been verified as exploitable in the specific environment.
• Attack path diagrams are among the most important sections of a penetration test report because they show how individual findings chain together into a complete breach scenario. A single medium finding may seem manageable; seeing it as the entry point of a chain that reaches domain administrator or customer data changes the prioritization decision.
• Remediation guidance in a penetration test report should be specific enough for an engineer to act on without additional research. Generic recommendations to apply vendor patches or follow best practices are insufficient; the report should identify the specific patch, configuration change, or architectural fix required for each finding.
• Retesting, a follow-up assessment specifically targeting the findings from the original test, confirms that remediations have been implemented correctly. Some remediations that appear complete on paper are incomplete in practice; retesting catches these gaps before the next formal audit or before an attacker finds that the finding was not actually closed.

The Structure of a Penetration Test Report

Executive summary

The executive summary is a concise narrative that communicates the most important conclusions of the penetration test to an audience that does not need to understand the technical details. A well-written executive summary covers the scope of the engagement (what was tested, over what period, using what methodology), the overall risk rating (a judgment about the organization’s security posture based on the totality of findings), the most significant findings described in business impact terms rather than technical language, and the prioritized remediation focus areas that leadership should be aware of. Executives and board members who receive penetration test results should read the executive summary as their primary input for governance decisions about security investment and risk posture.

The executive summary should not require technical background to interpret. If the executive summary contains CVSS scores, CVE identifiers, or technical jargon that a CFO or board member cannot parse without a glossary, it has not been written at the right level. The business impact language that belongs in an executive summary sounds like this: an attacker with no prior access to the network could gain complete administrative control of the domain within hours of obtaining a foothold on any internal workstation, rather than: the testing team identified an Active Directory misconfiguration resulting in a Kerberoasting attack vector enabling privilege escalation to domain administrator.

Technical findings

The technical findings section is the core of the report: the detailed documentation of every vulnerability identified during the engagement, formatted for the engineers who will close them. Each finding should include the title and severity rating, a description of the vulnerability and how it was identified, the affected system or systems, the evidence of exploitation including reproduction steps and screenshots, the business impact of the finding, and specific remediation guidance. The reproduction steps are particularly important: they allow the engineering team to verify that they can reproduce the finding in their environment, confirm that it is real, and verify after remediation that the fix has worked.

Technical findings are typically organized by severity, with critical and high findings presented first. Within each severity category, findings may be organized by test area (network, application, cloud) or by the attack phase in which they were identified (initial access, lateral movement, privilege escalation, impact). The organization of findings matters for prioritization: a report that presents all 47 findings in a flat list of equal visual weight does not help the engineering team understand where to focus first, while a report organized by severity and attack phase makes the prioritization immediately clear.

Attack path diagrams

Attack path diagrams are visual representations of how individual vulnerabilities chain together into complete attack scenarios. They show the starting point (initial access), the intermediate steps (lateral movement, privilege escalation), and the endpoint (the systems, data, or accounts reached). For executives, attack path diagrams are often the most impactful section of the report because they make the concrete impact of a breach visible in a way that a finding list does not. Seeing that the path from an external phishing email to the organization’s financial systems runs through three individually unremarkable findings changes the risk calculus for all three findings.

For engineers, attack path diagrams identify the most efficient remediation targets: closing the vulnerability at the earliest point in the chain eliminates the entire subsequent attack path. A diagram showing that every attack path in the engagement ran through a single misconfigured Active Directory setting identifies that setting as the highest-leverage remediation target, more valuable than closing any of the individual findings independently.

Remediation roadmap

The remediation roadmap is a prioritized list of all findings organized for action: severity ranking, estimated remediation effort, recommended timeline, and often a suggested owner category (security team, IT operations, development team, or external vendor). A well-constructed remediation roadmap allows the engineering manager or CISO who receives the report to immediately begin assigning findings to teams and setting timelines, without needing to re-read the entire technical findings section to determine what needs to happen first.

The remediation roadmap should be specific about effort estimation. Generic recommendations that all critical findings be resolved within 30 days are less useful than finding-specific effort estimates that allow the team to plan realistically. A critical finding that requires a configuration change taking two hours is prioritized differently from a critical finding that requires an architectural redesign taking three months, even though both are critical severity.

Running an Effective Remediation Process

The most common failure in penetration testing programs is not in the quality of the test but in the remediation process that follows it. Organizations that commission penetration tests, receive detailed findings, and then address none or only some of the findings before the next test consistently find that the same vulnerabilities recur year after year. The penetration test becomes a compliance exercise rather than a security improvement mechanism. A structured remediation process prevents this outcome.

Assign ownership immediately

Every finding in the penetration test report should be assigned to a named owner within the first week after the report is delivered. The owner is the person responsible for closing the finding: driving the remediation to completion, tracking progress, and escalating when the timeline is at risk. Findings without owners tend not to get closed; findings with owners tend to get tracked. The remediation briefing that a quality penetration testing provider delivers live with the engineering team is the right moment to assign ownership, while the findings are fresh and the tester can answer questions directly.

Set severity-matched timelines

Remediation timelines should reflect both the severity of the finding and the realistic capacity of the team. A common framework is critical findings remediated within 14 days, high findings within 30 days, medium findings within 90 days, and low findings within 180 days or accepted with documented rationale. These timelines are starting points; the actual timeline for each finding should account for the specific remediation effort required. A critical finding that requires a vendor patch should be tracked against the vendor’s release timeline with a compensating control applied in the interim. A high finding that requires an architectural change may require a longer timeline with interim mitigations documented and approved.

Conduct a retest before the next audit

A retest is a focused engagement in which the penetration testing team returns to verify that the findings from the original test have been successfully remediated. Retests are faster and less expensive than full penetration tests because they are scoped specifically to the original findings. They serve two purposes: confirming that remediations are technically complete (some remediations that appear correct in configuration review turn out to be incomplete when tested adversarially), and producing documentation that the findings have been closed, which is audit evidence that the penetration testing program is producing security improvement rather than just compliance documentation. Armour Cybersecurity offers retest engagements as standard follow-on services to initial penetration testing engagements, with findings mapped to the original report for direct audit trail continuity.

Frequently Asked Questions

What do the severity ratings in a penetration test report mean?

Severity ratings in a penetration test report reflect the tester’s assessment of the real exploitability and business impact of each finding in the specific tested environment. Critical findings represent vulnerabilities that are immediately exploitable with significant business impact: an unauthenticated remote code execution vulnerability on an internet-facing server, a privilege escalation path to domain administrator from any network user account, or a direct path to sensitive customer data without authentication. High findings are exploitable with significant impact but may require additional conditions or steps. Medium findings represent real vulnerabilities that are exploitable under specific conditions or that produce limited impact in isolation but may contribute to chained attack paths. Low findings are real but have limited exploitability or impact in the current environment. Informational findings represent observations that are not direct vulnerabilities but may indicate architectural or configuration decisions worth reviewing. This is the same exploitability-first severity model that separates a penetration test from a vulnerability scan: a pen test rates what was actually exploited, not what a scanner flagged as theoretically present.

Should we share the penetration test report with our customers?

Full penetration test reports, which contain detailed exploitation evidence and reproduction steps, should not be shared externally because they provide a roadmap for attacking your environment to anyone who receives them before remediations are complete. After remediations are complete, a redacted version of the report, showing the scope, methodology, overall findings summary, and remediation status, can be shared with customers or auditors who require evidence of penetration testing. Many enterprise customers request penetration test reports or attestation letters as part of vendor security assessments; the attestation letter format (confirming that a penetration test was conducted by a named firm over a specified scope and period, with findings remediated as documented) is typically preferable to sharing the full technical report because it provides the assurance the customer needs without disclosing exploitation details that are no longer relevant once remediated.

How do we handle a finding that we cannot remediate?

Findings that cannot be remediated within the standard timeline, because of technical complexity, vendor dependency, resource constraints, or business continuity considerations, should be formally accepted with documented rationale and compensating controls. The risk acceptance process mirrors the security risk register treatment decision: the finding is documented with the reason remediation is not feasible within the standard timeline, the compensating controls that reduce the risk in the interim are identified, a re-evaluation date is set, and the acceptance is approved at the appropriate authority level based on the finding severity. Risk acceptance of a critical finding should require CISO and executive approval. The documentation of formal risk acceptance, rather than simple non-remediation without explanation, is what demonstrates to auditors that the organization has a managed approach to residual risk rather than an uncontrolled backlog.

What is the difference between a finding remediation and a compensating control?

A remediation directly addresses the root cause of the finding: patching the vulnerable software, correcting the misconfiguration, redesigning the access control model. A compensating control is a measure that reduces the risk of exploitation without eliminating the underlying vulnerability: restricting network access to a vulnerable service so it is no longer reachable from untrusted network segments, implementing additional monitoring on a service with an unpatched vulnerability, or requiring additional authentication for a function with an authorization weakness. Compensating controls are appropriate when full remediation is not immediately feasible, but they should be treated as temporary measures with a defined target date for actual remediation rather than as permanent solutions. PCI DSS has a formal compensating control framework that requires documentation of why the standard control cannot be implemented, what the compensating control provides in its place, and how the compensating control meets the intent of the original requirement.

How long should we retain penetration test reports?

Penetration test reports should be retained for as long as the compliance frameworks that require them specify, plus a reasonable buffer. PCI DSS Requirement 11.4.1 requires retaining penetration test results and remediation activities for a minimum of 12 months. Most other frameworks do not specify a retention period, but three years is a common practice that supports multi-year audit trails and allows organizations to demonstrate the trend of security improvement across multiple test cycles. Reports should be stored in a secured, access-controlled location given that they contain detailed exploitation evidence. Access should be restricted to security leadership, IT leadership, legal counsel, and auditors with a defined need to review them.

The Bottom Line

A penetration test report is only worth what your team does with it. The report itself is a deliverable; the security improvement comes from the remediation process that follows. Read the executive summary for the business risk picture, read the technical findings and attack path diagrams for what was actually exploited and how the findings chain together, and then run a disciplined remediation cycle: assign every finding a named owner in the first week, set severity-matched timelines, apply compensating controls where full remediation has to wait, formally accept and document any residual risk, and retest to confirm closure before the next audit. Organizations that file the report and move on see the same findings recur year after year; organizations that treat the report as the start of a remediation cycle measurably reduce their exposure over time. Armour Cybersecurity delivers penetration testing with a live remediation briefing and retest engagements mapped to the original findings, so the report becomes a security improvement mechanism rather than a compliance artifact.