How to Write a High-Scoring Penetration Testing Exam Report (OSCP, PNPT, eJPT & More)

If you’re preparing for a hands-on penetration testing exam like OSCP, PNPT, or eJPT, there is one skill that determines whether you pass or fail, even if you rooted every machine:

🔥 Your ability to write a clear, professional, reproducible penetration testing report.

In the real world, this is what clients judge you on. In exams, this is what graders score you on. A beautiful chain of exploits means nothing if the reviewer can’t reproduce the steps or can’t understand the impact.

This guide walks you through exactly how to write an exam-ready pentest report, using a structure that works for both industry consulting and certification exams.

1. Introduction & Exam Context

If exploitation is the “fun” part of penetration testing, reporting is the skill that pays your salary—and earns you your certification.

In both real-world engagements and exam labs, reporting serves three purposes:

✅ 1. Demonstrate Your Methodology

Exams (especially OSCP) grade you heavily on whether you followed a structured process:

• enumeration

• exploitation

• privilege escalation

• post-exploitation

• documentation

Your report should reflect that professional methodology.

✅ 2. Prove Impact

Exploit alone doesn't matter. You must show:

• “What did this vulnerability let me do?”

• “Why does it matter to the organization?”

• “Could it lead to lateral movement, data exposure, domain takeover?”

✅ 3. Show Reproducible Evidence

Examiners expect:

• clear steps

• commands

• screenshots

• flags or proof files

• remediation recommendations

Even small jumps like “I got root” without proof will lose points.

Exams With High Reporting Weight

• OSCP – report can make or break your score

• PNPT – report + debrief required

• eJPT – more structured but still needs clarity

• CRTO – heavy emphasis on documentation of tradecraft

• GPEN – real-world consulting-style reports

Because the rubrics differ but the structure stays similar, we will use a master skeleton you can adapt to any exam.

2. High-Level Report Structure (Professional Template)

Here is the universal pentest report layout you can use for exams and consulting work.

📌 1. Title Page & Document Control

Include:

• Exam name (OSCP, PNPT, etc.)

• Candidate name + exam ID

• Date of submission

• Version number (“v1.0 Submitted”)

• Confidentiality statement

📌 2. Table of Contents

Auto-generated with page numbers.

This is critical for long reports (OSCP graders appreciate fast navigation).

📌 3. Executive Summary

One or two pages written for managers:

• What was tested?

• What was found?

• How bad was it?

• What should be fixed immediately?

📌 4. Introduction, Scope & Rules of Engagement

Document:

• machines/domains in scope

• flags required

• what you're allowed or not allowed to attack

• exam restrictions (e.g., “no automated exploitation”)

• time window

📌 5. Methodology (Mapped to a Framework)

Structure your workflow using:

• PTES

• NIST

• SANS
  This adds professionalism and earns exam points.

📌 6. Detailed Findings & Exploitation Walkthroughs

The largest portion of the report:

• enumeration

• exploitation

• privilege escalation

• lateral movement

• proof files

Every vulnerability should look like a mini case study.

📌 7. Risk Ratings & Business Impact

Use:

• qualitative ratings (High/Medium/Low)

• CVSS scores when appropriate

• impact expressed in business language

📌 8. Recommendations & Remediation Plan

Clear, specific fixes:

• configs

• patches

• architectural controls

• detection/monitoring guidance

📌 9. Appendices

Everything bulky goes here:

• full nmap outputs

• dirsearch/bruteforce output

• screenshots

• commands

• proof.txt flags

3. Writing the Executive Summary Section

Think of the Executive Summary as a manager reading your report during an Uber ride.

It should be:

• simple

• non-technical

• actionable

• concise (1–2 pages max)

What to Include

1. High-Level Posture

Example:

“During the assessment, 3 High-Risk and 4 Medium-Risk vulnerabilities were identified. Two of these issues enabled full domain compromise.”

2. Main Attack Path

Explain the kill chain like a story:

• foothold on a web server

• privilege escalation

• credential harvesting

• lateral movement

• domain dominance

Keep it human-friendly.

3. Business Impact

Explain risks in real-world terms:

• data theft

• system downtime

• regulatory penalties

• full domain compromise

4. Top 3–5 Priority Actions

A mini action plan:

• Patch vulnerable Apache Struts service

• Implement proper AD password policies

• Disable SMBv1

• Apply least privilege on service accounts

4. Scope, Objectives, and Engagement Details

This section ensures exam reviewers know exactly what you tested.

Include:

1. In-Scope Assets

Example (OSCP style):

• 192.168.171.0/24 network

• 5 Linux machines

• 1 Windows domain controller

• Proof files required per host

2. Out of Scope

Example:

• No DoS attacks

• No brute forcing beyond specified rate limits

• No automated exploitation tools unless allowed

3. Objectives

Examples:

• “Obtain proof.txt and local.txt from each host.”

• “Identify vulnerabilities that lead to privilege escalation.”

• “Demonstrate lateral movement within AD.”

4. Assumptions

Sometimes exams simulate:

• “User clicked a phishing link”

• “Standard user credentials were captured”

• “Default credentials present”

State them transparently.

5. Methodology and Tools

Your methodology proves you performed a professional assessment, not random hacking.

Core Phases

• Reconnaissance

• Enumeration

• Vulnerability mapping

• Exploitation

• Privilege escalation

• Lateral movement

• Post-exploitation

• Cleanup & documentation

Map to Frameworks

Use one:

• PTES

• NIST 800-115

• SANS Penetration Testing Methodology

This earns points in OSCP/PNPT and looks extremely professional.

Tooling Explanation

You don’t need a giant list of tools. Instead:

• name the tool

• explain why you used it

• note manual verification

Example:

“Nmap was used for initial port discovery and service fingerprinting. All results were manually validated before attempting exploitation.”

This shows examiners you know what you’re doing.

6. Technical Findings & Exploitation Walkthroughs

This is the heart of the report — the part that determines your score.

Each finding should follow this structure:

Finding Structure

1. Title & ID

Example:
WEB-01: SQL Injection in Login Form

2. Description

Explain the vulnerability in human language.

3. Affected Assets

• IP

• hostname

• URL

• parameters

4. Risk Rating + CVSS

Qualitative + CVSS score if appropriate.

5. Proof of Concept (PoC)

Include:

• commands

• payloads

• screenshots

Write it as if someone else must reproduce it using only your instructions.

6. Impact

Tie the exploit to business consequences:

• data breach

• privilege escalation

• domain compromise

7. Evidence

Include:

• screenshots

• truncated output

• flags

• key command snippets

Exam-Specific Advice for Findings

✔ Reproducibility Is Everything

For OSCP/PNPT graders:

• every enumeration step matters

• every exploit chain must be documented

• do NOT skip steps

If you can't reproduce it, they won't believe it.

✔ Avoid “Magic Jumps”

Write:
❌ “I got a shell.”
✅ “Uploaded webshell → executed netcat reverse shell → gained foothold as www-data.”

✔ Show Key Enumeration Output

Show:

• misconfigurations

• privilege escalation hints

• accessible shares

• kernel versions

Examiners want to see you followed a professional workflow.

7. Risk Ratings & Business Impact

Risk ratings shouldn’t just be “High/Medium/Low.”
Explain why.

Use at least two dimensions:

• Likelihood (ease of exploitation)

• Impact (damage if exploited)

Examples

“This SQL injection can be exploited with no authentication, making likelihood high.”
“Successful exploitation exposes all customer records stored in the CRM database.”

This shows maturity and real consulting skill.

8. Recommendations & Remediation

Remediation is graded in many exams.

Write:

• Clear

• Specific

• Prioritized

• Actionable

Format

• Short-Term Fixes (patching, config changes)

• Long-Term Fixes (network segmentation, hardening)

Example:

“Implement parameterized SQL queries to eliminate SQL injection. Validate all input server-side.”

Bonus:

• reference CIS benchmarks

• link vendor advisories

9. Appendices: Evidence & Artifacts

This is where all the “noise” goes so your main report stays readable.

Include:

• full nmap scans

• gobuster/dirsearch output

• exploit scripts

• command history

• screenshots not used in the main section

• proof.txt and local.txt flags

Cleanup Section

Document:

• users created

• files uploaded

• scheduled tasks created

• system changes

On OSCP: documenting cleanup is essential.

10. Writing Style & Formatting Best Practices

Your writing should be:

• clear

• simple

• professional

Tips

✔ Use active voice
✔ Use consistent headings
✔ Use tables for assets and vulnerabilities
✔ Use code blocks for commands
✔ Redact sensitive data
✔ Keep screenshots sharp and cropped
✔ Number your findings

Example asset table:

11. Exam-Specific Tips & Common Pitfalls

Here are the most common reasons students fail:

❌ Missing proof files

❌ Missing steps in exploitation chains

❌ Missing or blurry screenshots

❌ No privilege escalation explanation

❌ No remediation suggestions

❌ Commands not shown

❌ Enumeration not documented

✔ Use a prebuilt template

Prepare your report structure before the exam.

✔ Take notes in real-time

Tools:

• Obsidian

• CherryTree

• OneNote

• Notion

• Typora

✔ Screenshot everything

If you think “should I screenshot this?” — yes, you should.

✔ Track timestamps

Examiners appreciate clear chronological flow.

12. Suggested Overview Table