Blog

Internal vs. External Penetration Testing: Which Do You Need?

Compare internal and external network penetration testing, understand their coverage limits, and prepare a scope that answers your business risk question.

External penetration testing examines what an attacker can reach and exploit from outside the agreed network boundary. Internal penetration testing starts with an agreed position inside that boundary and examines what additional access or impact is possible. Choose the perspective that answers your risk question; when you need evidence about both initial entry and the consequences of a foothold, scope both.

For IT directors and MSPs commissioning an assessment, the important decision is the tester's starting position, permissions, and objective. A proposal labeled “penetration test” leaves too much unsaid if those details are missing.

Internal vs. external network penetration testing at a glance

Compare the starting position and question each assessment answers
AssessmentStarting positionMain question
ExternalOutside the agreed network boundary, targeting authorized exposed systems.Can an outsider exploit the tested services under the agreed conditions?
InternalAn agreed internal connection or account, representing an initial foothold.What additional access or impact is possible from that position?
CombinedSeparate external and internal starting points, documented in the scope.What do both perspectives reveal, and which assumptions remain untested?

External network penetration testing: what can be reached from outside?

An external assessment commonly examines authorized internet-facing systems and services. It can investigate whether exposed weaknesses offer a way into the environment. NIST SP 800-115 distinguishes this outside view from internal testing, which assumes some access already exists.

The useful buying question is specific: “Can an outside attacker compromise the systems supporting this public service under the agreed conditions?” That is more informative than asking whether the organization can pass a generic security test.

If the tester finds no entry path, that result applies to the targets, techniques, and time allowed. It does not establish what a compromised employee device could reach inside the network. Nor does an assessment of listed public addresses automatically cover every application, cloud account, or remote-access route the business uses.

Internal network penetration testing: what does a foothold enable?

An internal assessment begins from a defined network position, sometimes with an ordinary user account. It can examine whether the tester can gain privileges or reach systems beyond the intended access. NIST describes this as a way to assess the consequences of an insider or an attacker who has crossed the perimeter.

“Internal” still needs detail. A guest wireless connection, an employee workstation segment, and a server administration network represent different starting positions. For a useful proposal, name the position that reflects the scenario you want assessed. Giving a tester broad administrative access at the outset answers a different question from starting with an ordinary employee's permissions.

This remains relevant in environments using zero trust principles. NIST SP 800-207 explains that network location alone should not confer trust. Our practical implication for assessment buyers is to identify the resource and access decision being tested, even when the service is in the cloud or users work remotely. An office location is an incomplete description of the security boundary.

Starting position and prior knowledge are separate choices

A tester can assess an internet-facing application while receiving architecture details and authorized user credentials. The external network position does not require a completely uninformed test. Similarly, providing an internal connection does not require granting an administrator account.

The UK's National Cyber Security Centre guidance on penetration testing describes different levels of information supplied to testers and scenario-driven assessments. Less information may better represent a particular attacker, but it can also consume limited testing time on discovery and leave weaknesses unexplored.

Choose that tradeoff deliberately. If the concern is an unknown outsider's opportunity, limited prior knowledge may be useful. If the concern is whether a defined access boundary holds, sharing the design can help focus the engagement. Record the starting assumptions so the findings remain interpretable.

A hypothetical business, two different questions

Consider a hypothetical distributor with a public customer portal and an internal order-management environment. Leadership has two concerns: an outsider gaining access through the portal, and a compromised employee workstation reaching restricted order records.

An external engagement aimed at the portal addresses the first concern. If it finds no usable entry path, the second concern remains open. An internal engagement starting from the employee network can examine the second scenario without spending the whole assessment trying to reproduce the initial compromise.

Conversely, an internal result showing excessive access would establish a problem from that starting position. It would not, by itself, show that the tester could have obtained the foothold from the public internet. The findings should explain which access was supplied and which access was actually gained.

If both concerns matter, commission complementary scopes. If budget requires staging the work, prioritize the question with the most consequential uncertainty and explicitly retain the other as unassessed. Neither perspective substitutes for the other simply because one report has fewer findings.

A network penetration testing scope checklist

Use these questions to make proposals comparable. This checklist concerns network starting points and authorization; application roles and workflows need their own scope.

  • Targets: Which public addresses, domains, internal segments, and locations are included? Who owns them and can authorize testing?
  • Starting access: Where will the tester connect, and what account privileges or prior information will be supplied?
  • Boundaries: Which systems, third-party services, or activities are excluded? How will restrictions and blocked tests appear in the report?
  • Operating arrangements: What testing windows, escalation contacts, and stop conditions protect business operations?
  • Deliverables: What technical evidence, executive explanation, remediation guidance, and follow-up testing are required?

If the engagement includes an application, also prepare the web app test accounts and permission matrix. When reviewing a provider's sample report, use our guide to what penetration testing evidence actually proves.

An illustrative mini-scope

Use a scope record to make the starting position explicit. The addresses, credentials, and timing must be supplied and authorized for the actual engagement.

An illustrative mini-scope
Scope fieldExternal exampleInternal example
Starting positionAn approved tester outside the organization’s network.An approved foothold on a named internal segment.
TargetsAn explicit list of authorized public systems.An explicit list of authorized internal systems and paths.
Access and knowledgeRecord whether accounts and documentation are supplied.Record the starting account, privileges, and documentation.
Exclusions and evidenceAgree prohibited actions, test window, escalation, and expected finding evidence.Agree the same controls plus production and lateral-movement boundaries.

Buy an answer you can use

Before comparing proposals, write down the question the report must answer in one sentence. Then ask each provider to describe the starting position, included systems, permitted activity, exclusions, and evidence that would support an answer. The NCSC's commissioning guidance emphasizes agreeing technical boundaries, scenarios, effort, and reporting requirements during scoping.

Keep conclusions tied to those conditions. A finding should explain the demonstrated consequence; an excluded system or blocked test should remain a visible limitation. Agree how important fixes will be retested from the relevant starting position. This makes the report useful for a decision, rather than leaving leadership to infer coverage from a finding count.

Network Box USA's Penetration Testing service includes external and internal network testing, proof-of-impact evidence, remediation guidance, and retesting within an agreed scope. To discuss which perspective fits your environment, contact our team with the business question you need the assessment to answer.