Pentest Findings Report

Convert raw authorized engagement findings into a structured, client-ready penetration test report aligned to PTES and OWASP Testing Guide documentation standards.

intent

Use this skill when an authorized penetration tester, red team operator, or security consultant needs to document and draft findings from a completed authorized engagement into a structured penetration test report. The skill guides you through seven phases: engagement metadata capture, executive summary drafting, findings intake with CVSS scoring, risk summary table generation, remediation roadmap grouping, technical appendix stub creation, and final DRAFT report assembly. Output is always marked DRAFT pending lead tester review and sign-off before client delivery. This skill enforces authorization checks, prohibits exploit payloads in documentation, and requires tester input for all severity and CVSS assignments.

inputs

Engagement metadata (required before Phase 1):

• Engagement name and reference number
• Client organization and primary contact name/email
• In-scope assets: IP ranges, domains, applications, physical locations
• Out-of-scope assets (explicit list)
• Rules of engagement summary (escalation procedures, working hours, attack types allowed/forbidden)
• Testing window: start and end dates
• Testing team names: lead tester, all testers, designated reviewer
• Report classification level: Confidential or Restricted

Findings data (required for Phase 3, one finding at a time):

• Finding title (clear, specific descriptor)
• Severity rating: Critical, High, Medium, Low, or Informational (tester-provided, non-negotiable)
• CVSS 3.1 Base Score (numeric, 0.0 to 10.0) and full vector string (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
• Affected asset(s): hostname, IP, application name, or physical location
• Vulnerability description: what the vulnerability is, root cause, technical mechanism
• Proof-of-concept evidence summary: reference to screenshot filenames, log excerpts, HTTP request/response artifacts, command execution output (no working exploit code)
• Business impact statement: what an attacker can do with this vulnerability in plain language
• Remediation recommendation: specific, actionable steps (not generic advice)
• References: CVE ID(s), CWE ID(s), OWASP category (e.g., A03:2021), vendor advisory links

External connections (optional but recommended):

• Google Docs or Markdown editor for draft assembly and real-time tester review (URL or local path)
• Screenshot repository or artifact store (path or S3 bucket reference) for PoC evidence
• CVSS calculator (online or local) for vector string validation (https://www.first.org/cvss/calculator/3.1)

Authorization verification (required):

• Written or verbal confirmation that all testing was explicitly authorized within scope
• Engagement contract or rules of engagement document (reference or attachment)
• Authority to produce and distribute report (lead tester name and signature authority)

procedure

Phase 1: Engagement Metadata Capture

1. Input: request engagement name and reference number from tester. Output: recorded engagement identifier.
2. Input: request client organization name and primary contact (name, title, email). Output: client metadata recorded.
3. Input: ask tester to list all in-scope assets (IP ranges, domains, URLs, applications, physical locations). Output: in-scope asset inventory.
4. Input: ask tester to explicitly list out-of-scope assets. Output: out-of-scope asset inventory.
5. Input: request rules of engagement summary (working hours, attack restrictions, escalation procedures). Output: RoE statement recorded.
6. Input: request testing window start and end dates. Output: testing dates recorded.
7. Input: ask for testing team: lead tester name, all participating tester names, designated report reviewer. Output: team roster recorded.
8. Input: ask for report classification (Confidential or Restricted). Output: classification level set.

Phase 2: Executive Summary Inputs

1. Input: ask tester for overall risk rating (Critical, High, Medium, or Low). Output: overall rating recorded.
2. Input: ask tester to provide finding counts by severity tier (e.g., Critical: 2, High: 5, Medium: 12, Low: 8, Informational: 3). Output: severity tally recorded.
3. Input: ask for one-paragraph business context: why was this assessment conducted, what triggered it, what business objective does it serve. Output: business context statement recorded.
4. Input: ask tester to list top 3 Critical or High findings to highlight for leadership audience (just titles, no detail yet). Output: leadership highlight list recorded.
5. Input: ask for one-to-two sentence overall security posture statement for CISO audience (e.g., "The organization has adequate perimeter controls but significant application-layer vulnerabilities. Immediate remediation of critical findings is required before production deployment."). Output: posture statement recorded.
6. Generate draft Executive Summary using all inputs above. Output: formatted Executive Summary section (1 to 2 pages, CISO-readable tone).
7. Input: display draft to tester and ask for confirmation ("Does this Executive Summary accurately represent the engagement findings and risk profile?"). Output: Executive Summary approved or request revisions; repeat until tester confirms.

Phase 3: Findings Intake

1. Input: ask "Ready to enter findings? (Y/N)". If N, skip to Phase 4. If Y, proceed.
2. Input: ask tester for finding title. Output: title recorded.
3. Input: ask tester for severity (Critical, High, Medium, Low, Informational). Output: severity level recorded.
4. Input: ask tester for CVSS 3.1 Base Score and vector string. If tester does not have it, ask for required base metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability). Output: CVSS score and vector recorded; if estimated by you, label as "Estimated" and note that tester must validate.
5. Input: ask tester for affected asset(s). Output: asset list recorded.
6. Input: ask tester for vulnerability description (what it is, root cause). Output: description recorded.
7. Input: ask tester for proof-of-concept evidence summary (screenshot filenames, log excerpts, HTTP artifact references, command output references). Output: PoC summary recorded. Reminder: no working exploits, shellcode, or attack scripts allowed.
8. Input: ask tester for business impact in plain language (what can an attacker do with this vulnerability). Output: impact statement recorded.
9. Input: ask tester for remediation recommendation (specific and actionable). Output: remediation guidance recorded.
10. Input: ask tester for references (CVE, CWE, OWASP category, vendor advisory URLs). Output: references recorded.
11. Input: ask "Are there more findings to enter? (Y/N)". If Y, return to step 2. If N, proceed to step 12.
12. Output: display full findings list (title, severity, CVSS, asset) and ask tester to confirm all entries are accurate. If changes needed, allow edit and repeat step 12. If confirmed, proceed to Phase 4.

Phase 4: Risk Summary Table

1. Input: use all findings from Phase 3. Sort by severity (Critical first, then High, Medium, Low, Informational). Output: sorted findings list.
2. Input: ask tester "Have any findings been mitigated or remediated since the engagement ended? (Y/N). If Y, ask for finding title and current status (Mitigated or Remediated)". Output: status field updated for affected findings. All others default to "Open".
3. Output: generate risk summary table with columns: # (row number), Title, Severity, CVSS Score, Affected Asset, Status. Rows sorted by severity.
4. Input: display table to tester and ask for confirmation. Output: table approved or request changes; repeat until confirmed.

Phase 5: Remediation Roadmap

1. Input: use all findings and their severity levels from Phase 4. Output: group findings into three effort tiers based on severity and urgency.
   • Immediate (≤30 days): all Critical and High findings
   • Short-term (31 to 90 days): all Medium findings
   • Long-term (>90 days): all Low and Informational findings
2. Output: for each tier, create list with columns: Finding Title, Recommended Action (from Phase 3 remediation input), Responsible Team (placeholder, tester to fill). Display to tester.
3. Input: ask tester "Which team or teams are responsible for remediation in each tier?" Output: Responsible Team placeholders filled or noted as "TBD , confirm with client".
4. Input: ask "Does this roadmap align with your organization's remediation capacity and client expectations? (Y/N)". If N, allow tester to adjust tier assignments. Output: finalized Remediation Roadmap.

Phase 6: Technical Appendices

1. Output: generate appendix stub templates:
   • Appendix A: Detailed Scope and Methodology (placeholder: "Lead tester to document specific testing methodologies, phases, and tools used.")
   • Appendix B: Testing Tool List (placeholder: "List of automated and manual tools used during engagement.")
   • Appendix C: Raw Finding Evidence Log (placeholder: "Lead tester to attach screenshots, log files, network captures, and other evidence artifacts.")
   • Appendix D: CVSS Scoring Rationale for Critical/High Findings (placeholder: "For each Critical or High finding, document the justification for CVSS base metrics and score.")

Phase 7: DRAFT Report Assembly

1. Output: assemble DRAFT report document in this order:
   • Cover Page: engagement name, client organization, testing window (start date to end date), report classification (Confidential), version (DRAFT v1 with date), lead tester name
   • Table of Contents: hyperlinked sections
   • Executive Summary (from Phase 2)
   • Engagement Overview: scope (in-scope and out-of-scope assets), methodology summary, testing window, rules of engagement summary
   • Risk Summary Table (from Phase 4)
   • Technical Findings: one numbered section per finding containing (a) finding title, (b) severity, (c) CVSS 3.1 score and vector, (d) affected asset(s), (e) vulnerability description, (f) proof-of-concept evidence summary, (g) business impact, (h) remediation recommendation, (i) references
   • Remediation Roadmap (from Phase 5)
   • Appendices (stubs from Phase 6)
   • Lead Tester Review Block (see below)
2. Output: append this block verbatim to end of report:

   DRAFT - FOR AUTHORIZED INTERNAL REVIEW ONLY
   Lead Tester Review: _____________________________________ Date: __________
   Reviewer Sign-off:  _____________________________________ Date: __________
   
   This report documents findings from an authorized security engagement.
   Do not distribute without lead tester signature. Drafted with AI assistance;
   human review required before client delivery.
   

3. Input: ask tester "What format do you prefer for final delivery: Markdown, PDF, or Word (.docx)?" Output: deliver assembled report in requested format.
4. Output: confirm report location and filename to tester. Remind tester: "This is a DRAFT. Lead tester must review and sign-off before sharing with client."

decision points

Authorization check (applies throughout all phases):

• If tester mentions findings on assets not in the in-scope list, pause and ask: "This finding affects [asset]. Is this asset explicitly in-scope per your rules of engagement and client authorization?" If tester says no, move the finding to a separate "Out-of-Scope Observations" section at the end of the report with a note: "These findings were identified outside the authorized scope. Confirm with client before including in final report." If tester says yes, add asset to in-scope list and proceed. Do not proceed without explicit authorization re-confirmation.

CVSS scoring decision:

• If tester provides CVSS Base Score and full vector string, use it as-is and record source (e.g., "Provided by tester" or "Calculated by [tool]").
• If tester provides only a severity rating without CVSS, ask for CVSS 3.1 Base Score. If tester cannot provide it, prompt for the six required base metrics (AV, AC, PR, UI, S, CIA). If tester still cannot provide metrics, label the score as "Estimated" and calculate a reasonable score based on severity (e.g., Critical = 9.0 to 10.0, High = 7.0 to 8.9, Medium = 4.0 to 6.9, Low = 0.1 to 3.9) with explicit note: "CVSS score estimated by skill pending tester validation." Do not finalize until tester confirms.

PoC evidence decision:

• If tester includes working exploit code, shellcode, or functional attack scripts in PoC evidence, reject and respond: "Working exploits and shellcode cannot be included in client-facing reports. Describe the attack instead and reference screenshot filenames or command output. For example: 'Command execution verified via screenshot evidence-001.png showing shell prompt on target system.'" Ask tester to revise and resubmit PoC summary.

Mitigated/Remediated finding decision:

• If tester indicates a finding is already mitigated or remediated during Phase 4, update Status to "Mitigated" or "Remediated" and ask: "Should this finding remain in the Risk Summary Table and Technical Findings sections, or move to an 'Already Mitigated' appendix?" Default is to keep in main report with status noted.

Out-of-scope observations decision:

• If tester has identified secondary or incidental vulnerabilities on assets outside the authorized scope, create optional "Out-of-Scope Observations" section. Include brief title and severity only. Add disclaimer: "These observations were noted during testing but fall outside the authorized scope. Engagement does not confirm these findings and does not authorize remediation recommendations. Client should decide whether to authorize follow-up testing."

Missing or incomplete finding data decision:

• If tester skips a required finding field (e.g., no remediation recommendation provided), ask: "Finding [title] is missing [field name]. Please provide: [description of field]." Do not proceed to next finding until all required fields are complete.

Report format decision:

• If tester requests a compliance-specific format (SOC 2, ISO 27001, PCI-DSS aligned report), note that this skill produces a generic PTES/OWASP-aligned report. Provide output in requested format (Markdown, PDF, Word) but recommend: "For compliance-specific mappings, provide additional review from your compliance lead before client delivery."

output contract

DRAFT Penetration Test Report document containing:

1. Cover Page: engagement name, client organization, testing dates (start to end), report classification (Confidential), version label (DRAFT v1 [Date]), lead tester name, report generation timestamp.

2. Table of Contents: hyperlinked to all major sections; updates automatically based on report content.

3. Executive Summary (1 to 2 pages, CISO-audience tone): overall risk rating, finding count by severity tier, business context paragraph, top 3 critical/high findings highlighted, security posture statement (1 to 2 sentences).

4. Engagement Overview section:

   • Scope: in-scope assets listed by category (IP ranges, domains, applications, physical locations); out-of-scope assets listed separately.
   • Methodology: summary of testing approach and standards (PTES, OWASP).
   • Testing Window: start date and end date.
   • Rules of Engagement: summary of authorized attack types, working hours, escalation procedures.

5. Risk Summary Table: columnar format with # (row number), Title, Severity, CVSS Score, Affected Asset, Status; sorted by severity (Critical, High, Medium, Low, Informational); one row per finding.

6. Technical Findings section: one numbered subsection per finding containing:

   • Finding title
   • Severity rating (Critical / High / Medium / Low / Informational)
   • CVSS 3.1 Base Score and vector string; labeled "Estimated" if calculated by skill
   • Affected asset(s)
   • Vulnerability description (what it is, root cause)
   • Proof-of-concept evidence summary (screenshot filenames, log excerpts, HTTP artifacts, command output references; no working exploits)
   • Business impact (plain language description of attacker capability)
   • Remediation recommendation (specific, actionable steps)
   • References (CVE, CWE, OWASP category, vendor advisory links)

7. Remediation Roadmap section: three effort tiers presented as tables or lists:

   • Immediate (≤30 days): Critical and High findings with recommended actions and responsible team placeholder
   • Short-term (31 to 90 days): Medium findings with recommended actions and responsible team placeholder
   • Long-term (>90 days): Low and Informational findings with recommended actions and responsible team placeholder

8. Appendices section with stubs A through D:

   • Appendix A: Detailed Scope and Methodology (placeholder for lead tester)
   • Appendix B: Testing Tool List (placeholder)
   • Appendix C: Raw Finding Evidence Log (placeholder for lead tester to attach artifacts)
   • Appendix D: CVSS Scoring Rationale for Critical/High Findings (placeholder with guidance)

9. Lead Tester Review Block (verbatim):

   DRAFT - FOR AUTHORIZED INTERNAL REVIEW ONLY
   Lead Tester Review: _____________________________________ Date: __________
   Reviewer Sign-off:  _____________________________________ Date: __________
   
   This report documents findings from an authorized security engagement.
   Do not distribute without lead tester signature. Drafted with AI assistance;
   human review required before client delivery.
   

10. (Optional) Out-of-Scope Observations section (if applicable): brief list of secondary findings outside authorized scope with disclaimer that client must authorize follow-up.

Format options: Markdown (.md), PDF,