How to Scope a Penetration Test: What Buyers Get Wrong

The cost of getting scope wrong

Scoping is where most pentest engagements succeed or fail. Not during testing. Not in the report. In the scoping phase.

When buyers under-scope, they get a clean report that misses entire segments of their attack surface. When they over-scope, they burn budget on low-value targets while critical systems get shallow coverage. Both outcomes waste money.

The problem is not a lack of good testing companies. It is that buyers often hand off scoping decisions they should own. A penetration testing company can advise on methodology. But only you know which assets matter, what compliance mandates apply, and where your actual risk sits.

This guide walks through the practical decisions that define a pentest scope. It is written for the people signing the statement of work.

Start with asset inventory, not a vendor call

The single most common scoping failure is contacting testing companies before you know what you have.

You cannot scope what you have not inventoried. Before any vendor conversation, you need a current list of:

• External-facing IP ranges and domains. Include subdomains and any cloud-hosted assets.
• Web applications. List each one separately. A marketing site and a customer portal are different tests.
• APIs. Document endpoints, authentication methods, and whether they are public or internal.
• Internal network segments. Note VLANs, Active Directory domains, and any segmentation between environments.
• Cloud infrastructure. Identify providers, account structures, and shared-responsibility boundaries.
• Mobile applications. Specify platforms (iOS, Android) and whether you want backend API testing included.
• Wireless networks. Include guest networks and any IoT-connected segments.
• People. If social engineering is in scope, define which departments and roles.

If your asset inventory is incomplete, say so. A good testing company will help identify gaps during scoping. But they cannot build your inventory for free, and you should not expect them to.

What buyers get wrong here

Three patterns come up repeatedly:

1. Listing only production assets. Staging and development environments often have weaker controls and direct paths to production data. If they are internet-accessible, they are targets.
2. Forgetting third-party integrations. Your application may call APIs owned by other organizations. You need written permission from those third parties before testing touches their infrastructure.
3. Using stale asset lists. An inventory from 6 months ago is not current. Cloud environments change weekly. Run a fresh discovery before scoping.

Choose the right test type for the objective

Different test types answer different questions. Picking the wrong one is a scoping error, even if the test itself is executed well.

Test type	What it answers	Typical scope
External network pentest	Can an attacker breach our perimeter?	Public IPs, domains, exposed services
Internal network pentest	What can an attacker do after gaining internal access?	Internal network segments, Active Directory
Web application pentest	Does this application have exploitable vulnerabilities?	Single application, its APIs, and authentication flows
Mobile application pentest	Is the mobile app and its backend secure?	App binary, API endpoints, local storage
Wireless pentest	Can someone compromise our wireless infrastructure?	SSIDs, access points, segmentation
Social engineering	Are our people susceptible to phishing or pretexting?	Defined employee groups, specific attack scenarios
Red team engagement	Can a motivated attacker achieve a specific objective?	Broad, often including physical, digital, and human vectors
Cloud configuration review	Are our cloud environments securely configured?	Specific accounts, subscriptions, or projects

Buyers frequently request a “pentest” without specifying which type. This is like asking a contractor to “fix the building” without saying which floor has the problem.

Be specific. If you need a web application pentest, say so. If you need an internal network pentest with an assumed-breach starting point, say that. The test type shapes everything: methodology, duration, staffing, and price.

When you need more than one test

Many organizations need multiple test types. A common combination is an external network pentest plus web application testing for customer-facing apps.

Do not combine these into a single scope unless the testing company explicitly proposes it. Each test type has different tooling, methodology, and reporting requirements. Bundling them without clear boundaries leads to shallow coverage across both.

Request separate scopes and separate reports. This also makes it easier to compare quotes from different companies.

Define what is out of scope

Out-of-scope items matter as much as in-scope items. Failing to define them creates ambiguity that causes problems during testing.

Common items to explicitly exclude:

• Production databases with live customer data. If you want testing against production, define data-handling rules clearly.
• Denial-of-service testing. Most organizations exclude DoS attacks from pentest scope. If you want resilience testing, scope it separately.
• Third-party SaaS applications. You likely do not have authorization to test your CRM or email provider.
• Physical security testing. Unless explicitly included, assume it is out.
• Specific IP ranges or systems. Shared infrastructure, partner networks, or systems with known instability.

Put exclusions in writing. “Everything not listed as in-scope is out of scope” is a reasonable default, but name the critical exclusions explicitly to prevent misunderstandings.

Set rules of engagement

Rules of engagement are the operational constraints that govern how testing is conducted. They protect your business continuity and define what the testing company can and cannot do.

Every scope of work should specify:

Testing window

When can testing occur? Some organizations restrict testing to business hours. Others prefer off-hours to minimize user impact. Define the start date, end date, and daily window.

If you have change-freeze periods, maintenance windows, or peak traffic times, flag them.

Communication plan

Define who the testing company contacts and when.

• Primary technical contact. Someone who can answer questions about systems and grant access.
• Emergency contact. Someone reachable outside business hours if testing causes an outage.
• Escalation path for critical findings. If the team finds a critical vulnerability during testing, how quickly do they notify you? 1 hour? 4 hours? Define it.

A common buyer mistake: listing a project manager as the only contact. Technical contacts who understand the environment reduce delays during testing.

Credential and access levels

Specify what the testing team starts with:

• Black box. No credentials, no prior knowledge. Simulates an external attacker.
• Grey box. Standard user credentials provided. Tests what an authenticated user can access or escalate.
• White box. Full credentials, source code access, architecture documentation. Maximizes coverage.

Grey box testing is the most common for web applications. It provides the best balance of realism and coverage. Black box testing is appropriate for external network assessments. White box is useful for code-heavy applications where you want maximum depth.

Do not default to black box because it sounds harder. If an attacker can register an account on your application, starting a test without credentials wastes time on authentication bypass that any real attacker would skip.

Acceptable techniques

State whether the following are permitted:

• Brute-force attacks against authentication
• Exploitation of vulnerabilities (versus identification only)
• Pivoting between systems after initial compromise
• Data exfiltration (even simulated)
• Modification of data or configurations
• Creation of new accounts

If you are unsure, ask the testing company for their standard rules of engagement as a starting point. Most established companies have a template.

Align scope with compliance requirements

If your pentest is compliance-driven, the scope must satisfy specific requirements. Different standards have different expectations.

PCI DSS

PCI DSS requires testing of the cardholder data environment (CDE) and any systems connected to it. The scope must include:

• All systems that store, process, or transmit cardholder data
• All systems in the same network segment as the CDE
• Any system that could affect the security of the CDE

A common mistake: scoping only the payment application. If your CDE is not properly segmented, the scope should include adjacent systems. A testing company performing a PCI-focused assessment should validate your segmentation as part of the engagement.

SOC 2

SOC 2 does not mandate penetration testing, but many organizations include it as evidence for the security trust service criteria. If your auditor expects a pentest report, clarify exactly which systems are in scope for the SOC 2 audit and test those.

ISO 27001

ISO 27001 Annex A requires technical vulnerability management. Penetration testing is a common way to demonstrate this. The scope should align with your ISMS scope. If your ISMS covers specific business units or systems, your pentest scope should match.

Regulatory requirements

Some industries have specific testing mandates. Financial services regulators may require CBEST, TIBER-EU, or similar threat-intelligence-led testing frameworks. These have their own scoping methodologies. If you are subject to one, your testing company needs experience with that specific framework.

The gap between compliance scope and risk scope

Compliance-driven scoping tests what regulators require. Risk-driven scoping tests what matters most to your business. These are not always the same thing.

A PCI DSS pentest may cover your payment infrastructure while leaving your corporate network, employee credentials, and cloud environment untested. If your biggest risk is ransomware through phishing, a PCI-scoped test will not find it.

Most organizations benefit from doing both: a compliance-focused test to satisfy audit requirements, and a separate risk-focused test to find what actually threatens the business.

Size the engagement correctly

Once you know what is in scope, you need to estimate the effort required. This determines cost and timeline.

Testing companies typically price engagements in days. Here are rough sizing guidelines:

Scope	Typical effort
Single web application (standard complexity)	5 to 10 days
Single web application (high complexity, many roles)	10 to 20 days
External network (up to 256 IPs)	3 to 5 days
External network (large range, 1,000+ IPs)	5 to 15 days
Internal network (single site, standard AD)	5 to 10 days
Internal network (large enterprise, multiple domains)	10 to 25 days
Mobile application (single platform)	5 to 8 days
Red team engagement	15 to 40 days
Cloud configuration review (single account)	3 to 5 days

These are ranges. Your mileage will vary based on application complexity, network size, and depth of testing required.

What buyers get wrong here

Accepting unrealistically low estimates. If a company quotes 3 days for a complex web application with multiple user roles, authentication flows, and API integrations, the test will be shallow. You will get automated scanner output with minimal manual testing.

Treating days as interchangeable. Two testers for 5 days is not the same as one tester for 10 days. For complex engagements, overlapping testers with different specializations (network, application, cloud) produce better results than a single generalist working alone.

Not budgeting for retesting. After the initial test, you will need to fix vulnerabilities and verify the fixes. Most companies offer retesting as a separate line item. Include it in your budget from the start.

Write the scope of work document

The scope of work (SoW) is the contract between you and the testing company. A clear SoW prevents disputes, scope creep, and wasted effort.

Your SoW should include:

• Objective. One or two sentences. What is this test meant to achieve?
• Test type. External network, web application, internal network, etc.
• In-scope assets. Specific IPs, URLs, application names, network segments.
• Out-of-scope assets. Named exclusions.
• Testing approach. Black box, grey box, or white box.
• Methodology. OWASP Testing Guide, PTES, OSSTMM, or the company’s proprietary methodology.
• Rules of engagement. Testing window, communication plan, acceptable techniques.
• Deliverables. Report format, executive summary, technical findings, remediation guidance.
• Retesting terms. How many hours or days of retesting are included, and within what timeframe.
• Timeline. Start date, end date, report delivery date.
• Assumptions. Access requirements, VPN credentials, test accounts, environment availability.

Do not sign a SoW that says “penetration testing of client environment” without further detail. That is not a scope. It is an invitation for misaligned expectations.

Avoid these common scoping mistakes

A summary of the patterns that lead to poor outcomes:

• Scoping by budget, not by risk. “We have $20,000” is not a scope. Start with what needs testing, then adjust based on budget constraints.
• Copying last year’s scope. Your environment changed. Your scope should too.
• Testing only what you are confident about. The systems you are least sure about are often the ones that need testing most.
• Letting the testing company define scope alone. They do not know your business, your risk tolerance, or your compliance obligations. Scoping is a joint effort.
• Skipping the pre-engagement call. A 30-minute scoping call with the testing team prevents days of wasted effort.
• Forgetting about data sensitivity. If testers will encounter PII, health data, or financial records, define data-handling requirements in the SoW.

How to compare scoping proposals

Once you send your requirements to multiple testing companies, you will receive proposals with different approaches. Here is how to evaluate them:

Look for specificity. A good proposal references your actual assets, describes the testing methodology for your environment, and explains how days are allocated. A generic proposal that could apply to any client is a red flag.

Compare day allocations. If one company proposes 5 days and another proposes 12 for the same scope, ask both to explain their breakdown. The cheaper option may be relying heavily on automated scanning. The more expensive option may be padding.

Check tester qualifications. Ask which testers will work on your engagement and what their certifications are. CREST, OSCP, OSCE, GXPN, and similar credentials indicate hands-on testing ability.

Ask about tooling. Professional testers use a mix of commercial tools, open-source tools, and manual techniques. A proposal that names only automated scanners is unlikely to deliver thorough results.

Request sample reports. The report is your primary deliverable. Review a sample before signing. It should include clear finding descriptions, evidence, risk ratings, and actionable remediation guidance.

pentest.fyi lists thousands of penetration testing companies that you can filter by services offered, certifications held, company size, and location. If you have defined your scope and know what you need, the directory is a practical starting point for finding companies to request proposals from.

Scoping checklist

Use this before you send your requirements to testing companies.

• Asset inventory is current and complete
• Test type is defined (external, internal, web app, mobile, etc.)
• In-scope assets are listed with specifics (IPs, URLs, app names)
• Out-of-scope assets are explicitly named
• Testing approach is selected (black box, grey box, white box)
• Rules of engagement are drafted
• Testing window is defined
• Communication plan and contacts are identified
• Compliance requirements are documented
• Data sensitivity and handling rules are addressed
• Budget includes retesting
• Third-party permissions are obtained (if needed)
• Stakeholders have reviewed and approved the scope

Final note

Scoping is not administrative overhead. It is the decision that determines whether your pentest produces actionable findings or a generic report that sits in a drawer.

Own the scope. Define it with precision. Then find a testing company that can execute against it.

You can search for penetration testing companies by location, service type, and certifications on pentest.fyi.

Key Takeaways

• Scoping errors are the most common reason pentest engagements fail to deliver useful results.
• Define your asset inventory before you contact a single testing company.
• Rules of engagement protect both parties and must be documented before testing begins.
• Compliance-driven scoping and risk-driven scoping require different approaches and produce different outcomes.
• A detailed scope of work reduces cost disputes, scope creep, and wasted testing days.

Frequently Asked Questions (FAQ)

What is the most common scoping mistake buyers make?

Failing to maintain an accurate asset inventory before engaging a testing company. Without a clear list of in-scope systems, IP ranges, and applications, the engagement will either miss critical assets or waste time on irrelevant ones.

How long does it take to properly scope a penetration test?

For a straightforward web application test, scoping can take a few days. For a large enterprise network or multi-environment engagement, expect 2 to 4 weeks of internal preparation before you can provide a testing company with the information they need.

Should I scope based on compliance requirements or actual risk?

It depends on your objective. Compliance-driven scoping satisfies auditors but may leave significant attack surface untested. Risk-driven scoping focuses testing where a breach would cause the most damage. Many organizations do both separately.

What belongs in a pentest scope of work document?

At minimum: in-scope assets, out-of-scope assets, test type, testing methodology, rules of engagement, testing window, communication plan, deliverable format, and retesting terms.

How do I find a penetration testing company that fits my scope?

Start by defining your requirements, then search for companies with relevant experience. pentest.fyi lists thousands of penetration testing companies that you can filter by services, certifications, and location.