What Network Penetration Testing Actually Covers (And What It Does Not)

When a client tells us their network was pen tested last year, the follow-up question that matters most is: which network? A network penetration test is not a blanket assurance that every device, segment, and service in your environment has been assessed. It is a time-boxed exercise against a defined scope, and what sits outside that scope remains untested, regardless of how thorough the work was inside it.

Scope misunderstandings account for a significant portion of the frustration organisations feel after a pen test. The expectation was comprehensive coverage; the delivery was technically excellent but narrowly bounded. Understanding what a network pen test actually covers before you commission one saves budget, avoids gaps, and produces findings you can act on.

What Is Typically in Scope

A network penetration test generally targets IP ranges, subnets, and the services exposed within them. External assessments cover internet-facing infrastructure: firewalls, VPNs, publicly accessible management interfaces, mail servers, and any other services reachable from outside the organisation. Internal assessments assume an attacker has already gained initial access and focus on lateral movement, privilege escalation, and access to critical systems from within the network.

Common in-scope activities include port scanning and service enumeration, vulnerability identification and exploitation, password spraying against accessible authentication services, testing for network segmentation weaknesses, and attempts to reach crown-jewel systems from a foothold position. A well-scoped engagement also defines out-of-band testing, such as whether the tester may attempt to identify additional hosts not in the original IP list if they discover them during testing.

What Is Typically Out of Scope

The gaps that surprise organisations most are not exotic edge cases. Cloud-hosted infrastructure is frequently excluded from a network pen test unless it is explicitly added. If your workloads sit in a managed cloud environment and the test covers only your on-premises IP ranges, your cloud attack surface goes untouched. Similarly, OT and ICS networks are almost always carved out for safety reasons, even when they connect to corporate networks that are in scope.

Endpoint devices, web applications, APIs, and active directory environments may be adjacent to the network but they each carry their own assessment methodology. A network pen test that finds an open port does not automatically include a full application-layer review of whatever is running on that port. Physical access, social engineering, and wireless testing are separate disciplines entirely. If you want those covered, they need to be scoped in explicitly, with appropriate resourcing and time allocated.

Why Scope Boundaries Matter More Than People Realise

The risk of unclear scope is not just a missed finding here or there. It is the creation of false assurance. An organisation that believes its network has been tested may deprioritise investment in areas the testers never touched. When those gaps are later exploited, the pen test report becomes evidence that the problem area was not assessed, but the executive team often does not remember the scope boundaries in the original statement of work.

Scope decisions also affect what findings are reportable. If a tester discovers a misconfigured cloud storage bucket while testing adjacent infrastructure, whether they can report and pursue it depends entirely on whether cloud was in scope. Organisations benefit from broader scope agreements that allow for in-scope expansion where adjacent risk is discovered, rather than artificially limiting what a tester can flag.

How to Set Scope That Reflects Real Risk

The most useful scoping conversations start with threat modelling, not IP ranges. Ask which systems, if compromised, would cause the most harm. Work backwards from those assets to understand what network paths could reach them. That exercise often reveals that the segment you were planning to test is not where the real exposure sits.

A competent testing partner will push back on scope that excludes material risk. If you are asking for an external network test but your internet-facing perimeter is largely managed by a third party and your real exposure is internal segmentation, that conversation needs to happen before contracts are signed. The goal of scope definition is to direct testing effort at actual risk, not to create a clean boundary that protects comfortable assumptions.

• Define scope by asset criticality, not by convenience or historical convention.
• Explicitly list exclusions so both parties understand what is not being tested.
• Include cloud, wireless, and OT as separate line items so they are a deliberate include or exclude, not an assumption.
• Allow for scope expansion clauses so testers can flag adjacent risk they encounter.
• Align scope to the threat model, not just the asset register.

To discuss network penetration testing scope for your organisation, contact Cyberlinx at info@cyberlinx.com.au.