Penetration Testing: Scope, Evidence, Reporting and Retest — DedSec Project

Penetration testing is an authorized security assessment that combines discovery, validation, controlled exploitation where necessary, evidence collection, and reporting. A professional test is judged by accuracy, safety, reproducibility, and the usefulness of its remediation—not by the amount of access obtained.

Authorized-use boundary: A penetration test requires explicit permission, defined systems, allowed techniques, data-handling rules, contacts, and stop conditions. If a requested action is outside scope, do not perform it merely because it is technically possible.

Learning objectives

• create a rules-of-engagement document;
• design tests around security objectives;
• manage accounts, test data, and evidence safely;
• validate findings with minimal impact;
• communicate severity, uncertainty, and limitations;
• retest remediation and close findings cleanly.

Pre-engagement

Clarify:

• legal/organizational owner of the systems;
• in-scope and out-of-scope assets;
• source addresses and test accounts;
• dates/time windows;
• allowed and prohibited techniques;
• social engineering or physical testing, if any;
• production-safety constraints;
• third-party and cloud-provider restrictions;
• emergency/stop contacts;
• data retention and encryption;
• reporting expectations.

Threat model and objectives

A useful test begins with questions such as:

• Can a normal user access another tenant's object?
• Can an Internet-facing service reach an internal management network?
• Can a compromised workstation identity modify a protected build artifact?
• Will monitoring detect a known benign simulation of a specific behavior?

This makes testing measurable.

Discovery

Use inventories and passive evidence first. Active scanning should be bounded to the scope and rate needed. Record every source of truth and note uncertainty.

Validation and controlled proof

Prefer the smallest proof that demonstrates impact. Examples include reading a synthetic test object, creating a harmless marker, invoking a non-destructive test function, or reproducing a crash in a local copy.

Avoid collecting real data merely to strengthen a screenshot. Do not create persistent access unless explicitly required—and even then, prefer a benign simulation whenever possible.

Evidence management

Evidence should include:

• timestamp and tester identity;
• affected asset/version;
• request/configuration/test input;
• relevant response or log excerpt;
• authentication/authorization context;
• expected versus observed behavior;
• screenshots only when they add information;
• hashes for downloaded artifacts when appropriate.

Redact secrets and personal data from the report.

Severity and risk

Separate technical severity from business risk. Describe prerequisites, exploitability, blast radius, asset criticality, existing controls, and confidence. If you did not validate an assumption, say so.

Reporting structure

A useful finding contains:

1. title and affected assets;
2. concise summary;
3. evidence/reproduction using safe steps;
4. impact in the tested environment;
5. root cause;
6. remediation;
7. retest criteria;
8. references.

An executive summary should describe themes and business consequences rather than listing tool output.

Retest

A retest repeats the original security invariant after remediation. Confirm both that the weakness is fixed and that the intended functionality still works. If the remediation is partial, document residual risk and next actions.

Cleanup

Remove test accounts, synthetic records, temporary files, and configuration changes that were created by the assessment. Preserve legitimate audit and security logs. Return credentials/secrets through the agreed process and confirm data-retention requirements.

Common mistakes

• Treating a scanner report as a penetration test.
• Expanding scope informally.
• Collecting unnecessary production data.
• Creating persistence or destructive impact to “prove” severity.
• Hiding uncertainty.
• Reporting only technical details without remediation.
• Failing to retest.

Safe lab

Write rules of engagement for a fictional two-host lab. Define one authorization objective, one network-exposure objective, and one detection objective. For each, state evidence, safe stop condition, and retest criteria. Then write one sample finding using only synthetic data.

Knowledge check

1. What makes rules of engagement different from a target list?
2. Why is minimal proof preferred?
3. What should be redacted from evidence?
4. How does a retest differ from simply checking that a patch installed?
5. Why should logs be preserved during cleanup?

Guided study workflow

Use the shared Study Method. A completed lab should produce a scope document and a professional finding, not merely command output.

Continue with

Recommended next modules: 26, 27, 43, 50, 85.