What is the scope of a pentest?

The pentest scope in plain English

Before a penetration test begins, it has to be clear what it covers: a specific web application, all servers reachable from the internet, the internal network at one location, or how your team handles phishing emails. This definition is called the scope.

An everyday comparison: if you hire a home inspector before buying a house, you specify what should be inspected – just the roof, or the basement, electrical system, and heating as well. Anything not included in the assignment won’t be inspected, and the report won’t say anything about it. It’s the same with a pentest: a report only makes statements about the systems that were in scope.

How the scope is defined

The scope is set during what’s known as scoping – a conversation or questionnaire before the quote. Typically, the following points are clarified:

1. Test targets: Which applications, interfaces, IP address ranges, cloud environments, locations, or groups of people are included?
2. Exclusions: What will deliberately not be tested – such as service providers’ systems for which there is no permission?
3. Perspective: Will testing be done from the outside, like an attacker on the internet, or from the inside, like an infected workstation?
4. Prior knowledge: Does the testing team get hardly any information up front (black-box testing), test accounts and documentation (gray-box testing), or comprehensive insight all the way down to the source code (white-box testing)?
5. Extent and depth: How many user roles, functions, or systems will be tested, and which standards will the test follow?
6. Test environment: Will testing take place in the live environment or in a separate test environment, and what access is needed?

The scope answers the question “What will be tested?” How testing is carried out – time windows, permitted techniques, escalation paths – is governed by the rules of engagement.

A practical example

Here’s a typical scenario: An online retailer wants to have “the online shop” tested. During scoping, it turns out there’s more to it than the shop pages: an app for regular customers, an interface through which the shop exchanges data with the inventory management system, and an admin area for customer service. The external payment service provider is excluded because its system doesn’t belong to the retailer.

Testing takes place in a test environment, with test accounts for three roles: customer, customer service, and administrator. The result is a quote that matches the actual risks. Later, the testing team finds the most serious vulnerability in, of all places, the interface – with the scope originally envisioned, it would have gone undetected.

Why does this matter for businesses?

A scope that’s too narrow creates blind spots and a false sense of security: the report is clean, but the real vulnerability lay outside the scope. A scope that’s too broad, on the other hand, spreads the budget across many systems, leaving too little testing time for the critical ones.

The scope also determines the price. Quotes from different providers can only be compared if they cover the same scope. It also has a legal side: testing is only permitted where authorization has been granted. And any evidence you present to customers, insurers, or auditors always applies only to the scope that was tested. A later retest – testing again after remediation – also relates to the vulnerabilities found within this scope.

What to look out for

• Start from risk: First ask which data and processes matter most to your business, and align the scope accordingly.
• Think it through completely: Include interfaces, apps, admin areas, subdomains – the sub-addresses of your website – and cloud accounts that belong to the application.
• Document exclusions: Record in writing what won’t be tested and why.
• Clarify ownership: Make sure the listed systems and IP addresses belong to you or that their operator consents to the test.
• Prepare test accounts: Plan access for all relevant user roles.
• Compare quotes fairly: Make sure all quotes describe the same scope.

How Rootsektor can help

For penetration tests and security assessments, we work with you to define the scope during scoping and, if needed, suggest how best to tailor it. You’ll receive a fixed-price quote within 24 hours of scoping (on business days) – with no additional charges for the agreed scope. On request, we sign a non-disclosure agreement in advance. You can describe your test scope directly via our Pentest Quote page.