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