4.1 Penetration Test Report Components
Key Takeaways
- PT0-003 moved reporting into Engagement Management (13%); objective 1.4 is scored on which section a CEO reads versus which a sysadmin needs, not on whether you can paste scanner output.
- The executive summary is non-technical residual risk and business impact; detailed findings carry evidence, affected hosts, CVSS/risk, and reproduction steps.
- The attack narrative is the chained story of how testers combined issues; methodology records how the test was run and is not a second findings list.
- Limitations and assumptions must name what was not tested (excluded CIDR, no credentials, time-box) so a quiet report is not read as 'the environment is secure.'
- Reporting considerations are legal, ethical, quality control (QC), and AI: public generative AI on client evidence can leak data or invent findings, and a human tester must still verify every claim.
On CompTIA PenTest+ PT0-003, the report is not a Domain 5 afterthought. CompTIA placed it in Engagement Management (13%) as objective 1.4: Explain the components of a penetration test report. Exam items often ask which section a CEO should read versus which a sysadmin needs. Hand an executive a packet capture, or hand an operator a three-paragraph residual-risk memo with no host list, and you failed 1.4 even if every issue is real.
Format alignment and documentation specifications
Format alignment means the delivered file matches the format the client already required in the statement of work (SoW): their template, heading order, logo, classification banner, and whether they want a PDF, a GRC-portal export, or both. A handsome firm-standard report that ignores the client's SOC 2 evidence folder, PCI DSS retest table, or TLP marking is misaligned. Alignment is not branding. Auditors reuse the structure, and a CISO who asked for a one-page scorecard plus a technical annex will not accept a 90-page novel with the summary buried on page 40.
Documentation specifications are the evidence rules attached to that format: what each finding must include, how screenshots are cropped and redacted, whether raw request/response pairs are attached or paraphrased, filename conventions, and how long raw evidence is retained. If the SoW requires a CVSS 3.1 vector, a screenshot of the affected host, and a sanitized HTTP exchange, a finding that only says "SQL injection exists" is incomplete. Specifications also cover classification (Confidential, TLP:AMBER, client-restricted) so testers treat the file as a controlled artifact, not a blog draft.
Exam trap
Format alignment is the answer when the stem is "the client template" or "the report does not match the SoW deliverable." Documentation specifications are the answer when evidence is missing, unredacted, or stored past the retention date. Neither bullet is an excuse to skip a component CompTIA names below.
Risk scoring and definitions
Risk scoring turns a technical issue into a priority the client can fund. Typical inputs are CVSS base scores, qualitative bands (Critical / High / Medium / Low / Informational), and business impact (payment outage, PHI exposure, safety). Do not paste a scanner's CVSS as residual risk. A "critical" plugin on an isolated lab VLAN that never reaches production is not the same sentence as a "medium" on the internet-facing payroll login. Compensating controls, exploitability during the window, and data sensitivity all move the number. State the method in the report so two readers can reconstruct why Finding 3 outranks Finding 7.
Definitions stop vocabulary collisions. Include a short glossary for this engagement: exploited versus identified, confirmed versus potential, critical versus high, in scope versus observed out of scope, and informational. Without definitions, a CEO hears "we exploited the domain" as "attackers are in production right now," while a sysadmin hears a successful Kerberos test against a lab DC. Definitions are an official 1.4 bullet, not optional polish.
Report components: who reads what
PT0-003 names five report components. Memorize the audience with the heading.
| Component | Primary reader | What it contains | What it is not |
|---|---|---|---|
| Executive summary | CEO, CISO, board, business owner | Non-technical residual risk, business impact, overall posture, counts by severity, whether objectives were met | Packet captures, CVE tables, Metasploit session IDs |
| Methodology | Security leadership, auditors, future testers | How the test ran: scope recap, dates and windows, knowledge level, standards (PTES, OWASP), tool classes | A dump of every Nmap flag, or a substitute for findings |
| Detailed findings | Sysadmins, developers, control owners | Per-issue title, affected hosts, evidence, CVSS/risk, reproduction steps, impact | The only section an executive is expected to finish |
| Attack narrative | Technical managers, detection engineering, a CISO who wants the story | The chained path from foothold to objective | A chronological reprint of every finding with no synthesis |
| Recommendations (with remediation guidance) | Control owners and project managers | What to fix, in what order, with enough direction to act | A vendor shopping list, or a promise that the tester will patch production |
Executive summary. Write it last, after findings are scored and peer-reviewed. Use business language: customer invoice data was reachable from the internet-facing login; residual risk remains high until the application is parameterized and default database credentials are rotated. Give severity counts and say whether the test objective (for example, reach payroll) was achieved. Do not hide a ransomware-capable finding in paragraph four of a cheerful letter. This is the section a CEO should read.
Methodology. Recap authorized targets, exclusions, testing windows, and whether the test was black-, gray-, or white-box. Map the approach to a named methodology without turning the section into a framework essay (that comparison is objective 1.3). Mention tool classes — credentialed vulnerability scanning, authenticated web testing — rather than a 40-page appendix of version strings unless the SoW asked for it.
Detailed findings. Each finding stands alone: identifier, title, affected asset (hostname, IP, URL, account), evidence (screenshot, request, hash), risk score, impact, and reproduction a competent admin can follow without the tester on the phone. Reproduction is not a live exploit kit; it is enough to verify the issue and later verify the fix. This is the section a sysadmin needs.
Attack narrative. Tell the chain. Default wiki password → stolen CI token → production postgres still on the vendor default → export of payroll. Individual CVEs do not explain that path. The narrative is how leadership sees realistic attacker progress, and how detection engineering sees missed alerts.
Recommendations, including remediation guidance. Point to fixes, owners, and sequencing. Objective 1.5 (next section) is where you pick the control type. In 1.4, know that recommendations live in the report and must include remediation guidance, not a one-line "fix SQL injection."
Test limitations and assumptions
A limitations and assumptions section is how you keep a quiet report from being misread as "we are secure." State what was not tested: excluded CIDRs, systems for which no credentials arrived, the production database cluster the RoE forbade, phishing that was out of scope, a WAF left in blocking mode, IPv6 never routed to the tester, and the time-box that ended Saturday at 05:00. State assumptions too: the asset inventory was complete; staging mirrors production; the provided test user represents a normal employee. If credentials arrived on day four of a five-day test, write that authenticated testing was truncated. Clients and auditors who skip this section will quote "zero criticals" in a board deck that should have said "zero criticals in the unauthenticated, time-boxed slice."
Reporting considerations: legal, ethical, QC, and AI
PT0-003 lists four reporting considerations. They apply to the finished document, not only to how you sent it.
Legal. The report is a controlled work product. Honor the NDA, engagement contracts, and any legal-hold or privilege instruction from counsel. Do not put regulated data (full PAN, ePHI, government IDs) in an appendix if a redacted sample proves the issue. Know who is authorized to receive the file. Secure distribution itself is a 1.2 collaboration activity (encrypt in transit and at rest, use the named channel). Objective 1.4 assumes you still treat the finished report as a legal artifact, not a public PDF; this section does not retread the 1.2 delivery workflow.
Ethical. Do not pad severity to sell a retest. Do not include live customer records, employee home addresses, or exploit modules that have no verification value. If you observed something illegal or clearly out of scope, follow the RoE escalation path; do not "document it colorfully" in a widely copied report.
Quality control (QC). QC is the human process that stops false positives and invented impact from reaching the client. Peer-review evidence, reproduce the issue, match hostnames to the inventory, and kill scanner noise. A report that ships unverified plugins as "findings" fails QC even if the executive summary is eloquent. QC is also the last gate before any AI-assisted draft is allowed to leave the team.
Artificial intelligence (AI). CompTIA lists AI as a reporting consideration. Using a public generative-AI service on client evidence can leak engagement data to a vendor that is not on the NDA, and the model can invent findings, CVEs, or hosts that were never tested. There is no CompTIA AI-policy number to memorize; the exam point is leakage plus hallucination. Offline grammar tools that never leave the tester's disk are a different risk from pasting payroll screenshots into a chatbot. QC still requires a human tester to verify every claim, citation, and asset name before the client sees the file. AI may draft structure. It cannot sign the report.
Write for the reader in front of you: executives get residual risk; operators get evidence and reproduction; everyone gets honest limitations. That is what 1.4 scores.
A CEO asks where in the penetration test report to find residual risk and business impact without packet captures or CVE tables. Which section should that executive read?
Testers chained a default password on an internal wiki into a stolen CI token and then into the payroll database. Which report component should present that sequence as a realistic attacker path?
A tester wants to speed up write-ups by pasting production screenshots and customer invoice tables into a public generative-AI chatbot. Which statement matches PT0-003 reporting considerations?