Pre-Engagement & Scoping Setting Up Rules of Engagement

Before you launch a single exploit or run a vulnerability scan, you need a clear agreement on what you are testing and how you are going to test it. Defining the scope (what to test) and the Rules of Engagement (how to test) protects both you and your client from scope creep, legal issues, and unexpected downtime.

flowchart TD
    A["Initial Questionnaire"] --> B["Scoping Meeting"]
    B --> C["Define Scope (The 'What')"]
    B --> D["Define RoE (The 'How')"]
    C --> E["Establish Communication Plan"]
    D --> E
    E --> F["Sign Contract & SOW"]

The Scoping Meeting

The scoping meeting usually occurs after an initial Non-Disclosure Agreement (NDA) is signed. The goal is to validate assumptions, define target environments, and set the boundaries of the test.

  1. 1

    Validate target ownership

    Explicitly establish which IP ranges, domains, and physical locations are in scope. You must verify that the customer actually owns the target environments, including DNS servers, email servers, and underlying hardware.

  2. 2

    Identify third-party providers

    Determine if the client uses Cloud services (AWS, Azure), Managed Security Service Providers (MSSPs), or third-party web hosts. You must obtain explicit permission from these providers before testing, as the client cannot authorize attacks on infrastructure they do not own.

  3. 3

    Define primary and secondary goals

    Align the test with business objectives. The primary goal should focus on identifying risks that impact the organization's mission (e.g., preventing a customer data breach). Secondary goals often revolve around specific compliance requirements (e.g., PCI-DSS).

  4. 4

    Establish timelines and locations

    Set firm start and end dates. Use project management tools like GANTT charts to outline when specific testing phases will occur. Identify any physical locations you need to travel to and research local laws for those regions.

Verify Target Ownership
Never assume a client owns an IP address just because they provided it. Attacking a machine that belongs to a hospital, government agency, or unrelated third party can lead to severe legal consequences. Always validate target ownership before testing begins.

Pre-Engagement Questionnaires

To accurately estimate the time and cost of an engagement, you need to understand the client's environment. Send a targeted questionnaire before the scoping meeting to gather essential details.

Network Penetration Testing
  • Is the test required for specific compliance (e.g., PCI, HIPAA)?

  • When should active scanning and exploitation occur (business hours, after hours, weekends)?

  • How many internal and external IP addresses are in scope?

  • Are there firewalls, IDS/IPS, or load balancers that might impact results?

  • If a system is compromised, should testers attempt to gain root/SYSTEM privileges or perform password cracking?

Web Application Testing
  • How many static and dynamic pages are being assessed?

  • How many distinct login systems or user roles exist?

  • Will source code or API documentation be provided (White-box vs. Black-box)?

  • Does the client require fuzzing or credentialed scans?

Physical & Wireless Testing
  • Wireless: How many networks exist? Is there a guest network? What encryption is used?

  • Physical: How many locations and floors are in scope? Are there armed security guards, silent alarms, or client-owned video cameras? Is the use of lock picks or bump keys permitted by local laws?

Social Engineering
  • Does the client have a specific list of target email addresses or phone numbers?

  • Is social engineering approved for gaining unauthorized physical access?

  • Are specific pretexts (e.g., IT support, delivery driver) required or forbidden?

Establishing Communication Plans

Effective communication is the difference between a successful engagement and a panicked client. You must establish a clear incident reporting process and secure communication channels before the test begins.

Emergency Contacts

Create an emergency contact list and share it with all involved parties. This ensures that if a critical system goes down or a severe vulnerability is found, the right people are notified immediately.

Include the following contacts:

  1. All penetration testers on the engagement.

  2. The manager of the testing group.

  3. Two technical contacts at the target organization.

  4. One upper-management or business contact at the client.

Discuss the organization's incident response capabilities. If the client's security team detects your activity, they need to know who to call so they don't wake up executives in the middle of the night for a false alarm.

Secure Communication Methods

Due to the sensitive nature of penetration testing, all vulnerability data and reports must be encrypted.

MethodBest ForConsiderations
PGP/GPG EmailStatus updates, report deliverySubject lines are sent in plaintext; do not include sensitive info in the subject.
Secure MailboxContinuous communicationMust be hosted securely on the customer's network.
AES Encrypted ArchivesFinal report deliveryEnsure your archive utility supports AES encryption using CBC.
Verbal/PhoneCritical zero-day disclosuresSome organizations prefer highly sensitive findings be delivered verbally first.

Managing Time, Cost, and Scope Creep

Scope creep is one of the biggest risks to a penetration testing firm. If a client asks for additional IP addresses or applications to be tested after the contract is signed, the volume of work increases dramatically.

Handling Scope Creep

Any requests outside the original scope must be documented in a new Statement of Work (SOW). Clearly state in your contract that additional ad-hoc work will be billed at a flat hourly rate and requires a signed SOW before work begins.

Time Estimation and Padding

When estimating how long an engagement will take, calculate the expected hours and then add 20% padding. This cushion protects you against common interruptions, such as a target network segment going down or a critical vulnerability requiring unexpected emergency meetings.

What if you don't use the 20% padding?
Billing a client for unworked hours is unethical. Instead, use that remaining time to provide extra value: walk their security team through an exploit, write an executive summary, or spend extra time trying to crack an elusive vulnerability.

Payment Terms

Establish payment structures early. Common methods include:

  • Net 30: Total amount due within 30 days of final report delivery (often with a late penalty).

  • Half Upfront: 50% billed before testing begins, 50% upon completion.

  • Recurring: Monthly installments for long-term or multi-year engagements.