How to Scope a Penetration Test (and Get an Accurate Quote)

Learn how to scope a penetration test and get a realistic quote by understanding test types, components, and common scoping pitfalls.

If you’ve been asked to organise a penetration test – or you’re trying to figure out what kind of test your business needs – you’re not alone. Many people come to us unsure about what to choose, what the terminology means, or how to get a quote that reflects what they actually need.

We suggest reading this guide before completing our free, instant pentesting quote generator.

Penetration testing – a straightforward guide to understanding what you need

This guide is written in plain English and designed to be helpful whether you’re an IT manager, an operations lead, a compliance officer, or someone who’s suddenly been told: “We need a pen test. Can you get a quote?”

We’ll explain what each type of test is, when it applies, why you might need it, what risks it addresses, how to understand application complexity, how to estimate the number of systems or components involved, and what to do if you’re not sure.

By the end of this article, you’ll feel more confident and better prepared to either complete our penetration testing quote generator or book a free scoping call with one of our consultants.

You do not need to read every section of this guide. Use the parts that help you answer the quote generator confidently.

If You Want to Test X, You Need Y

If you just want to know which type of penetration test applies to your situation, use the guide below. You can read the detailed explanations later if you need to.

• If you want to test internet-facing systems such as public IP addresses, VPNs, firewalls, or exposed services: External infrastructure penetration testing

• If you want to understand what an attacker could do once inside your network: Internal infrastructure penetration testing

• If your systems are hosted in AWS, Azure, or Google Cloud Platform: Cloud infrastructure penetration testing

• If you want to test a website, portal, or browser-based application (especially anything with logins, user data, or workflows): Web application penetration testing

• If you want to test an iOS or Android app:  Mobile application penetration testing

Many organisations need more than one type of test. That is normal.

If you’re wondering whether we can “just act like a real attacker and find whatever we can”, we explain why that isn’t possible later in this guide.

How to Estimate the Scope of a Penetration Test

Once you know the type of penetration test you need, the next question is how large the scope is. This is usually the biggest driver of cost.

You do not need to be perfectly precise. You just need to estimate how many separate things need to be tested.

Use the guide below to choose the closest option.

If you are testing a website or web application:

• Count how many externally reachable systems make it work
• This often includes a frontend, one or more APIs, and an authentication service
• Do not count individual pages or screens

If different parts of the application are hosted separately or reachable on different domains or IP addresses, they usually count separately.

If you are testing internet-facing infrastructure:

• Count each public IP address assigned to you
• Count each externally accessible service (for example VPNs, email gateways, remote access portals)

If it is reachable from the internet, it is in scope.

If you are testing internal infrastructure:

• Count each physical site or office with its own internal network
• Do not count individual laptops, desktops, or printers

If two offices have separate networks, they count separately.

If you are testing cloud infrastructure:

• Count each cloud account or subscription
• Count separate environments if they are isolated (for example production and staging)

Cloud environments vary widely, so if you are unsure, choose the higher option or book a scoping call.

If you are testing a mobile application:

• Count each platform separately (iOS and Android)
• Count the backend systems or APIs if you host them

If both apps use the same backend, this may count once.

Why Penetration Testing Scope Matters

Penetration testing is a controlled, authorised attempt to compromise specific systems within an agreed boundary.

From a tester’s perspective, scope defines:

• What they are legally allowed to test
• How deep they are expected to go
• How much time is required
• What level of assurance the results provide

From your perspective, scope determines:

• Whether the test answers the question you actually care about
• Whether the report will be usable for customers, regulators, or auditors
• Whether the quote is realistic or misleading

Penetration testing scope is explicit and finite. Anything not clearly included in scope is treated as out of scope and will not be tested. This protects both parties and ensures results are reliable, repeatable, and defensible.

You can’t test everything at once. So, one of the most important steps is defining exactly what you want tested – also known as defining the scope.

Without scope clarity:

• Testers may miss important systems
• You might get an unrealistic quote
• The test might not meet compliance or contractual needs
• You risk legal or operational issues if unauthorised systems are tested

That’s why our quote generator asks for specific details – not to catch you out, but to help you get the right test for your situation.

Defining scope does not mean sharing sensitive credentials, diagrams, or internal secrets. At this stage, we are only establishing what exists and what is in bounds, not asking for detailed configurations or access.

How Penetration Test Scope Affects Cost

Penetration testing is priced based on effort, not just on the label of the test.

Two organisations may both request “a penetration test”, but the time required can vary significantly depending on what is in scope.

In simple terms, cost is influenced by:

• The type of test: Web application and internal tests typically require more time than basic external testing, because they involve more complex behaviour, access control, and validation.
• How many systems or components are in scope: Each additional system, application, or environment increases the amount of testing required.
• How complex those systems are: Authentication, permissions, business logic, and data handling all increase testing depth.
• How the environment is structured: Separate locations, cloud accounts, or environments (e.g. production and staging) usually require separate testing effort.
• What level of assurance is required: Compliance-driven testing often requires more evidence, deeper validation, and more detailed reporting.

This is why penetration testing quotes are typically provided as ranges rather than fixed prices. Clear scope allows us to estimate effort realistically and avoid surprises later.

If scope is unclear, any cost estimate is likely to be either misleadingly low or unnecessarily high.

A common misconception

Penetration testing is not priced by page count, user numbers, or company size. It is priced based on what needs to be tested and how complex it is to test.

Types of Penetration Testing

1. External Infrastructure Penetration Testing

What it is: Testing your internet-facing systems – the parts of your network visible to the outside world.

Why it’s important: These systems are exposed to anyone on the internet. Attackers routinely scan for open ports, exposed services, and outdated software. Even a single misconfiguration can be exploited.

Risks it helps identify:

• Weak or outdated services (e.g. old web servers or unpatched VPNs)
• Misconfigured firewalls or remote access tools
• Forgotten legacy systems still online
• Exposed admin panels or login portals

How to count components:

• Count each public IP address
• Count each externally accessible service or subdomain (e.g. mail.example.com, vpn.example.com)
• If unsure, your hosting provider or IT team can list your IP ranges

2. Internal Infrastructure Penetration Testing

What it is: Simulating an attack from inside your network – either from a malicious insider or someone who has breached the perimeter.

Why it’s important: Once attackers are inside, they often have broad access. This test checks how easy it would be to move laterally, escalate privileges, or access sensitive data.

Risks it helps identify:

• Weak passwords or shared credentials
• Unrestricted internal access to sensitive systems
• Poor network segmentation
• Insecure file shares and default admin accounts

How to count components:

• Count each office or building with its own internal network
• If you have segmented networks (e.g. guest Wi-Fi, internal LAN), treat them as separate components if they need to be tested
• Don’t worry about individual laptops or printers – we scope based on network environments

3. Cloud Infrastructure Penetration Testing

What it is: Testing systems hosted on platforms like AWS, Azure, or Google Cloud Platform.

Why it’s important: Misconfigured cloud services are one of the most common causes of breaches. Testing can identify risks before they’re exploited.

Risks it helps identify:

• Publicly accessible cloud storage (e.g. open S3 buckets)
• Overly permissive IAM roles
• Misconfigured firewalls or security groups
• Exposed admin interfaces or services

How to count components:

• Count each cloud account or subscription (e.g. AWS account, Azure tenant)
• Count each major service or environment (e.g. production vs staging)
• If you use multiple cloud providers, count each platform separately

4. Web Application Penetration Testing

What it is: Testing the security of websites, portals, and browser-based applications – especially those involving logins, user data, or business logic.

Why it’s important: Web apps are often complex and accessible online. Vulnerabilities here can expose sensitive data or allow unauthorised actions.

Risks it helps identify:

• Broken authentication and session management
• Cross-site scripting (XSS), SQL injection, and other input flaws
• Access control issues – e.g. users seeing data they shouldn’t
• Business logic errors – e.g. skipping approval steps or triggering unintended actions

How complex is your web application?

If you choose web application testing, complexity is one of the biggest drivers of effort.

Basic informational site (no login)

This applies if:

• There is no authentication
• No user-specific content
• No sensitive workflows or data processing
• Mostly static content

Complexity is low because there are few attack paths.

Login page without credentials (black-box)

This applies if:

• A login exists
• No test accounts are provided
• Testing is done entirely from an external attacker’s perspective

This still requires careful testing, but depth is limited by lack of authenticated access.

Full web application with user accounts and roles

This applies if the application includes:

• Authenticated users
• Multiple permission levels or roles
• Business logic or workflows
• Data access controls
• Administrative functionality

This category represents a significant increase in testing effort, because testers must validate not just technical flaws, but logic and access control issues.

If you are unsure, choose this option. Under-scoping web applications is the most common quoting mistake.

How to count components:

• Each externally reachable system (e.g. frontend, API, auth server) counts separately
• Count subdomains or services hosted on separate infrastructure
• Focus on externally exposed parts – not internal pages or content

5. Mobile Application Penetration Testing

What it is: Testing iOS and Android apps, along with the APIs or systems they connect to.

Why it’s important: Mobile apps often store or access sensitive data. Insecure app design, storage, or communication can expose that data.

Risks it helps identify:

• Insecure data storage on the device
• Weak or bypassable authentication
• Poorly protected API communication
• Misuse of permissions (e.g. access to camera, location)

How to count components:

• Count each platform separately (e.g. iOS = 1, Android = 1)
• Count the back-end API(s) if you host them
• If both apps use the same backend, that may count once – unless there are version differences

How to Count Systems for Penetration Testing Scope

Scoping is about identifying how many distinct things need to be tested. This is one of the biggest drivers of cost – and one of the most misunderstood areas for people new to penetration testing.

If you completed the earlier sizing guide, this section simply explains the same idea in more detail and covers common edge cases.

Here’s how to think about components per test type:

Web Applications

• Frontend: Is your UI hosted separately from your backend or API? Count that.
• APIs: Hosted on a different domain or infrastructure? Count that.
• Authentication service: If login is managed by a third-party or standalone system (e.g. login.yoursite.com), count that too.
• Admin panels: If hosted separately or with different access controls, count as a separate component.
• Subdomains: app.example.com, api.example.com, login.example.com may each count separately.

Still not sure? If it has a separate IP, server, or deployment pipeline, it likely counts.

External Infrastructure

• Public IPs: Each IP in use or assigned to you is in scope
• Services: Each unique public-facing service (e.g. mail, VPN, RDP, DNS)
• Subdomains: mail.example.com ? vpn.example.com

Even “unused” IPs may expose services – if they’re routable, they need to be assessed.

Internal Infrastructure

• Offices or sites: Each site with its own network counts
• Network segments: Guest Wi-Fi and internal LAN = 2 components if both need testing
• VPN entry point: If you allow internal access via VPN, that may count as a separate access point

Focus on environments – not individual endpoints.

Cloud Infrastructure

• Accounts/subscriptions: Each AWS, Azure, or GCP account counts
• Regions or environments: If dev and prod are separated, count both
• Key services: Major services in use (e.g. S3, Lambda, Azure VMs) may require targeted testing
• Connections: If your cloud connects to internal networks or identity providers, that adds scope

Cloud is complex – if unsure, we recommend a short scoping call.

Mobile Applications

• Each platform: Android and iOS = two components
• APIs: One backend may support both apps, or they may have separate logic
• Third-party services: Some analytics, push, or auth services may need to be tested

When a quote generator is not the right tool

A penetration test cannot be scoped responsibly if:

• You do not know what systems exist
• You do not know what is externally accessible
• You have no architectural visibility
• You are responding to a vague third-party request

Typical red flags include:

• “We’ve been told we need a pen test”
• “A customer asked for this but didn’t specify anything”
• “We think this is everything, but we’re not sure”
• “IT handles that, we just need a quote”

In these situations, a quote generator will either:

• Underestimate the work
• Exclude critical systems
• Create false confidence

A short scoping call almost always saves time and avoids re-quoting later.

Not Sure What You Need?

If you’re still not sure which test type applies to your environment or situation, that’s completely normal.

We can help:

• Translate vague requirements into a clear, testable scope
• Advise on the best test type for your environment
• Recommend whether pen testing is the right first step

Sometimes, a vulnerability scan or configuration review is a better place to start.

Book a scoping call – no pressure, no jargon.

“Can’t you just act like a real attacker and find whatever you can?”

This is a common request, especially from organisations that do not want to disclose details of their environment in advance.

The short answer is: no, not without defined scope and permission.
And the reasons are legal, ethical, and practical.

Penetration testing is not the same as real-world criminal hacking

A criminal attacker:

• Has no legal constraints
• Does not ask for permission
• Does not care who is impacted
• Does not stop when they hit a boundary
• Is willing to cause disruption, data loss, or downtime

A professional penetration tester must operate very differently.

Penetration testing is a controlled, authorised security assessment, not an open-ended attack. Testers are legally bound to:

• Only test systems they have explicit permission to test
• Stay within agreed boundaries
• Avoid unnecessary disruption
• Protect data and availability
• Produce evidence-based findings that can be fixed

Without scope, testers cannot safely or legally operate.

Testing without scope is illegal

In most jurisdictions, attempting to access systems without explicit authorisation is a criminal offence, even if the intention is defensive.

Without a defined scope, a tester cannot prove:

• Which systems they were allowed to test
• That access attempts were authorised
• That third-party systems were not affected

This exposes both the tester and your organisation to legal risk.

“Just find your way in” creates unacceptable risk

Modern environments are rarely self-contained.

Without scope, a tester may:

• Interact with third-party systems

• Impact shared infrastructure
• Trigger security monitoring or incident response
• Disrupt live services
• Cause unintended data exposure

From your side, this creates operational and reputational risk. From the tester’s side, it is professionally unacceptable.

Undefined scope produces meaningless results

Even if a tester were willing to “find their way in”, the results would not be useful.

Without scope, there is no way to answer:

• What was meant to be tested?
• What was out of scope?
• What does “good coverage” look like?
• Whether critical systems were missed

This makes the report impossible to rely on for:

• Compliance
• Customer assurance
• Risk management
• Remediation planning

Black-box testing still requires boundaries

When people ask for “criminal-style” testing, they are often actually asking for black-box testing.

Black-box testing means:

• No internal documentation
• No architecture diagrams
• No credentials
• No prior knowledge

But even black-box testing still requires:

• Named IP ranges or domains
• Explicit confirmation of ownership
• Defined systems in scope
• Time windows and constraints

Black-box does not mean unlimited or undefined.

Why we ask scoping questions up front

Scoping questions exist to answer four critical things:

1. What are we allowed to test?
2. What must we not touch?
3. How deep should the testing go?
4. What level of assurance is required?

Without clear answers, any test is either unsafe, incomplete, or both.

What to do if you genuinely do not know your environment

If you do not have visibility of:

• What systems are exposed
• What applications exist
• Where boundaries sit
• Who owns what

A penetration test is usually not the best first step.

In these cases, better starting points may include:

• Asset discovery
• External attack surface mapping
• Architecture or scope definition workshops
• A limited, tightly defined reconnaissance exercise

These activities create the clarity needed for a meaningful penetration test later.

The safest and most realistic alternative

If your goal is realism, the closest professional equivalent is:

• Black-box testing
• With clearly defined external boundaries
• Agreed systems and domains
• No credentials
• No internal assistance

This simulates an external attacker without creating legal or operational risk.

Why this matters for your quote

The less defined the scope:

• The wider the potential effort
• The higher the uncertainty
• The less reliable the quote

A quote generator can only work when scope exists.

Frequently Asked Questions About Penetration Testing Scope

What is penetration testing scope?

Penetration testing scope defines exactly which systems, applications, networks, and environments are authorised for testing, and which are not.

It sets clear boundaries around what the tester is allowed to interact with, how deep the testing should go, and what level of assurance the results are expected to provide. Scope typically includes details such as IP addresses, domains, applications, cloud accounts, environments (for example production or staging), and any exclusions.

A well-defined scope protects both your organisation and the testing provider, ensures the results are meaningful, and allows the testing effort and cost to be estimated accurately.

Why is defining penetration testing scope so important?

Defining scope is essential because penetration testing is a legal, authorised security activity, not an open-ended exercise.

Without clear scope, important systems may be missed, testing effort may be misjudged, and results may not meet compliance, customer, or regulatory requirements. There is also a risk of testing systems you do not own or control, which can create legal and operational issues.

Clear penetration testing scope ensures the test answers the question you actually care about and that the findings can be relied on for remediation, reporting, and risk management.

How does penetration testing scope affect cost?

Penetration testing is priced based on effort, not on company size or number of users. Scope is the single biggest factor in determining that effort.

Cost is influenced by the type of penetration test being performed, the number of systems or components in scope, the complexity of those systems, how the environment is structured, and the level of assurance and reporting required.

When scope is clearly defined, a realistic quote can be provided. When scope is vague or incomplete, quotes are often inaccurate and need to be revised later.

Can I just ask for a general penetration test without defining scope?

No. Responsible penetration testing cannot be carried out without defined scope.

Professional penetration testers must have explicit authorisation to test specific systems and must stay within agreed boundaries. Without scope, testing cannot be performed legally, safely, or professionally.

If you are unsure what needs to be tested, a scoping call or an initial discovery exercise is a better starting point than requesting a generic penetration test.

Does penetration testing scope need to be very detailed?

Not at the early stages.

When requesting a quote or planning a test, scope is about identifying what exists and what is in bounds, not about sharing sensitive credentials, configurations, or internal documentation.

Reasonable estimates are usually sufficient. If there is uncertainty, it is generally better to slightly overestimate scope than to under-scope, as this avoids missed systems and re-quoting later.

What happens if we under-scope a penetration test?

Under-scoping can result in critical systems being excluded from testing, which may lead to false confidence in your security posture.

It can also cause delays, additional cost, and the need to re-scope the test once gaps are identified. In compliance-driven situations, under-scoping may mean the results are not accepted by customers, auditors, or regulators.

Choosing a broader or more complex scope when unsure usually leads to more reliable and useful outcomes.

Does the size of my organisation affect penetration testing cost?

No. Penetration testing cost is not based on company size, revenue, or employee count.

A small organisation with a complex web application and cloud infrastructure may require significantly more testing effort than a large organisation with a limited external footprint. What matters is what needs to be tested and how complex it is.

Can penetration testing simulate a real attacker?

Penetration testing can simulate many attacker techniques, but it cannot fully replicate real-world criminal behaviour.

Criminal attackers operate without permission or legal constraints and may cause disruption or data loss. Professional penetration testers must work within agreed scope, avoid unnecessary impact, and produce defensible, evidence-based findings.

The closest professional equivalent to a “real attacker” is black-box penetration testing with clearly defined external boundaries and no credentials, but even this still requires scope and authorisation.

What if we genuinely don’t know what systems we have?

This is a common situation, particularly in growing or long-established organisations.

If you do not have clear visibility of your assets, a penetration test is often not the best first step. Activities such as asset discovery, external attack surface mapping, or scope definition workshops can help establish what exists and what is exposed.

Once this visibility is in place, penetration testing becomes far more effective and meaningful.

Is penetration testing always the right first step?

Not always.

Depending on your goals and level of visibility, an audit, vulnerability scan, configuration review, or discovery exercise may provide more immediate value. Penetration testing is most effective when the environment is reasonably well understood and the objectives are clear.

A scoping discussion helps determine whether penetration testing is appropriate and, if so, which type of test will deliver the most useful insight.

Final Tips for using our penetration testing quote generator

• You don’t need to be technical – just answer the simple questions
• Choose the more complex option if you’re unsure – this avoids under-scoping
• A short call now saves time later – and gets you a more accurate quote