Defining the scope is arguably the most important component of a penetration test. A well-defined scope prevents scope creep, ensures legal protection, and sets clear expectations between you and your client. This page guides you through establishing clear boundaries, setting goals, and ensuring all logistical bases are covered before testing begins.

flowchart TD
    A["Identify Targets and Goals"] --> B["Assess Third-Party Involvement"]
    B --> C["Establish Communication Plan"]
    C --> D["Define Rules of Engagement"]
    D --> E["Obtain Permission to Test"]

Setting the Goals

Every penetration test should be goal-oriented. The purpose is not just to find unpatched systems, but to identify risks that could adversely impact the organization.

• Primary Goals: Focus on business risk. For example, while a client might request a test for PCI-DSS compliance, the primary goal is demonstrating the business impact if customer credit card data were leaked.

• Secondary Goals: These are typically related to compliance or IT checklists (e.g., successfully obtaining the credit card numbers).

Before diving into a full penetration test, assess the client's security maturity. If they have a very immature security program, a Vulnerability Assessment (VA) might provide them with far more value than a full penetration test.

Defining the Targets

It is imperative to validate that the targets you are attacking are actually owned by the customer. A common pitfall is assuming the client owns all infrastructure between you and the target application.

Handling Third-Party Services

Modern environments heavily rely on third-party infrastructure. Client permission does not grant you permission to test their third-party providers.

• Cloud Services: Cloud environments host data from multiple organizations on shared physical mediums. You must alert the cloud provider, follow their specific procedures (such as Amazon's online request forms), and establish a direct security contact with them.

• ISPs and Web Hosts: Review the ISP's terms of service. ISPs may shun or block malicious traffic. Web hosting providers must also be notified of the scope and timing of the test.

• MSSPs (Managed Security Service Providers): If the client uses an MSSP, they generally need to be notified. The only exception is if testing the MSSP's actual response time is an explicit goal of the engagement.

International Considerations

Verify the countries where the target servers are housed. Laws vary wildly from region to region (e.g., strict EU privacy laws). It is your responsibility to verify and adhere to local laws before testing begins.

Gathering Client Requirements

During initial communications, use scoping questionnaires to accurately estimate the workload.

Establishing Communication

How often you interact with the customer can make a huge difference in their satisfaction. An ignored customer is a former customer.

1. 1

   Create an Emergency Contact List

   Gather 24/7 contact information for all parties in scope. Include full names, titles, authorization levels, and two forms of immediate contact (e.g., cell phone). Include technical contacts for both the target organization and your testing team.

2. 2

   Define the Incident Reporting Process

   Discuss the organization's incident response capabilities. Ensure someone at the target organization knows when tests are occurring so they don't accidentally trigger a massive internal alarm in the middle of the night.

3. 3

   Set Status Meeting Frequencies

   Schedule brief, regular status meetings (often daily). Keep these focused on three concepts: Plans (what's next), Progress (what's done), and Problems (blockers).

4. 4

   Establish Secure Communication

   Encryption is not optional. Establish a secure means of communication before testing begins. Use PGP/GPG for emails, secure client-hosted mailboxes, or AES-encrypted archive files (using CBC) for delivering the final report.

Rules of Engagement (RoE)

While the scope defines what will be tested, the Rules of Engagement define how the testing will occur.

Handling Sensitive Information

You may gain access to sensitive data like Personally Identifiable Information (PII) or Protected Health Information (PHI). Do not download or take possession of this data.

Instead, prove access by taking a screenshot of the database schema, file permissions, or directory listings (ensuring no sensitive data is visible in the filenames).

Logistics and Edge Cases

Discuss specific testing parameters with the client to ensure smooth execution:

• Denial of Service (DoS): If availability is a concern, stress testing should only be conducted in a non-production environment that mirrors production.

• Shunning: Determine if the client's security team is allowed to block your IP addresses. This is acceptable for black-box tests evaluating the security team, but counterproductive for large, coordinated vulnerability sweeps.

• Time of Day: Clarify if testing must occur strictly outside of business hours to prevent operational disruption.

Time Estimation and Payment

Accurate time estimation relies on experience, but you should always account for the unexpected.

Ensure you have a definitive "drop-dead date" for the project. Any requests outside the original scope require a new Statement of Work (SOW) and should be billed at an agreed-upon hourly rate.

Common Payment Structures

Establish clear payment terms before testing begins.

The Final Step: Permission to Test

Do not send a single packet until you have a signed Permission to Test document.

This document legally acknowledges the scope, confirms awareness of the testing activities, and explicitly states that while all due care will be taken, testing can lead to system instability. Crucially, it must include a "hold harmless" clause stating the customer will not hold the tester liable for any system crashes or instability.