Penetration testing: what scope, reporting and retesting should include

1. Decide which question the assessment must answer

“We want a pentest” is not yet an objective. Define the decision: validate controls before an application launch, confirm tenant separation, review external exposure, meet a contractual requirement or verify remediation. The question determines assets, accounts, depth, evidence and timing.

Distinguish configuration review, vulnerability assessment, scanning, code review, red-team exercise and penetration testing. NIST SP 800-115 presents techniques with different benefits and limitations. Combining services may be appropriate, but reporting should identify which method produced each piece of evidence.

• Decision depending on the result and its owner.
• Scenario, threat or control being validated.
• Assessment type and reason for selecting it.
• Success criteria, accepted limitations and relevant date.
• Relationship with development, monitoring and continuous vulnerability management.

Finding “some vulnerability” is not a measurable objective and does not define when testing ends.

2. Confirm authorization, ownership and third-party dependencies

Authorization should identify the organization able to permit testing and the people empowered to represent it. Relate every domain, address, application, API, account, network and environment to an owner. An internet-accessible asset does not become authorized merely because it connects to the client’s system.

Review hosting, CDN, cloud, payment, authentication, messaging, support and other dependencies. Providers publish their own policies; Microsoft and AWS, for example, define rules and exclusions for testing cloud services. Obtain permission or remove those components from the path before active activity.

• Authorizing entity, signer and technical and executive contacts.
• Inventory with concrete identifiers and confirmed ownership.
• Included environments and explicit exclusion of third-party systems.
• Cloud, hosting, telecommunications and other provider policies.
• Route for extending scope without assuming improvised verbal authorization.

Technical scope can never be broader than demonstrated authority.

3. Write rules of engagement usable during testing

Rules turn broad permission into operational decisions. They include dates, timezone, traffic sources, accounts, rate limits, windows, permitted techniques and actions requiring additional approval. Define whether data changes, file uploads, account access, social engineering, persistence, lateral movement or availability testing are allowed.

Establish normal communication, critical reporting and an emergency stop. Identify who may order a pause and which evidence must be preserved. Align monitoring and support so the test can be distinguished from a real incident without disabling the detection capability being observed.

• Start, end, timezone, source addresses and windows.
• Permitted, restricted, prohibited and approval-gated actions.
• Test data, accounts, backups and available safeguards.
• 24/7 contacts where operational risk requires them.
• Stop, restart and critical-finding communication thresholds.

4. Derive coverage from architecture, flows and requirements

A generic list does not represent a concrete application. Map components, entry points, roles, data, trust boundaries, integrations and high-impact functions. Include negative and positive flows: searching for known errors is not enough; controls should also be verified against their intended behavior.

OWASP WSTG provides domains and cases for web applications and services, while OWASP ASVS provides verifiable requirements useful in contracts and criteria. Select references with a version, adapt cases to the system and document what could not be tested because of time, data, architecture or restrictions.

• Relevant architecture, technologies, interfaces and dependencies.
• Roles and accounts for anonymous, user and administrative access.
• Critical functions, sensitive data and organization boundaries.
• Security requirements that should operate and cases to validate them.
• Excluded, unavailable or blocked coverage and its effect.

Citing OWASP does not demonstrate coverage; reporting must connect each reference to assets and executed cases.

5. Combine tools with manual validation and impact control

Tools help discover surfaces, compare responses and detect patterns, but they produce false positives, false negatives and context-free results. Every important finding needs proportionate validation, a reproducible condition and enough evidence for the responsible team to understand and remediate.

Minimize impact and data. A test may demonstrate access without copying a complete dataset, or execution without maintaining persistence. Record time, source, account, request or condition, response, asset and applied limit. If information outside the objective appears, stop expansion and follow the agreed procedure.

• Technique or tool and version where relevant.
• Precondition, role, asset and reproducible sequence.
• Observed result versus expected behavior.
• Redacted or minimized evidence and secure delivery channel.
• Avoided impact, limitation and finding confidence.

6. Require reporting that supports decisions and remediation

OWASP WSTG recommends separating executive summary, test parameters and technical findings, including scope, schedule, objectives and limitations. Each finding should explain condition, asset, technical impact, reproducible evidence, recommendation and references; group symptoms sharing a cause where that helps fix the system.

CVSS, maintained by FIRST, communicates technical characteristics and severity; it does not replace business analysis. Add exposure, asset criticality, data, compensating controls and plausibility to decide priority. A high number does not authorize an urgent change that may stop a service without understanding context.

• Executive summary: what matters, why and which decision is needed.
• Scope, dates, method, accounts, exclusions and limitations.
• Technical finding with evidence, reproduction and affected assets.
• Technical severity separate from organizational impact and priority.
• Concrete recommendation, options and closure-verification criterion.

Finding count alone measures neither security nor penetration-test quality.

7. Plan remediation and retesting in the contract

Assign an owner, date, dependency and closure evidence to every action. Correct the cause where possible: one narrow validation can hide the same pattern in other endpoints, roles or components. Feed changes into development, configuration, automated tests, monitoring and training according to origin.

Retesting repeats agreed conditions and verifies that the solution did not merely hide the symptom. Define rounds, deadline, environment and included findings. Record states such as remediated, partial, open, not reproducible, accepted risk or not assessed without turning the retest into a broad guarantee.

• Remediation owner and approved priority.
• Cause, planned change and similar systems to review.
• Test demonstrating closure and retained evidence.
• Included retest window and scope.
• Residual risk and formal decision where no fix is applied.

8. Evaluate providers through clarity, safety and transfer

Request a proposal naming scope, method, team, deliverables, evidence handling, insurance or applicable contractual requirements, critical communication and retesting. Certifications may signal individual or process knowledge, but do not replace a report sample, experience with the technology and the ability to explain limitations.

Before starting, update inventory, confirm backups, prepare test accounts and data, notify necessary owners and define a secure channel. Do not silently remediate during testing unless risk is immediate; record changes so results remain interpretable. At closure, revoke accounts, remove access and confirm evidence disposal.

• Relevant experience and identifiable technical owner.
• Deliverable sample with useful evidence and protected data.
• Conflict-of-interest, confidentiality and escalation process.
• Prepared temporary access, monitoring, backup and contacts.
• Closure of accounts, evidence, sessions and pending obligations.