How Is the Scope of a Penetration Test Determined?

The success of a penetration test does not depend only on the tools used or the technical depth of the specialists. It rests on a properly defined scope.

A poorly planned scope means important systems get missed, risk is assessed incorrectly and the reporting comes out incomplete. A test plan built around what the organisation actually needs, by contrast, reveals the real attack surface, allows critical risks to be prioritised, and produces results that mean something to engineers and executives alike.

In a professional engagement, scoping is therefore always the first stage.

What Is the Scope of a Penetration Test?

The scope is the technical and operational plan defining which systems will be tested, by which methods, over which period and within which boundaries.

In other words, the scope is the roadmap that establishes:

• which systems are included,
• which systems are excluded,
• which methods will be used,
• the rules that apply during testing,
• the responsibilities of each party.

A properly written scope document protects both the client organisation and the testing team.

Why Does Scoping Matter So Much?

In practice, many organisations open with a request like this:

"We'd like our website tested."

The critical question is:

Which website?

Because most organisations do not have just one system.

For example:

• The corporate website
• The customer portal
• The dealer portal
• The HR application
• The ERP system
• The CRM system
• Mobile application APIs
• Administrative interfaces
• VPN services
• Active Directory
• Cloud infrastructure

All of these can carry different levels of risk within the same organisation.

Saying "the website" is therefore not enough.

Professional scoping requires every digital asset to be identified clearly.

What Can Be Included in the Scope?

Depending on what the organisation needs, the scope can be very broad.

Web Applications

• Websites
• Customer portals
• ERP systems
• E-commerce applications
• Administrative interfaces

API Services

• REST API
• GraphQL
• SOAP
• Mobile APIs
• Partner APIs

Network Infrastructure

• Firewall
• Switch
• Router
• VPN
• Reverse proxy
• DMZ

Servers

• Windows Server
• Linux Server
• Web servers
• Database servers
• File servers

Identity Management

• Active Directory
• LDAP
• Azure AD
• Microsoft Entra ID

Cloud Environments

• Microsoft Azure
• AWS
• Google Cloud Platform
• Kubernetes
• Docker

Mobile Platforms

• Android
• iOS

Wireless Networks

• Corporate Wi-Fi
• Guest network
• Factory wireless networks

Industrial Systems

• SCADA
• PLC
• OT network
• ICS

The right scope differs for every organisation.

What Is Considered When Setting the Scope

A professional engagement involves more than listing systems.

The following are considered as well.

Test Environment

Will testing take place on live systems?

Or in a test environment?

Testing against live systems shows the real security posture, but maintenance windows may need planning for some critical systems.

Timing

Will testing run during working hours?

At the weekend?

Overnight?

In organisations with heavy user traffic in particular, timing should be planned to minimise operational impact.

Critical Systems

Some systems can bring production to a halt.

For example:

• Hospital systems
• Manufacturing plants
• Banking infrastructure
• Energy systems

The techniques applied to systems like these must be agreed in advance and executed under control.

Privileged Accounts

Which approach will the test take?

• Black box
• Gray box
• White box

Will a user account be provided?

An administrator account?

Will source code be shared?

These decisions directly shape the test methodology.

The Biggest Mistakes Made in Scoping

One of the problems we meet most often in the field is a scope that is incomplete or incorrectly defined.

For example:

❌ Testing only the main domain

Subdomains get forgotten.

❌ Leaving API services out of scope

The web application is tested while the APIs running behind it are ignored.

❌ Assessing only the interface of a mobile application

The test is treated as complete without analysing the APIs and the data in transit.

❌ Excluding Active Directory

Yet many ransomware attacks spread through the domain infrastructure.

❌ Forgetting cloud services

Misconfiguration in Azure, AWS or Google Cloud goes untested.

What Does a Well-Defined Scope Deliver?

Good scoping means:

• Critical systems are assessed in full.
• Time and cost are managed properly.
• The testing window is used efficiently.
• Realistic attack scenarios can be applied.
• A false sense of security is avoided.
• Risk is prioritised more accurately.
• Reporting is more meaningful for management.

In short, the right scope is the foundation of a successful penetration test.

The SecureSys Approach

At SecureSys we begin every project with scope analysis, before any technical testing starts.

During that process:

• Every digital asset to be tested is identified.
• Critical systems are prioritised.
• A test plan is prepared that will not affect business continuity.
• The regulations the organisation is subject to are considered.
• The methodology is aligned with the scope.
• Expectations and boundaries are set out in writing.

Client and testing team therefore work towards the same goal, and the findings that come out at the end are far more accurate and far easier to act on.

Once the scope is settled, the next important decision is which perspective the test should take.

Should the tester proceed with no knowledge of the system at all? With limited user credentials? Or with full access to the architecture and source code?

The answer lies in the black box, gray box and white box approaches.

---

← Previous chapter: Types of Penetration Testing

Next chapter → Social Engineering: A Chain of Attacks That Starts With One Click