Overview
This room focuses on the final deliverable of an engagement: the report. The core message is simple and important: if it is not documented clearly, it effectively did not happen. Good reporting has to explain what was tested, what was found, why it matters, and what the client should do next.
Core idea: a pentest report must work for multiple audiences at once. Business stakeholders need impact, security stakeholders need prioritisation, and technical stakeholders need enough detail to reproduce and remediate the issue correctly.
1) Why Reporting Matters
Tool output, screenshots, and shells are temporary. The report is the durable product that remains after the engagement ends.
- It records the scope, findings, and overall security posture at a fixed point in time.
- It drives remediation and risk decisions after the test is over.
- It becomes historical evidence for retesting, audits, and future assessments.
- Poor reporting can cause good technical work to be ignored or misunderstood.
2) Know the Audience
The room breaks reporting audiences into three groups, each with different needs.
- Technical stakeholders: developers, administrators, or engineers who must reproduce and fix the issue. Most of the report is aimed here.
- Security stakeholders: teams who need to understand risk themes, remediation priority, and whether findings combine into larger attack paths.
- Business stakeholders: non-technical decision-makers who need the business impact and the urgency in plain language.
A good report changes its level of abstraction without changing the underlying facts.
3) Core Report Structure
The room frames a strong pentest report around three main sections:
- Summary: high-level explanation of scope, results, impact, and next steps.
- Vulnerability write-ups: detailed technical findings with evidence and remediation guidance.
- Appendices: supporting material such as achieved coverage, methodology notes, and any artefacts left behind.
Practical rule: structure matters because different readers jump to different sections. If the report is not easy to navigate, action slows down.
4) Writing the Summary Properly
The summary should usually be written last, once the rest of the report is complete.
- Overview: what was tested, what type of system it was, and what coverage was achieved.
- Results: what categories of weaknesses were found and whether the system was generally secure.
- Impact: what a real attacker could do if the issues remain unresolved.
- Remediation direction: high-level next steps and whether the fixes are tactical or systemic.
When needed, this can be split into an executive summary for business readers and a findings-and-recommendations summary for security stakeholders.
5) What Makes a Strong Vulnerability Write-Up
This is the technical core of the report. Each finding should stand on its own and be actionable.
- Title and risk rating: say what the issue is and how severe it is.
- Summary and background: explain the vulnerability and why it matters.
- Technical details and evidence: include the exact location, conditions, and proof needed to reproduce it.
- Impact: explain the concrete consequence in the client’s environment.
- Remediation advice: provide client-relevant fixes, not vague generic guidance.
- References: link to authoritative supporting material where useful.
6) Precision Over Generic Advice
One of the most useful points in the room is that remediation should be tailored to the client’s stack and context.
- Do not stop at “sanitize input” or “validate data.”
- If the application stack is known, give examples that fit it.
- State assumptions clearly, such as whether credentials or a specific role are required.
- Describe the exact endpoint, parameter, or workflow involved.
Specific remediation reduces ambiguity and makes it much more likely that the issue is fixed correctly the first time.
7) Appendices That Matter
The appendices act as the audit trail for the engagement.
- Assessment scope: document what was actually covered and where coverage was partial or blocked.
- Assessment artefacts: record any uploaded files, test accounts, shells, or other remnants that may need cleanup.
This is important because residual testing artefacts can later be mistaken for a real incident if they are not documented.
8) Writing Style and QA
The room emphasizes that strong reporting is also an editing discipline.
- Write clearly and directly.
- Use a professional, objective tone.
- Stay consistent in terminology, formatting, and naming.
- Write in past tense and avoid first-person language.
- Mask passwords and other sensitive data unless disclosure is explicitly authorised.
- Perform self-review and peer review before delivery.
QA is not just spell-checking: it is a check for accuracy, consistency, professionalism, and whether the report is actually actionable for the client.
9) TryHackMe Exam-Ready Report Template
Based on the room, this is the cleanest structure to mirror what TryHackMe expects for a professional PT1-style report.
Use this as the default model: summary first, then one consistent write-up per finding, then appendices for scope and artefacts.
Report Title
Client / Application / Assessment Name
Assessment Dates
Tester
1. Summary
Overview:
- What was tested
- Type of application or environment
- Goals of the assessment
- Scope and coverage achieved
Results:
- Overall security posture
- Main categories of findings
- Whether the application/environment was mostly secure or materially exposed
Impact:
- Realistic business and security impact
- What an attacker could achieve if issues remain unresolved
Remediation Direction:
- Immediate next steps
- Whether fixes are quick wins or require broader engineering effort
Optional split when needed:
- Executive Summary
- Findings & Recommendations
2. Vulnerability Write-Up Template
Title:
Risk Rating:
Summary:
Background:
Technical Details & Evidence:
Impact:
Remediation Advice:
References:
3. Appendices
Assessment Scope:
- Original scope
- Actual coverage achieved
- Gaps, blockers, or deviations
Assessment Artefacts:
- Accounts created
- Files uploaded
- Shells, payloads, tools, or persistence left behind
- Cleanup actions required
4. QA Checks Before Delivery
- Clear and professional tone
- Past tense
- No first-person wording
- Sensitive data masked
- Consistent terminology and formatting
- Findings are reproducible and remediation is actionable
- Self-review completed
- Peer review completed
This matches the room’s actual emphasis: audience-aware summary, a repeatable finding structure, and appendices that document scope and residual artefacts.
10) Practical Reporting Checklist
- Make sure every finding answers where, how, impact, and fix.
- Keep business impact separate from exploit detail when needed.
- Ensure screenshots and snippets support the finding instead of replacing explanation.
- Check that remediation advice matches the client environment.
- Verify that scope limitations and leftover artefacts are documented.
- Run a full QA pass before the report is considered complete.
Exam Notes (PT1)
- A pentest report must serve business, security, and technical audiences at the same time.
- The three core report sections are the summary, vulnerability write-ups, and appendices.
- For TryHackMe-style reporting, the safest structure is Summary - Finding Write-Ups - Appendices - QA.
- The summary should explain scope, results, impact, and next steps in language appropriate to the reader.
- Strong finding write-ups need precise evidence, clear impact, and remediation advice tailored to the actual stack.
- Appendices should capture scope gaps and any testing artefacts left behind.
- Use clear, formal, objective language; write in past tense; avoid first-person phrasing; and always perform QA.