Business Guide

Scoping a Penetration Test: What to Include, What to Exclude

> series: business_owners_guide —— part: 05/10 —— topic: scoping —— principle: good_scope_equals_good_test<span class="cursor-blink">_</span>_

Hedgehog Security 3 February 2026 11 min read

A test is only as good as its scope.

Scoping is the process of defining exactly what will be tested, how it will be tested, and — equally important — what will not be tested. It is the single most important step in the penetration testing process, because every decision made during scoping directly affects the value of the results. Too narrow a scope and you miss critical systems. Too broad and the tester spreads too thin to test anything properly. Unclear scope and both sides end up disappointed.

This article walks you through the scoping process from a business owner's perspective — what information you need to provide, what questions the provider should ask, and how to make informed decisions about scope that balance thoroughness with budget.


Recommended

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Information to gather before scoping.

A good scoping conversation is efficient and productive when you arrive prepared. You do not need to be technical — but you do need to know the basics of what you have and what matters most to your business. Gather the following before your scoping call with the provider.

Information Why the Provider Needs It Who to Ask Internally
Your external IP addresses and domains Defines the boundary of an external infrastructure test. The number of IP addresses and domains directly affects the duration and cost of the engagement. Your IT team, hosting provider, or managed service provider. Ask for a list of all public-facing IP addresses and all registered domain names.
Your web applications and their user roles For web application testing, the provider needs to know how many applications are in scope, how large they are (number of pages, features, and API endpoints), and what user roles exist (unauthenticated, standard user, administrator). Each role needs to be tested separately. Your development team or application owner. If you do not have a definitive list, the provider can help identify applications during reconnaissance — but this uses testing time.
Your internal network structure For internal testing, the provider needs to understand the size of your network — number of subnets, servers, workstations, and network devices. Also important: whether you use Active Directory, how many domains exist, and whether network segmentation is in place. Your IT team or network administrator. A network diagram is ideal but not essential — a conversation about the general structure is sufficient for scoping.
Third-party and cloud services If your infrastructure includes cloud-hosted systems (AWS, Azure, Google Cloud), SaaS applications, or third-party managed services, the provider needs to know — because testing these systems may require additional authorisation from the third party. Your IT team. Also check contracts with your cloud and hosting providers for any clauses relating to penetration testing.
Your business objectives for the test The most valuable input you can provide. What are you most worried about? What data would cause the most damage if breached? What systems are business-critical? What compliance requirements are you trying to meet? This helps the provider prioritise testing effort where it matters most. This is your question to answer as the business owner.

The choices that shape your test.

Once the provider has the basic information, they will work with you to make a series of decisions that define the engagement. These are not purely technical decisions — they involve trade-offs between cost, coverage, and risk appetite that require business input.

What Is In Scope
Everything the tester is authorised to test. This should be defined precisely — specific IP ranges, specific URLs, specific applications. Ambiguity here leads to either gaps in coverage or the tester accidentally testing systems you did not intend. If in doubt, include it — the provider can always exclude non-critical systems to manage budget.
What Is Excluded
Systems, applications, or test types that are explicitly off-limits. Common exclusions include third-party hosted systems where you do not have authorisation, production databases where data corruption is unacceptable, and denial-of-service testing on live systems. Exclusions should be documented in the rules of engagement and acknowledged by both parties.
Testing Window
When can testing occur? Some organisations restrict testing to business hours so IT staff are available to respond to issues. Others prefer out-of-hours testing to avoid impacting users. For external testing, attackers do not respect business hours — testing outside working hours is more realistic. Agree this upfront.
Testing Approach
Black box, white box, or grey box — as discussed in Part 2. Also consider whether the tester should attempt social engineering, whether denial-of-service testing is permitted, and whether the tester should stop at demonstrating a vulnerability or should fully exploit it to demonstrate business impact.
Communication During Testing
How will the tester communicate with your team during the engagement? Who is the primary contact? What happens if a critical vulnerability is found — is the tester authorised to continue, or should they stop and report immediately? Define an escalation path for critical findings discovered during the test.

What drives the price.

Penetration testing is priced primarily by the number of testing days required, which is determined by the scope. Understanding what drives the day count helps you make informed decisions about scope and budget.

Factors That Increase Testing Duration
── External Infrastructure ────────────────────────────────
More IP addresses = more time
More services per IP = more time
Complex configurations = more time
Typical: 2–5 days for a small to medium external test

── Web Application ────────────────────────────────────────
More pages/features = more time
More user roles = more time (each role tested)
Complex business logic = more time
API endpoints = more time
Typical: 3–10 days depending on application complexity

── Internal Infrastructure ────────────────────────────────
Number of subnets/VLANs = more time
Active Directory complexity = more time
Number of servers = more time
Typical: 3–7 days for a small to medium internal test

── Additional Services ────────────────────────────────────
Social engineering campaign = 2–5 additional days
Wireless testing = 1–2 additional days
Retest of findings = 1–2 additional days

Budgeting Guidance

As a rough guide for UK organisations: a small external penetration test might cost from £2,000 to £5,000. A web application test for a moderately complex application typically falls between £3,000 and £8,000. A combined external and internal test for a medium-sized organisation might range from £5,000 to £15,000. These figures vary significantly by provider and scope — treat them as order-of-magnitude guidance, not fixed prices.


Scoping errors to avoid.

We see the same scoping mistakes repeatedly. Avoiding these common pitfalls ensures your engagement delivers maximum value.

Mistake Consequence What to Do Instead
Testing only what you think is secure You miss the systems you do not know about or assume are safe. The most critical vulnerabilities are often in systems nobody thought to include. Let the tester conduct reconnaissance on your full IP range and domain portfolio. They may discover services you have forgotten about.
Excluding production to avoid risk If you only test staging or development environments, the results may not reflect your actual exposure. Production systems often have different configurations, data, and access controls. Test production with agreed safeguards — limited exploitation depth, business-hours only, immediate notification of critical findings. The risk of testing is far lower than the risk of not testing.
Scoping too broadly on a tight budget The tester rushes through everything and tests nothing thoroughly. Breadth without depth misses the vulnerabilities that matter most. Prioritise. Test your most critical or most exposed systems properly first. Extend scope in subsequent engagements.
Not involving the right people in scoping Important systems are missed because the person on the scoping call did not know about them. Legacy applications, shadow IT, and partner integrations are frequently overlooked. Include your IT manager, a senior developer (for web application testing), and if possible your network administrator in the scoping conversation.

Part 6 preview.

Scoping defines what will be tested. Next week, we cover how to prepare your organisation for the test itself — what your IT team needs to do, what access to provide, what to communicate internally, and how to ensure the engagement runs smoothly from day one.


Free, no-obligation scoping consultations.

We will work through your infrastructure, applications, and business objectives to define a scope that targets your highest risks within your budget. No pressure, no commitment — just a clear picture of what you need and what it will cost.

Next Step

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Related Articles