Before launching any attacks, a successful penetration test requires rigorous pre-engagement planning. This phase establishes the rules, defines the scope, and ensures both the testing team and the client are aligned on objectives, timelines, and legal boundaries.
flowchart TD
A["Initial Contact"] --> B["Scoping Questionnaire"]
B --> C["Time & Cost Estimation"]
C --> D["Contract & NDA"]
D --> E["Scoping Meeting"]
E --> F["Validate Targets & 3rd Parties"]
F --> G["Establish Comm Channels"]The Pre-Engagement Workflow
Setting up a new engagement involves a structured progression from initial contact to the official start date. Follow these steps to ensure a smooth kickoff.
- 1
Gather initial information
Send the client a comprehensive questionnaire to understand their environment, compliance needs, and primary business goals. This helps you determine whether they need a full penetration test or if a Vulnerability Assessment (VA) is more appropriate for their current security maturity.
- 2
Estimate time and costs
Base your time estimates on the complexity of the target, not just a linear cost-per-IP model. Always add a 20% padding to your time estimate to account for unexpected interruptions (e.g., network outages, emergency meetings). If the padding goes unused, provide extra value by walking the security team through exploits or performing deeper analysis.
- 3
Hold the scoping meeting
Once the NDA and initial contracts are signed, hold a meeting dedicated strictly to defining what will be tested. Keep this meeting focused on scope—save rules of engagement and specific costs for separate discussions. Establish a firm start date and a "drop-dead" end date.
- 4
Validate targets and permissions
Never assume the client owns every IP or domain they provide. Verify ownership of all target environments, including DNS servers, email servers, and physical hardware.
Handling Scope Creep
If a client requests additional testing outside the original agreement, take it as a compliment—but require a new Statement of Work (SOW) and an hourly rate agreement before proceeding. This protects your time and prevents legal misunderstandings.
Scoping Questionnaires
To accurately estimate the engagement, you need to ask the right questions upfront. Use these categories to build your intake forms based on the type of test requested.
Network & General Questions
Why is the test being performed? (e.g., compliance, recent breach, routine audit)
When should active testing occur? (Business hours, after hours, weekends)
How many internal and external IP addresses are in scope?
Are there active defenses in place? (Firewalls, IDS/IPS, Load Balancers)
If a system is compromised, should the team attempt to gain root/SYSTEM privileges or perform password cracking?
Web Application Questions
How many static vs. dynamic pages are being assessed?
Will source code or documentation be provided? (White-box vs. Black-box)
Does the client require fuzzing, static analysis, or role-based credentialed testing?
Wireless & Physical Questions
Wireless: Are guest networks in scope? What encryption is used? Will you be assessing client-side wireless attacks or rogue access points?
Physical: How many locations/floors are in scope? Are there armed guards, silent alarms, or video cameras? Is the use of lock picks or bump keys legally permitted?
Social Engineering Questions
Does the client have a target list of emails or phone numbers?
Is social engineering approved for gaining unauthorized physical access?
Note: Ensure all pretexts (the "story" used to trick users) are approved in writing, as some corporate environments prohibit certain sensitive topics.
Third-Party and Legal Considerations
Modern infrastructure rarely lives entirely on-premises. You must account for third-party providers and regional laws before sending a single packet.
Legal Ramifications
It is your responsibility to verify the laws of the specific country, province, or state where the target servers reside. For example, EU privacy laws strictly govern how social engineering and data access can be conducted. Do not assume your firm's legal team will catch every regional nuance.
| Provider Type | Testing Considerations |
|---|---|
| Cloud Services | Data from multiple organizations often shares physical hardware. You must obtain explicit permission from the cloud provider and establish a direct security contact with them. |
| ISPs | Review the ISP's terms of service. They may automatically shun or block malicious traffic, which can interfere with your testing. |
| Web Hosting | Clarify with the client that testing will only target web vulnerabilities, not the underlying infrastructure owned by the hosting provider. |
| MSSPs | Managed Security Service Providers must be notified if their devices are being tested, unless the goal of the engagement is specifically to test the MSSP's incident response time. |
Establishing Communication Workflows
Communication can make or break client satisfaction. Establish a clear framework for routine updates and emergency situations.
Emergency Contacts
Create and distribute an emergency contact list to all involved parties. This ensures that if a critical system goes down or a severe vulnerability is found, the right people are notified immediately.
Gather the following for each contact:
Full name and operational title
Authorization level for discussing test details
Two forms of 24/7 contact (e.g., cell phone, pager)
A secure method for bulk data transfer
Incident Reporting
Discuss the organization's incident response (IR) capabilities beforehand. If the internal 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. Conversely, if you complete the engagement without being detected, you've identified a major gap in their IR posture.
Secure Communications
Encryption is not optional. Due to the highly sensitive nature of penetration testing data, all critical communications must be secured.
Use PGP/GPG for email communications and encrypting the final report. (Remember: email subject lines are still sent in plaintext!)
Utilize a secure, encrypted mailbox hosted on the customer's network.
Use out-of-band communication, such as secure phone calls, for immediate critical disclosures.