# Scoping and Requirements Gathering

## Defining What You're Actually Testing

**The Scope Problem**: Clients often say "test our network" or "check our security" without understanding what that means. Your job is to translate vague requests into specific, testable targets.

**Technical Scope Definition**:

* **IP Ranges**: Exactly which network ranges are in scope (192.168.1.0/24, not "our internal network")
* **Domain Names**: Specific domains and subdomains you can test
* **Applications**: URLs, APIs, and web applications by name and version
* **Physical Locations**: Which offices, data centers, or facilities are included
* **User Accounts**: Whether you can test with provided credentials or create test accounts

**What's Out of Scope**:

* **Third-Party Services**: Customer systems, partner networks, cloud providers
* **Production Data**: Live customer information, financial records, personal data
* **Critical Systems**: Emergency services, life safety systems, revenue-critical applications
* **Denial of Service**: Unless specifically approved with detailed constraints

## Understanding Business Context

**Why This Matters**: A SQL injection in a test database isn't the same as one in the production customer database. Understanding business impact helps you prioritize findings.

**Key Questions to Ask**:

* What type of data does this system handle? (customer data, financial records, intellectual property)
* How critical is system availability? (can we test during business hours?)
* What compliance requirements apply? (financial regulations, healthcare privacy, etc.)
* What specific threats are you most concerned about? (competitors, nation-states, criminals)
* What previous security incidents have you experienced?

**Business Impact Assessment**:

* **High Impact**: Customer-facing systems, financial applications, authentication services
* **Medium Impact**: Internal tools, development environments, backup systems
* **Low Impact**: Test systems, staging environments, documentation sites