Design Penetration Test Scopes

This skill defines comprehensive penetration testing scopes that balance thoroughness with practical constraints, built around five elements: assets in scope (IP ranges, domains, applications), allowed testing methods and attack vectors, explicit boundaries and out-of-scope limitations, rules of engagement (testing windows, communication protocols, emergency procedures), and measurable success criteria. It applies a risk-based approach that prioritizes high-value assets and critical business functions, weighs industry-specific threat patterns, balances depth against time and budget, and aligns scope with compliance requirements like PCI DSS, NIST, or ISO 27001.

It provides a technical scope definition covering external IP ranges and domains with exclusions, internal network segments and Active Directory testing constraints, and web application scope with authentication and per-role testing, plus a methodology section naming allowed frameworks (OWASP, NIST SP 800-115, PTES) and explicitly categorizing techniques as allowed, restricted (for example, DoS testing only during maintenance windows), or prohibited (data destruction, data exfiltration, third-party attacks). Testing-category guidance covers network infrastructure boundaries (only specified ranges, a request-rate cap, no direct third-party or cloud-provider testing) and web application parameters (test accounts only, all privilege levels, excluding payment processing, automated scans limited to business hours).

Rules of engagement cover communication protocols (primary/secondary/escalation contacts, a 2-hour notification window for critical findings, immediate notification for system impact, daily status emails) and defined testing windows per test type (network scans weekdays 9-5, web app testing continuous automated plus business-hours manual, internal testing a narrower midweek window, high-impact tests scheduled 48 hours ahead). It also covers evidence handling (a screenshot naming convention, AES-256-encrypted evidence archives), authorization documentation (signed agreement, network diagram, cloud authorization letter), five standard limitation clauses (time-bound, point-in-time, methodology-specific, non-exhaustive, environmental), a pre-test validation checklist, and a formal scope-creep change-request process for handling newly discovered or out-of-scope assets.

nmap -sn 203.0.113.0/24
nmap -sS -O -sV --top-ports 1000 203.0.113.10

Use this skill when scoping a penetration test - defining in-scope assets and testing methods, setting rules of engagement and testing windows, writing authorization and limitation documentation, or handling scope creep when new assets are discovered mid-test.

It is not a fit for conducting the penetration test itself or writing the final findings report - it's scoped to the pre-engagement scoping and rules-of-engagement documentation, not the technical exploitation or reporting phases.

Inputs are the client's asset inventory (IP ranges, domains, applications), compliance requirements, and available testing budget and timeline. Outputs are an executive summary scope document, a technical YAML scope definition, rules of engagement with testing windows and communication protocols, limitation clauses, a pre-test checklist, and a scope-creep change-request process.

Penetration testers and security consultants who need a complete, client-ready scope document - technical asset boundaries, rules of engagement, legal and compliance documentation, and success criteria (100% of in-scope assets assessed, zero scope violations, all critical findings validated) - rather than assembling scoping documentation from scratch per engagement.