Reporting & Professional Practice · beginner · ~11 min
By the end of this lesson you will be able to: - Lay out a professional penetration test report using the standard sections in the right order. - Write the same engagement for two audiences at once — an executive summary for leadership and a technical body for engineers. - Choose what belongs in the report versus the appendices, and what must never appear in it at all. - Apply the four guiding principles — impact-first, actionable, accurate, reproducible — to every section you write. - Handle report data safely: mark it confidential, redact secrets, and follow secure handling and retention.
Security objective: the asset you protect in this lesson is the report itself — a document that concentrates every weakness of the client's systems in one place. The report is the deliverable: it is the thing the client actually receives, pays for, and acts on. The test only creates knowledge; the report is how that knowledge becomes fixes. A brilliant test written up badly delivers almost nothing.
This builds directly on your prerequisite, The phases of an engagement (methodology-phases). There you learned that reporting is the final phase, after scoping, discovery, exploitation, and post-exploitation. This lesson zooms into that phase and asks: once the testing is done, how do you structure the write-up so it is credible, usable, and safe?
A good report serves two audiences at once:
The standard sections, in order, are: executive summary, scope, methodology, findings (ordered by severity), remediation roadmap, and appendices. Throughout, you lead with impact, stay honest, keep every recommendation actionable, and make every finding reproducible.
One more thing this lesson protects: the confidentiality of the report as a data object. A pentest report is a roadmap to compromise. If it leaks, it hands an attacker a pre-written attack plan. So structure is not only about clarity — it is also about handling the document securely.
In authorized professional work, clients act on the report, not on the test. Whoever signed the contract rarely watched you work; the PDF you hand over is the entire visible product of weeks of effort.
A clear, well-structured report is what turns findings into fixes. If the executive summary is muddy, leadership will not fund remediation. If the technical body is not reproducible, the engineering team cannot confirm or close a finding, and it lingers unfixed. If severities are inflated or evidence is sloppy, you lose credibility and the client discounts everything else you wrote.
Writing for both executives and engineers — impact-first, accurate, reproducible, and actionable — is one of the most valued and most differentiating skills a penetration tester has. Two testers can find the exact same bug; the one who reports it clearly is the one who gets rehired. Report quality is also what auditors, insurers, and regulators inspect when they ask a company to prove it tested its systems.
Definition. The report is the formal written deliverable that documents scope, method, findings, and remediation for an engagement.
Plain explanation. The client is not paying for the excitement of the test. They are paying for a document they can act on, share with auditors, and use to drive fixes. The write-up — not the testing activity — is the thing that has value after you leave.
How it works. Everything you did during the engagement gets distilled into a structured document with a predictable shape, so any reader knows where to look.
When / when not. Always produce a report for a paid or formal engagement. For an informal internal check you may use a lightweight ticket instead — but the same discipline (impact, evidence, fix) still applies.
Pitfall. Treating the report as an afterthought written the night before delivery. Good testers take notes and screenshots as they go, so the report writes itself.
Definition. A single report deliberately written in two styles for two readers.
Plain explanation. An executive wants to know "how bad is it and what will it cost me"; an engineer wants to know "exactly what is broken and how do I fix it." One document must answer both without making either reader wade through the other's section.
Pitfall. Writing the executive summary in engineer-speak ("unauthenticated IDOR on /api/v2/orders"). Executives stop reading. Translate to impact: "any logged-in user could view other customers' orders."
| # | Section | Audience | Purpose |
|---|---|---|---|
| 1 | Executive summary | Leadership | Business-level overview, top risks, posture |
| 2 | Scope | Both | Exactly what was tested (assets, dates) and what was not |
| 3 | Methodology | Both | How you tested; standards followed |
| 4 | Findings | Engineers | Detailed issues, ordered by severity |
| 5 | Remediation roadmap | Both | Prioritized, actionable fixes |
| 6 | Appendices | Engineers | Tooling, raw evidence, out-of-scope notes |
Scope protects both sides legally and technically: it states the authorized targets and the test window so no one can claim you touched something you were not allowed to. Methodology cites recognized standards — the OWASP Web Security Testing Guide (WSTG) or the Penetration Testing Execution Standard (PTES) — which makes results credible and repeatable.
A pentest report is a concentrated map of how to break in. Treat it as confidential: mark every page, redact live secrets, control who receives it, and agree retention up front. Structure and safety go together.
THREAT MODEL — the report as a protected asset
ASSET: the penetration test report
(contains: findings, reproduction steps, evidence,
sometimes screenshots with tokens/PII)
+-------------------- TRUST BOUNDARY --------------------+
| TESTER SIDE (authorized) |
| |
| [Engagement notes] --> [Draft report] --> [Final] |
| | | | |
| encrypted disk encrypted disk signed PDF |
+--------------------------|-----------------------------+
| secure delivery
v (entry point: how it is shared)
+-------------------- TRUST BOUNDARY --------------------+
| CLIENT SIDE (authorized recipients only) |
| named stakeholders -> remediation teams |
+--------------------------------------------------------+
ENTRY POINTS an attacker would target:
- email attachment sent to the wrong address
- unencrypted file share / public bucket
- a laptop with the draft, lost or stolen
- screenshots that still contain live tokens or PANs
Knowledge check.
There is no programming syntax here; the "syntax" of a report is its section skeleton and its per-finding template. Lock these in and every report you write becomes consistent and reviewable.
A lab-safe report skeleton in Markdown:
# Penetration Test Report — <Client> <Engagement>
> CONFIDENTIAL — authorized recipients only. Do not redistribute.
## 1. Executive Summary <!-- 1 page, plain language, impact-first -->
## 2. Scope <!-- assets tested + explicitly NOT tested + dates -->
## 3. Methodology <!-- approach + standards: OWASP WSTG / PTES -->
## 4. Findings <!-- ordered by severity, one block each -->
## 5. Remediation Roadmap <!-- prioritized, actionable -->
## Appendix A. Tooling & Evidence
The per-finding block that lives under section 4 (you will go deep on severity in the next lesson):
### F-01 <Title> — Severity: <Critical/High/Medium/Low/Info>
- Affected component: <asset / endpoint>
- Preconditions: <access needed to reproduce>
- Reproduction: <numbered, lab-safe steps>
- Evidence: <redacted screenshot / log excerpt>
- Impact: <business consequence>
- Likelihood: <how easy to exploit>
- Remediation: <concrete fix>
- Retest: <how to verify the fix works>
Note the two guardrails baked into the syntax: a confidentiality banner on line 2, and a Retest line on every finding so remediation can be verified rather than assumed.
The report is the product.
A brilliant test that is reported badly delivers little value. A clear report is what the client pays for and acts on.
The platform's build-markdown-report exercises cover the C side of assembling a report programmatically. This track focuses on what goes inside it.
Below is a complete, self-contained example: the same finding written badly, then rewritten to standard, then a verification checklist that proves the rewrite is adequate. This is documentation, not exploit code — every value is a placeholder for a local lab.
This is a bad report entry for a finding discovered on a deliberately vulnerable app running on localhost in a container. It is what NOT to write:
### Found SQL injection lol
Ran sqlmap against the login and it's totally hacked. Super critical.
Everything is vulnerable. Payload: ' OR '1'='1
Proof: see my screenshot (has the admin session cookie in it).
Why this is dangerous as a report: no scope reference, no reproduction steps an engineer can follow, an inflated blanket severity, no fix, no retest, and — worst — it pastes a live session cookie into the evidence, turning the report itself into a credential leak.
### F-01 Authentication bypass via SQL injection on login — Severity: High
- Affected component: `POST /login` on the lab app (localhost:8080, container `dvwa-lab`)
- Preconditions: Network access to the login form. No valid account required.
- Reproduction (lab only):
1. Send a login request with the email field set to a value that
terminates the SQL string early (a single quote followed by an
always-true clause). The exact payload is recorded in Appendix A.
2. Observe that the application returns an authenticated session
without valid credentials.
- Evidence: Appendix A, redacted. Response body and headers included;
the session token is masked as `Set-Cookie: session=<REDACTED>`.
- Impact: An unauthenticated attacker can log in as an existing user
and read that user's records. On this lab the affected table
is `users` (test data only).
- Likelihood: High — reachable pre-auth, no special tooling required.
- Remediation: Use parameterized queries / prepared statements so input
is never concatenated into SQL. Example (pseudo-SQL):
db.query("SELECT * FROM users WHERE email = ?", [email])
Add server-side input validation and least-privilege DB
credentials as defense in depth.
- Retest: Re-send the same request after the fix; the app must reject
the input and return an authentication failure, while a
valid credential must still succeed.
Run this checklist over every finding before delivery. It rejects the bad entry and accepts the good one:
[ ] Has a stable ID and a plain-language title? bad: FAIL good: PASS
[ ] Severity justified by impact + likelihood (not blanket)? bad: FAIL good: PASS
[ ] Reproduction steps another tester could follow? bad: FAIL good: PASS
[ ] Evidence contains NO live secret/token/PAN/PII? bad: FAIL good: PASS
[ ] Concrete remediation an engineer can implement? bad: FAIL good: PASS
[ ] Retest step that ACCEPTS good input, REJECTS bad? bad: FAIL good: PASS
[ ] Ties back to a scoped, authorized asset? bad: FAIL good: PASS
Expected result: the bad entry fails on all seven lines; the standard entry passes all seven. That contrast is the whole lesson: same bug, wildly different value and safety depending on how it is written.
Walking through the SECURE finding block, field by field, and why each earns its place:
| Field | What it does | Why it matters |
|---|---|---|
F-01 + title |
Gives the finding a stable handle and a one-line plain-language summary | Lets the client track "is F-01 fixed?" across emails and retests; the title alone tells an executive what broke |
| Affected component | Names the exact scoped asset (localhost:8080, container name) |
Proves the finding is inside authorized scope and points engineers at the right code |
| Preconditions | States the access needed to reproduce ("no valid account") | Directly feeds likelihood and severity — a pre-auth bug is worse than one needing admin |
| Reproduction | Numbered steps; the raw payload is pushed to the appendix | Reproducibility is the credibility test; keeping the payload in an appendix keeps the body readable and lets you redact centrally |
| Evidence | Points to appendix, token shown as <REDACTED> |
Proof the issue is real, without turning the report into a live credential leak |
| Impact | Translates the bug into a business consequence, naming the data at risk | This is the sentence the executive summary is built from |
| Likelihood | How easy the bug is to trigger | Combined with impact, it justifies the severity rating (next lesson) |
| Remediation | A concrete, implementable fix (parameterized queries) plus defense in depth | Turns a finding into a work ticket; "be more secure" is not a fix |
| Retest | Exactly how to confirm the fix — reject bad input, accept good input | Closes the loop: without it, no one can prove the issue is actually resolved |
How the value "flows" up the document: the Impact line of each finding is summarized (de-jargoned) into the Executive Summary; the Severity of each finding determines its order in section 4; the Remediation lines are collected and prioritized into section 5's roadmap. So a well-written finding block is the atom from which the whole report is assembled — write the blocks well and the summary and roadmap almost fall out for free.
Real mistakes testers make when structuring reports:
1. Everything is Critical.
2. Leading with tools instead of impact.
3. Findings that cannot be reproduced.
4. Leaking secrets in evidence.
<REDACTED>), mask PANs, crop PII, use development placeholders.5. Confusing "scanner passed" with "secure."
6. No retest / verification path.
"Debugging" a report means catching structural and safety defects before the client does.
Common problems and how to chase them down:
Questions to ask when a report "fails":
Security & safety — handling, detection, and logging for the report itself.
The report is a high-value document. Handle it like the sensitive asset it is, and keep an audit trail around it.
What to LOG around a report's lifecycle (so misuse is detectable):
What to NEVER put in the report or its logs:
API_KEY=<development-placeholder>.Events that signal abuse / a problem:
How false positives arise: a legitimate reviewer or the client's own remediation team accessing the report can look like unexpected access; a security tool scanning attachments can trip forwarding alerts. Confirm against the agreed recipient list before treating access as an incident, and record the resolution.
Handling checklist: store drafts on encrypted disk; mark every page CONFIDENTIAL; deliver over an encrypted channel to named recipients only; agree a retention/destruction date up front and follow it.
Authorized real-world use case. A SaaS company hires a firm for an annual web application penetration test to satisfy a SOC 2 / customer security review. Everything happens under a signed statement of work against explicitly scoped, authorized systems. The deliverable is a report whose executive summary the CISO forwards to the board, whose findings the engineering team turns into Jira tickets, and whose remediation roadmap sets the fix priority for the next quarter. Months later the same report — and its retest section — is what an auditor inspects as evidence the company tests and fixes its systems.
Professional best-practice habits:
Beginner vs advanced:
| Beginner | Advanced | |
|---|---|---|
| Structure | Follows the six-section template | Tailors sections to the client's compliance context (PCI, SOC 2) |
| Findings | One clear finding block each | Chains related low findings into a higher-impact attack narrative |
| Severity | Impact + likelihood, plain | Full CVSS with environmental scoring, justified |
| Summary | Plain-language paragraph | Board-ready risk narrative tied to business objectives |
| Retest | States how to verify | Delivers a formal retest report closing each finding |
All tasks are documentation exercises. Any testing they reference is lab-only — localhost, containers, or intentionally vulnerable VMs you own or are explicitly authorized to test. Each security task ends defensively: remediate and verify.
Authorization checklist (before any lab work): (1) You own or have written authorization for the target. (2) It runs isolated on localhost/container/VM. (3) You have a rollback/reset plan. (4) No third-party or production system is involved.
Beginner 1 — Build the skeleton.
.md file.Beginner 2 — Translate for executives.
Intermediate 1 — Redaction pass.
<REDACTED> and <development-placeholder>; invent no real secrets.Intermediate 2 — Write one standard finding with a retest.
Challenge — Review-and-repair.