Penetration Test Scope
Define penetration test scope, objectives, rules of engagement, and success criteria.
Context
You are a senior security architect planning a penetration test for $ARGUMENTS. A well-scoped penetration test has clear objectives, defined targets, agreed-upon constraints, and measurable success criteria. Poor scoping leads to missed testing, false negatives, or testing outside agreed boundaries.
Domain Context
- Penetration Test Types: External (attack from internet), internal (attack from network), social engineering, physical security, supply chain
- Scope Dimensions: Systems (servers, applications, networks), data (what's in scope to access?), users (employees, customers, partners?), timeframe
- Rules of Engagement (RoE): What's allowed? Denial of service? Social engineering? Data exfiltration? Which systems are off-limits?
- Compliance Alignment: PCI-DSS, HIPAA, SOC 2, ISO 27001 may require annual or periodic penetration testing
Instructions
-
Define Test Objectives:
- Clarify what you want to learn: "Can attackers access customer data?", "Is our authentication robust?", "Do employees fall for phishing?"
- Align with business goals: security posture improvement, compliance validation, incident response testing, supply chain risk assessment
- Specify success criteria: vulnerabilities found, attack chain demonstrated, business impact quantified
-
Define Test Scope:
- In-Scope Systems: List all systems to be tested (web app, mobile app, APIs, cloud infrastructure, on-prem servers)
- Out-of-Scope Systems: Systems that are off-limits (production databases, critical infrastructure, third-party systems without permission)
- Data Scope: What data can testers access or exfiltrate? (Avoid accessing real customer PII if possible; use staging data)
- Timeline: When is testing allowed? (Off-hours? Weekends? Avoid critical business events)
-
Establish Rules of Engagement:
- Destructive Testing: Are DOS/DDoS attacks allowed? System crashes?
- Social Engineering: Is phishing/pretexting allowed? Which employee groups?
- Physical Access: Can testers attempt physical break-ins?
- Reporting: Who is notified if a critical vulnerability is found? Escalation procedures?
- Remediation Access: Do testers have access to remediation systems, or test-only access?
-
Identify Constraints & Limitations:
- Environment: Production, staging, or dedicated test environment?
- Approval Required: What testing requires additional approval (data access, social engineering)?
- Testing Intensity: Full attack simulation vs. lighter assessment?
- Regulatory: Which compliance frameworks apply? (PCI-DSS, HIPAA, SOC 2)
-
Document Agreements:
- Written scope document signed by security team and business stakeholders
- Penetration test contract with external firm (if applicable) specifying RoE
- Communication plan (who gets updates, how urgent issues are escalated)
- Post-test briefing schedule and report expectations
Anti-Patterns
- Vague scope ("test our security"); specific, measurable scope prevents misalignment and wasted effort
- Excluding critical systems from scope; scope should represent your highest-risk assets
- Unlimited social engineering (annoying employees, high stress); social engineering should be targeted and approved
- Testing production without permission or safeguards; always get explicit approval; consider staging environment
- Not documenting RoE; misunderstandings between tester and organization cause conflicts
Further Reading