By Cyber Defense Technologies April 28, 2026 5 min read
When a penetration test ends, the report is what remains. It is what executives read, what engineers work from, and what auditors and customers may ask to see. A strong report turns a week or two of testing into clear decisions and concrete fixes. A weak one leaves teams sorting through pages of generic findings, unsure what matters.
Here is how to tell the difference.
A penetration test report should include
- An executive summary in business terms
- Scope, rules of engagement and testing dates
- Methodology and the perspective tested from
- Attack narratives showing how findings chain
- Each finding with evidence you can reproduce
- Risk ratings that reflect your environment
- Specific, prioritized remediation guidance
- Mapping to MITRE ATT&CK where relevant
- What was tested and found secure
- A clear path to retesting fixes
An executive summary that speaks to leaders
Leaders need to understand, in a page or two:
- what was tested and why
- the overall result: could an attacker achieve meaningful objectives, and how difficult was it?
- the most important risks, in business or mission terms
- the few actions that would reduce risk the most
If the executive summary is a table of vulnerability counts by severity, it is not doing its job. "Testers gained administrative control of the corporate domain within one day, starting from a phishing-equivalent foothold, primarily due to reused local administrator passwords" tells a leader far more than "3 critical, 11 high, 24 medium."
Clear scope and method
The report should state exactly what was tested, from what perspective (external, internal, authenticated, unauthenticated), during what dates, and under what rules of engagement. It should also note what was out of scope or could not be tested. Without this context, a clean result can be misread as broader assurance than the test provided.
Attack narratives
The most valuable part of many reports is the story: how the testers moved from their starting point to their objectives, step by step. Attack narratives show:
- how individual weaknesses combined into a path
- where defenses worked, and where they did not
- which single fixes would break the path
A report that lists findings without showing how they connect leaves you to guess at the real risk.
Findings with evidence
Each finding should include:
- A clear description of the weakness and why it matters
- Affected systems specifically identified
- Evidence: screenshots, commands, requests and responses, sufficient for your team to reproduce and verify the issue
- Risk rating with the reasoning behind it
- Remediation guidance specific enough to act on
- References such as vulnerability identifiers or configuration guidance where relevant
Findings copied from a scanner, with generic text and no evidence of exploitation, are a warning sign.
Risk ratings that reflect your environment
Generic severity scores, such as CVSS base scores, describe a vulnerability in the abstract. Your risk depends on context: whether the system is exposed, what data it holds, whether compensating controls exist, and whether the weakness was actually exploited during testing. Good reports explain how context shaped each rating.
Remediation guidance you can use
"Apply patches" and "harden configuration" are not guidance. Useful remediation explains what to change, where, and how to verify the fix, and distinguishes quick fixes from longer-term improvements. It should also call out systemic issues, such as a weak password practice seen across many systems, that deserve a root-cause fix rather than one-by-one remediation.
Mapping to frameworks
Mapping findings and techniques to MITRE ATT&CK helps defenders connect test results to detection engineering. Where relevant, references to compliance requirements help organizations update security plans and POA&Ms.
Positive findings
A good report also records what was tested and found secure, and where defenses detected or blocked testers. This helps organizations understand what is working, avoid unnecessary changes and credit teams appropriately.
A path to retesting
The report should explain how fixes will be verified. Retesting confirms that remediation actually closed the attack paths, and provides evidence for auditors and leadership.
Red flags
- Dozens of pages of scanner output with little analysis
- Findings without evidence of exploitation or verification
- Generic remediation advice copied across findings
- No attack narratives or explanation of how findings relate
- Ratings that ignore your environment's context
- No distinction between what was tested and what was not
Before you buy, ask for a sample
A sanitized sample report is the best predictor of what you will receive. Review it with both an executive and an engineer in mind: would each of them know what to do after reading it?
An example of a strong finding
Finding: Local administrator password reused across workstations (High)
Description: The built-in local administrator account on sampled workstations uses the same password. An attacker who compromises one workstation can authenticate to others with the same credential.
Affected systems: 212 of 215 domain workstations tested.
Evidence: The credential was recovered from the first compromised workstation (screenshot 4) and used to authenticate to workstations in the finance and engineering units (screenshots 5 to 7). This enabled lateral movement described in Attack Narrative 1, step 3.
Risk: High in this environment. Combined with Finding 2, it allowed the testers to reach a server where a domain administrator was signed in, leading to domain compromise. Endpoint protection did not alert on the lateral movement.
Remediation: Deploy a local administrator password management solution that sets unique, rotated passwords on each workstation. As an interim measure, restrict local administrator network logons through Group Policy. Verify by attempting authentication with the old password against a sample of workstations.
ATT&CK: Valid Accounts: Local Accounts (T1078.003); Lateral Movement.
This finding tells an engineer exactly what to fix, tells a manager why it matters, and tells a defender what to detect.
Frequently asked questions
Should we share the report with customers or auditors? Many organizations share an executive summary or a letter of attestation rather than the full report, which contains sensitive detail. Ask your provider what formats they offer.
How CDT can help
CDT's penetration testing reports include executive summaries in plain language, attack narratives, reproducible evidence, context-aware risk ratings and findings mapped to MITRE ATT&CK, with retesting to confirm fixes. Penetration Testing as a Service delivers findings as they are verified.