How to Scope a Penetration Test: The Complete Guide to Getting the Right Quote
A pentest is only as good as its scope. Badly scoped tests waste money (too broad) or miss critical risks (too narrow). This guide reduces the vendor-buyer information gap.
Black Box vs Grey Box vs White Box: Cost Implications
| Approach | Access Level | Cost Impact | Best For |
|---|---|---|---|
| Black Box | No prior knowledge. Tester has only the target URL or IP range. | 20-30% more expensive (extra reconnaissance time) | Simulating a real external attacker. Useful for red team exercises and external perimeter tests. |
| Grey Box | Authenticated access with test credentials. Some architecture documentation. | Baseline cost (most common approach) | Most web app and API pentests. Balances realistic testing with efficiency. The sweet spot for most organisations. |
| White Box | Full access: source code, architecture docs, credentials, API documentation. | 20-30% cheaper (no reconnaissance phase) | Deep security analysis. Best for code-heavy applications, compliance-driven tests, and when maximising finding depth. |
Recommendation: grey box is the right choice for 80% of penetration tests. It provides efficient testing with realistic attack simulation. White box is best when you want maximum finding depth and cost efficiency.
Scoping Checklists by Test Type
Gather this information before requesting a quote. The more detail you provide, the more accurate (and typically lower) the quote will be.
Web Application
- □Number of applications in scope
- □URLs for each application
- □Number of authenticated user roles
- □Authentication method (SSO, SAML, OAuth, local)
- □Estimated number of pages/screens
- □API endpoints (REST, GraphQL, SOAP)
- □File upload functionality (yes/no)
- □Payment processing (yes/no)
- □Staging or production environment?
- □Source code access available? (white box)
Network / Infrastructure
- □Number of external IP addresses
- □Number of internal IP ranges
- □Active Directory environment (yes/no, number of domain controllers)
- □Number of physical sites
- □VPN access for internal testing
- □Network segmentation diagram
- □Operating systems in scope (Windows, Linux, other)
- □Critical systems to exclude from testing
- □Acceptable testing hours and maintenance windows
Cloud Infrastructure
- □Cloud provider(s): AWS, Azure, GCP
- □Number of cloud accounts/subscriptions
- □Kubernetes clusters (number, complexity)
- □Serverless functions (Lambda, Cloud Functions)
- □Key services in scope (S3, RDS, EC2, etc.)
- □IAM configuration documentation
- □Multi-region deployment (yes/no)
- □Container registries and CI/CD pipelines
Mobile Application
- □Platforms: iOS, Android, or both
- □App store URLs or test builds
- □API backend in scope (yes/no)
- □Payment/financial features
- □Biometric authentication
- □Offline functionality
- □Push notification service
- □Certificate pinning implemented?
- □Jailbreak/root detection in place?
API
- □API type (REST, GraphQL, SOAP, gRPC)
- □Number of endpoints
- □Authentication method (JWT, OAuth, API key)
- □API documentation available (OpenAPI/Swagger)
- □Rate limiting in place?
- □Multi-tenant architecture?
- □WebSocket or real-time endpoints
- □Versioned API (number of active versions)
Red Team
- □Engagement duration (weeks)
- □Physical access component (yes/no)
- □Social engineering component (yes/no)
- □Geographic locations of offices
- □Specific threat actor to simulate (optional)
- □Blue team awareness (announced vs unannounced)
- □Rules of engagement and escalation procedures
- □Critical systems off-limits
- □Purple team debrief required?
Sample Scope Statements
Use these templates as starting points. A clear scope statement is the single best way to get accurate quotes and prevent scope creep.
SaaS Web Application
In Scope
Grey-box penetration test of app.example.com. Three authenticated user roles (Admin, Manager, User). Approximately 45 pages/screens. RESTful API with 80 endpoints documented in Swagger. OAuth 2.0 authentication via Auth0. No source code access. Staging environment provided. One retest of Critical and High findings within 60 days.
Out of Scope
Marketing website (www.example.com), mobile applications, infrastructure-level testing, social engineering.
Internal Network
In Scope
Internal network penetration test of 10.0.0.0/16 subnet (approximately 200 active hosts). Active Directory environment with 2 domain controllers. Grey-box approach: tester provided with domain user credentials and VPN access. Testing hours: Monday-Friday 09:00-18:00 EST. Duration: 5 business days.
Out of Scope
External perimeter testing, web applications, production database servers (10.0.5.0/24 excluded), denial-of-service testing.
AWS Cloud Assessment
In Scope
White-box assessment of production AWS account (ID: 123456789). Services in scope: EC2, S3, RDS, Lambda, IAM, VPC, CloudFront, ECS. Tester provided with ReadOnly IAM role and architecture documentation. Assessment of IAM policies, security group rules, encryption settings, and privilege escalation paths.
Out of Scope
Development and staging accounts, application-layer testing, third-party SaaS integrations.
What a Good Pentest Report Looks Like
The report is the primary deliverable. Here is the structure you should expect from a professional provider:
1-2 pages. Overall risk rating, key findings summary, strategic recommendations. Written for non-technical stakeholders.
Testing approach (black/grey/white box), tools used, dates of testing, tester qualifications, rules of engagement.
Each finding includes: title, CVSS score, severity rating, description, evidence (screenshots, request/response), affected assets, and remediation guidance.
Common Vulnerability Scoring System. Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9), Informational.
Prioritised list of remediation actions. What to fix first, estimated effort for each fix, quick wins vs long-term improvements.
After remediation, evidence that fixes were verified. Pass/fail status for each original finding. Regression testing notes.
Managing Scope Creep
Scope creep is the most common cause of pentest cost overruns. Here is how to prevent it:
- ✓Write explicit 'in scope' and 'out of scope' lists in the contract
- ✓Define rules of engagement: testing hours, escalation contacts, no-test zones
- ✓Agree on a change control process before the engagement starts
- ✓Set a maximum engagement duration with automatic stop
- ✓Include a scope review checkpoint at 50% completion
Common scope creep triggers to watch for:
- !Discovering new applications or services during testing
- !Stakeholders adding 'just one more thing' mid-engagement
- !Unclear ownership of shared infrastructure components
- !Testing in production leading to unexpected incident response
- !Compliance requirements discovered after testing has started