Accurately estimating the time, budget, and resources required for a penetration test is critical to a successful engagement. Proper scoping ensures that both you and your client have clear expectations, preventing scope creep and ensuring adequate coverage of the target environment.
Calculating Time Requirements
Estimating the time required for an assessment relies heavily on the experience of the testing team. If you are assessing a familiar environment, you can often estimate time innately. For less familiar territory, reviewing previous engagement logs and timelines is a reliable starting point.
The 20% Padding Rule
Once you determine the base time required for testing, it is a standard industry practice to add 20% padding (often called consultant overhead) to your estimate.
Padding provides a necessary cushion for unexpected interruptions, such as:
Network segments unexpectedly going down.
Discovering a critical vulnerability that requires immediate, time-consuming meetings with management.
Delays in credential provisioning or firewall whitelisting.
What if you don't use the padding?
Billing a client for unworked hours is unethical. If you finish early, use the remaining time to provide additional value. You can walk the security team through exploitation steps, provide an executive summary, or spend extra time attempting to crack an elusive vulnerability.
Structuring Your Pricing
A common trap is maintaining linear costs throughout the testing process. For example, charging a flat rate of $1,000 per IP address might make sense for a block of 100 standard IPs, but applying that same rate to a single, highly complex, business-critical web application will leave you severely undercharging for your labor.
Always vary your costs based on the volume and complexity of the work, rather than a strict per-asset metric.
Common Payment Terms
Establish payment structures before testing begins. Here are the most common models:
| Payment Model | Description | Best Used For |
|---|---|---|
| Net 30/60 | Total amount is due within 30 or 60 days of final report delivery, often with late penalties. | Standard, short-to-medium length engagements. |
| Half Upfront | 50% of the total bill is required before testing begins, with the remainder upon completion. | New clients or resource-intensive assessments. |
| Recurring | Regular installment payments made throughout the lifecycle of the engagement. | Long-term engagements spanning several months or years. |
Managing Scope Creep
Scope creep occurs when a client requests additional testing outside the original agreement without adjusting the budget or timeline. Managing this effectively is vital to maintaining profitability and healthy client relationships.
- 1
Establish a drop-dead date
Every project needs a definitive end date. Ensure your contract specifies the exact date testing concludes.
- 2
Document out-of-scope requests
If a client requests additional work, do not perform it ad-hoc. Document the request in a new Statement of Work (SOW).
- 3
Apply an hourly rate
Include a clause in your initial contract stating that any work outside the defined scope will be billed at a flat hourly rate, pending a signed SOW.
- 4
Define retesting windows
Clients often request retesting after patching. Add a statement to the contract requiring all retesting to occur within a specific timeframe (e.g., 30 days) after the final report delivery.
Legal Ramifications of Ad-Hoc Work
Taking on additional work without formal documentation can lead to legal disputes. If an undocumented test causes an outage, it becomes difficult to prove you had permission to target that specific asset.
Coordinating Third-Party Resources
Modern infrastructure rarely lives entirely on-premises. You will frequently encounter assets hosted by third parties, cloud providers, or managed by external security teams. Client permission does not automatically grant you permission to test third-party infrastructure.
flowchart TD
A["Identify Target Asset"] --> B{"Hosted by 3rd Party?"}
B -- No --> C["Client Permission Sufficient"]
B -- Yes --> D{"Is it a Cloud Environment?"}
D -- Yes --> E["Obtain Explicit Cloud Provider Permission"]
D -- No --> F{"Managed by MSSP?"}
F -- Yes --> G{"Testing MSSP Response?"}
G -- Yes --> H["Do Not Notify MSSP"]
G -- No --> I["Notify MSSP"]
F -- No --> J["Check ISP Terms of Service"]Cloud Services: Cloud environments host data from multiple organizations on shared physical mediums. You must alert the cloud provider and follow their specific penetration testing procedures (request forms, scheduling) to avoid violating their Terms of Service.
ISPs: Verify the Internet Service Provider's terms. Some ISPs automatically shun or block traffic they consider malicious.
MSSPs: Managed Security Service Providers should generally be notified when systems they manage are tested. Exception: If the goal of the engagement is to test the MSSP's incident response time, do not notify them.
Pre-Engagement Questionnaires
To accurately estimate time and resources, you must gather detailed information about the target environment during the initial scoping phase. Use targeted questionnaires based on the type of assessment.
Network Penetration Testing
How many total IP addresses are being tested (internal vs. external)?
Are there devices in place that may impact testing (firewalls, IDS/IPS, load balancers)?
If a system is compromised, should the team attempt to gain highest privileges (root/SYSTEM)?
Are we authorized to perform password attacks against obtained local hashes?
Web Application Testing
How many static vs. dynamic pages are being assessed?
How many distinct login systems/roles exist?
Will source code or API documentation be made available (White-box vs. Black-box)?
Is fuzzing or credentialed scanning permitted?
Wireless & Physical Testing
Wireless: Is there a guest network? What encryption is used? What is the square footage of coverage?
Physical: How many locations/floors are in scope? Are there armed security guards? Is the use of lock picks or bump keys legally permitted and authorized? Are there silent or motion-triggered alarms?
Social Engineering
Do you have a targeted list of email addresses or phone numbers?
Is social engineering for the purpose of gaining physical access approved?
Are specific pretexts off-limits (e.g., HR complaints, IT password resets)?
