# Penetration Test Report

**Client:** [Client / organization name]
**Prepared by:** [Tester or firm name]
**Report date:** [YYYY-MM-DD]

---

## Tester Identity & Credentials

> Name the individual or firm who performed the testing, their relevant certifications
> (for example OSCP, OSCE, CISSP, GIAC), and a short statement confirming they are
> independent from the team that built or operates the tested system.

- Tester / firm: [name]
- Certifications: [list]
- Independence statement: [one or two sentences]

## Testing Dates

> State the exact start and end dates the testing activity was performed. This is
> distinct from the report publication date above.

- Testing start: [YYYY-MM-DD]
- Testing end: [YYYY-MM-DD]

## Testing Type

> State how much internal knowledge or access the tester had.

- [ ] Black-box (no internal knowledge of the target)
- [ ] Grey-box (partial access, e.g. a standard user account)
- [ ] White-box (source code and internal documentation provided)

## Executive Summary

> Summarize the engagement in business terms for a non-technical reader: what was
> tested, the overall risk posture, and the headline findings. Avoid technical
> jargon here; save the detail for the Findings section below.

[2-4 paragraphs]

## Scope

> List the exact assets tested: domains, IP ranges, applications, APIs, mobile apps,
> and anything explicitly excluded from testing.

**In scope:**

- [asset 1]
- [asset 2]

**Out of scope:**

- [exclusion 1]

## Rules of Engagement

> Document the agreed boundaries for the test: allowed and disallowed techniques,
> testing windows, exclusions, and emergency-contact or escalation procedures.

- Testing windows: [e.g. business hours only, 24/7]
- Disallowed techniques: [e.g. denial-of-service, social engineering]
- Emergency contact: [name / phone / email]

## Methodology

> Describe the approach and techniques used: reconnaissance, vulnerability analysis,
> exploitation attempts, and any standard or framework the engagement was structured
> around (for example PTES or the OWASP Testing Guide).

[Describe phases and techniques]

## Findings

> List each vulnerability found, ordered from critical to informational severity.
> Each finding should include a CVSS score and vector, a description, affected
> assets, and proof-of-concept evidence showing the issue is real and reproducible.

### [Finding title] - [Critical / High / Medium / Low / Info]

- **CVSS score / vector:** [e.g. 9.1 / CVSS:3.1/AV:N/AC:L/...]
- **Affected asset(s):** [asset]
- **Description:** [what the issue is and why it is exploitable]
- **Proof of concept:** [request/response, screenshot reference, or reproduction steps]

_(Repeat this block for each finding, in severity order.)_

## Remediation Guidance

> For each finding, give concrete, actionable steps to fix it, written for the
> engineers who will implement the fix.

### [Finding title]

- **Recommended fix:** [specific steps]
- **Priority:** [Critical / High / Medium / Low]

## Retest / Verification

> Provide the exact steps or commands to re-run each check after a fix is applied,
> so the fix can be confirmed rather than assumed.

- [Finding title]: [retest command or steps]

## Attestation

> A signed statement confirming that testing occurred, summarizing scope and
> dates, and identifying the tester. Often shared separately from the full report.

I/We attest that the penetration test described in this report was performed
against the scope defined above, during the testing dates stated above, using
the methodology described above.

Signed: [signature]
Name: [tester name]
Date: [YYYY-MM-DD]

## Appendices

> Supporting technical detail that would clutter the main report: raw tool
> output, full request/response logs, an asset inventory, or a glossary of terms.

- Appendix A: [raw tool output]
- Appendix B: [asset inventory]
- Appendix C: [glossary]

---

_Template provided by TurboPentest._