Skip to content
Lesson 8 of 8

Reporting and Remediation

9 min read

The Report Is the Final Product

No matter how impressive your technical skills are, the client receives only one tangible thing: the report. It is the deliverable that justifies the engagement, communicates the risk, and guides remediation. A brilliant pentest with a poor report delivers little value; a solid pentest with an excellent report transforms the organization's security posture. That is why writing well is as important as hacking well.

The report must serve multiple audiences. Management needs to understand the business risk without technical jargon; technical teams need enough detail to reproduce and fix each finding. Balancing both levels of detail is the art of professional reporting, and it is usually resolved with a layered structure.

A good report is also timeless: someone who reads it months later, without having participated in the engagement, should be able to understand what was found, why it matters, and how to solve it. Clarity and completeness are your central goals.

Ethical framing: the report contains the client's weaknesses. Deliver it over encrypted channels, limit its distribution, and mask sensitive data in the evidence.

Structure of a Professional Report

A well-built pentest report usually includes several sections, and each one has a distinct audience. The executive summary condenses the key findings, the overall risk level, and the priority recommendations in language accessible to management. It should not contain unnecessary technical jargon; its audience makes investment decisions, not configuration ones, and it is often the only section executives read.

The scope and methodology section documents what was tested, when, with what approach, and under what rules of engagement. This contextualizes the findings, demonstrates rigor, and delimits responsibilities: whatever fell out of scope was not evaluated. Its natural audience is the project's technical owner and any auditor reviewing the work.

Then comes the technical body: the detailed findings, each with its description, severity, evidence, impact, and remediation. This section is consumed by the IT and development teams that will fix the issues. Finally, the appendices gather raw data, scan listings, extended methodology, or supporting information; they serve as a reference for anyone who wants to reproduce or audit the fine detail.

This layered structure lets each reader access the level of detail they need. Management reads the executive summary; the IT team digs into the findings; the auditor turns to the appendices. A clear table of contents and consistent numbering make it easy to navigate a document that can be extensive.

Severity Classification and CVSS

Each finding must carry a clear severity that communicates its urgency. The usual categories are critical, high, medium, low, and informational. Severity should be based on a combination of likelihood of exploitation and potential impact, ideally backed by a CVSS v3.1 score that gives consistency and objectivity to the classification.

CVSS breaks risk down into metrics: the Base group describes the intrinsic characteristics of the vulnerability, and it is expressed as a readable vector. For example, a remote injection with no authentication and full impact usually looks like this:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That vector reads as network attack vector (AV:N), low complexity (AC:L), no privileges (PR:N) or user interaction (UI:N), with high impact on confidentiality, integrity, and availability (C:H/I:H/A:H), yielding a base score of 9.8 — critical. Beyond the Base group, CVSS offers Temporal metrics (exploit maturity, patch availability) and Environmental metrics, which let you reweight the score according to the client's context.

It is important that severity reflects that real context, not just the generic score. A critical vulnerability on an isolated system with no sensitive data may deserve a severity adjusted downward through the environmental metrics, while a medium flaw on an exposed system that processes customer data may be raised. Explaining the reasoning behind each severity — and publishing the CVSS vector alongside the score — adds transparency and credibility.

Consistent severity lets the client prioritize their remediation effort rationally. If everything is marked critical, nothing is critical; the honest calibration of severity is part of your professionalism and of the value you deliver.

Reusable Finding Template

A uniform format for each finding improves readability and keeps you from missing information. Reuse this template as a starting point and adapt it to the client. It is a report template, not an attack: it describes how to document, in a structured way, what you found during an authorized engagement.

### [ID: PT-2026-001] Short, descriptive finding title

- **Severity:** Critical
- **CVSS v3.1:** 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
- **Affected asset:** app.client.com (10.0.4.12), endpoint /api/v1/login

**Description**
What the vulnerability is, which component it lives in, and why it exists.
Explain the root cause, not just the symptom.

**Impact**
What an attacker can achieve if they exploit it, in business terms:
data access, account compromise, service disruption.

**Reproduction steps**
1. Send a request to the affected endpoint with parameter X.
2. Observe response Y.
3. Confirm condition Z that demonstrates the weakness.

**Evidence**
Screenshot, output snippet, or request/response that demonstrates it.
Mask credentials and personal data before including them.

**Remediation**
Concrete, actionable step, with a temporary mitigation if applicable.
E.g.: update component X to version Y; validate parameter Z.

**References**
- OWASP WSTG / ASVS: corresponding identifier
- CWE-XXX, vendor advisory, related CIS Benchmark

A stable ID lets you reference the finding in the debrief, the retest, and the follow-up. Keep the fields consistent across every finding so the client learns to read them at a glance.

Clear and Reproducible Evidence

Each finding needs evidence to support it: screenshots, command output snippets, requests and responses, or proofs of concept. Evidence transforms a claim ("this system is vulnerable") into a verifiable fact. Without it, the client cannot confirm the problem or convince their own teams to act.

Evidence must be reproducible: include enough steps so the client's technical team can confirm the finding themselves. At the same time, protect sensitive data. If a screenshot shows credentials or personal information, redact or mask what is necessary so as not to expose data in a document that will circulate through the organization.

Keep evidence proportional. You do not need to dump megabytes of raw output; what demonstrates the point unambiguously is enough. Well-chosen evidence is more persuasive than an overwhelming appendix that no one will read.

Remediation Recommendations by Standard

The most valuable part of each finding is the remediation recommendation. Finding problems is useful; explaining how to solve them is what justifies the engagement. Each recommendation must be specific, actionable, and realistic for the client's environment. "Patch the system" is vague; "update component X to version Y, or apply mitigation Z in the meantime" is actionable.

Linking each recommendation to a recognized standard reinforces its authority and makes it easier for the client to implement. These are the frameworks worth citing and how to map them:

  • OWASP — for web application findings, reference the WSTG testing guide (verification methodology) and the ASVS standard (security requirements by level). E.g.: "the finding fails ASVS V2.1 on authentication".
  • CIS Benchmarks — for operating system, service, and cloud configurations, point to the specific control in the product's benchmark (Linux, Windows, Kubernetes, etc.).
  • NIST — for organizational and management controls, cite SP 800-53 or the Cybersecurity Framework when the finding points to a process, not a technical setting.
  • Vendor recommendations — link the security advisory, hardening guide, or patch bulletin from the vendor of the affected component.

By associating each recommendation with a concrete standard identifier (control number, section, or CWE), you give the client a verifiable, traceable anchor instead of a loose opinion.

Good recommendations consider the operational context. Sometimes the ideal solution is not immediately feasible, so it is wise to offer temporary mitigations in addition to the definitive fix. When possible, group recommendations that address common root causes: if several findings stem from poor patch management or a lack of network segmentation, pointing out the systemic problem adds more value than treating each symptom separately. Think about improving the security posture, not just plugging holes.

Closing, Secure Delivery, and Retesting

The report is delivered securely, since it contains sensitive information about the client's weaknesses. Encrypting the document, using protected channels, and limiting its distribution to those who need to know are standard practices. Define a tight recipient list, apply end-to-end encryption or at least out-of-band password protection, and avoid emailing the report unprotected. The confidentiality of the deliverable is part of the contract, not an optional detail.

The debrief closes the communication phase: it is a meeting where you walk through the key findings with the client, answer questions, and help prioritize. Its mechanics combine a review of the executive summary with management and a deeper technical session with the teams that will remediate. A good debrief ensures the message is understood and that owners and deadlines are agreed for each action.

The value of the pentest materializes in the follow-up. Many engagements include a subsequent retest phase to verify that remediations were applied correctly. Retesting each finding by its ID and documenting its state — remediated, mitigated, or pending — closes the loop and demonstrates tangible progress. Thus, the report stops being a static document and becomes the engine of a real and measurable improvement in security.

Report Quality Closing Checklist

Before delivering the report, verify that it meets these criteria:

  • Clarity: each section addresses its audience and avoids unnecessary jargon in the executive summary.
  • Reproducible evidence: each finding includes steps the client can follow to confirm it on their own.
  • Calibrated severity: severities reflect the real context, with the CVSS score and vector published and justified.
  • Actionable remediation: each recommendation is specific, feasible, and linked to a recognized standard.
  • Protected data: credentials and personal information are masked throughout the evidence.
  • Secure delivery: the document is encrypted, sent over a protected channel, and its distribution is limited.
  • Defined follow-up: there is a retest plan and a mechanism to document the state of each finding.