Internal vs External Penetration Testing: What's the Difference?

When you start looking at penetration testing, one of the first choices you face is internal or external. The terms sound like a technicality. They are not. The two tests start from different places, answer different questions, and find different problems — and buying the wrong one first is a common and expensive mistake.

Here is the distinction in plain terms.

External penetration testing

An external test is conducted from outside your network, the way a stranger on the internet would see you. The tester has no credentials and no access. They start with your domain name and work out what they can reach.

The question it answers: what can someone with no access do to us?

What it typically covers:

• Internet-facing assets — web servers, mail servers, VPN endpoints, remote access portals
• External attack surface discovery, including systems you may have forgotten are exposed
• Leaked credentials that have appeared in public breach data
• Password spraying risk against exposed login portals
• Misconfigured services and unnecessary exposure

The most common finding on a first external test is not a dramatic vulnerability. It is an asset nobody knew was public — a forgotten staging server, a legacy portal from a decommissioned system, an admin interface that was only ever meant to be reachable internally.

Internal penetration testing

An internal test starts inside your network. The tester is placed in the position of someone who already has a foothold: a compromised laptop, a phished employee, a contractor with excessive access, or someone who plugged into a network port in a meeting room.

The question it answers: if an attacker gets in, how far do they get?

What it typically covers:

• Internal attack surface discovery
• Active Directory misconfiguration — usually the richest source of findings
• Lateral movement between systems
• Privilege escalation toward domain administrator
• Whether network segmentation actually holds
• Use of leaked or reused credentials against internal systems

Internal tests almost always find more than external tests. That is not because internal networks are worse; it is because there is far more of it to look at, and because internal environments are historically built on the assumption that everyone inside is trusted.

The practical differences

Can an internal test be done remotely?

Usually, yes. In most scenarios we carry out internal penetration tests remotely, either over a VPN connection or using a small device we post to you and you plug into the network.

The exception is a segmented network. If your environment is properly divided — a separate manufacturing VLAN, an isolated card-processing zone, a site-to-site arrangement across offices — then where the tester is placed determines what they can see. In those cases we will work with you to decide the right physical location, or agree several.

This is worth raising during scoping rather than discovering on day one of testing.

Which should you buy first?

If you are testing for the first time and can only do one, start external. Three reasons:

1. It models the threat that reaches everyone. Every organisation with an internet presence is scanned continuously by automated tooling. That is not targeted, it is just background weather, and external testing tells you how you fare in it.
2. It is the cheapest entry point. Smaller scope, fewer days.
3. It usually satisfies the trigger. If a customer's security questionnaire or your cyber insurance renewal prompted this, an external test plus a clean report is often what is actually being asked for.

Move to internal testing when you have a mature perimeter, when you hold data whose compromise would be serious, or when you want to know what a successful phishing email would actually cost you. If your organisation runs Active Directory and has never had an internal test, there are findings waiting. There always are.

What about cloud?

If most of what you run lives in Microsoft 365, Azure or AWS rather than on servers you own, neither test is the right first purchase. Cloud environments fail through misconfiguration — over-permissive identity roles, public storage, absent conditional access, disabled logging — and those are found by reviewing configuration against a benchmark, not by attacking a network perimeter.

A cloud configuration review is the equivalent exercise for that environment.

Getting the scope right

To scope either test we need to know roughly what exists: how many external IPs are live, how many internal hosts and subnets, how many physical locations, and whether the network is segmented. You do not need exact figures to start the conversation — part of an external test is discovering assets you did not know about.

Both are covered on our infrastructure penetration testing page, with what is included at each level. If you would rather just describe your environment and be told what makes sense, get in touch and we will give you a straight answer — including if the answer is that you need something else.