Reporting, Evidence Handling and Remediation Guidance
Reporting
Two audiences, one document
A penetration test report has an executive layer and a technical layer, and questions frequently probe the difference. The executive summary states overall risk posture, the most material themes, and business consequences in plain language - no CVE identifiers, no payloads. The technical body carries the reproducible detail.
Anatomy of a finding
Each finding should contain: a descriptive title, severity with the scoring rationale, affected assets, a clear description of the weakness and its root cause, reproduction steps precise enough for an administrator who was not present, captured evidence, realistic business impact, a specific remediation recommendation, and references. Deduplicate the same weakness across many hosts into one finding with an affected-asset list.
Quality control
Score consistently across findings; a report where severity ordering contradicts the executive summary destroys credibility. Separate technical severity from business risk. Remove unsupported claims, vague language, and anything you did not personally verify. Include scope, methodology, limitations, and testing dates so the reader knows what was and was not covered.
Traps in exam questions
- Severity inflation to impress the client, which undermines the whole report.
- Findings with no reproduction path or no remediation.
- Screenshots with no hostname, timestamp, or surrounding context.
- Mixing testing limitations into a footnote rather than declaring them explicitly.
- Reporting an observation as a vulnerability.
Rule of thumb
Write every finding so that a system administrator who was not on the engagement can reproduce it unaided. If they cannot, the finding is incomplete regardless of how good the evidence is.
Evidence Handling and Remediation Guidance
Evidence integrity
Evidence must be attributable, unaltered, and retained per the contract. Practical controls: record hostname, source IP, timestamp and tester identity in every capture; save raw tool output alongside screenshots; hash exported evidence sets (SHA-256) and record the hash; store evidence encrypted at rest and transfer it over secure channels; and maintain a chain-of-custody record for anything that leaves your environment. Collect only what you need - pulling whole databases or user mailboxes creates privacy exposure with no reporting benefit. Redact credentials, tokens, personal data and customer records in the delivered report, retaining the unredacted originals in the secured evidence store.
Remediation guidance
Good remediation is specific, prioritised, and verifiable. It addresses root cause, not just the symptom: "apply the vendor patch and add a regression test to the monthly cycle," not "patch the server." Where a full fix is slow, propose compensating controls (network segmentation, WAF rule, monitoring alert) and state their residual risk. Define retest criteria so the client knows what "fixed" will look like, and offer defence-in-depth where one control failure would re-open the path.
Traps in exam questions
- Pasting live credentials, password hashes, or full personal records into the report body.
- Deleting evidence at engagement close without documented destruction and client confirmation.
- Recommending only a point fix that leaves the vulnerable pattern in place elsewhere.
- Remediation advice that contradicts the discovered architecture (blocking a port the business depends on).
Rule of thumb
Every piece of evidence should answer: what, where, when, and who captured it - and every recommendation should state how the client will prove it worked.