Internal or External Penetration Testing: Which Do You Need?

External penetration testing asks whether somebody on the internet can get in; internal penetration testing asks how far they get once they have, usually starting from a standard user account. Most organisations buy only the first, and the second is usually where the surprises are.

What external testing covers

Everything reachable from outside your network: the websites, the applications, the VPN endpoint, the mail gateway, whatever is exposed on your public addresses, and increasingly whatever sits in a cloud account with a public endpoint nobody remembered creating.

It is the right first purchase because it maps to the most common attack: somebody with no access trying to gain some. It is also the easier one to arrange, because nobody has to be let inside anything.

What external testing cannot tell you

How far somebody gets after the first step. That first step is very often not a technical exploit at all. It is a phished credential, a reused password, a laptop, an outside supplier's account that should have been closed. None of those are things an external test can simulate, and all of them land the attacker exactly where an internal test starts.

The two side by side

	External	Internal
Question answered	Can an outsider get in?	How far does one foothold go?
Starting point	The internet, with no access	A standard user account on a normal segment
How the tester connects	From the internet	A VPN account, a jump host or a small device on the network
Typical findings	Exposed services, unpatched edge devices, weak authentication on public logins	Over-privileged accounts, open shares, flat networks, directory weaknesses
Typical report	Often short on a maintained perimeter	Usually long the first time

What internal testing finds

The findings are consistent enough across organisations to list. A tester dropped onto a standard user account and a normal network segment typically finds some combination of:

• Service accounts with far more privilege than the service needs, and passwords that have not changed since the system was installed.
• Shares readable by everybody containing credentials, configuration files or exports of data nobody remembers making.
• Flat networking, where a workstation can reach the database directly.
• Administrative interfaces on internal hosts with default or shared credentials.
• Legacy systems kept alive for one department, unpatched because patching them breaks the one thing they do.
• Monitoring that watches the perimeter attentively and the interior not at all.

None of that is exotic. All of it is the difference between one compromised laptop and a bad quarter, and most of it runs through the directory, which is why an Active Directory penetration testing checklist covers so much of a typical internal engagement.

Assumed breach, and why it is efficient

The most useful form of internal testing does not try to get in first. It starts from a standard user account, granted deliberately, and asks how far that goes. This is sometimes called assumed breach, it is grey box testing by another name, as black box, grey box or white box explains, and it removes the least interesting part of the exercise.

It is efficient because the initial access step is both the least surprising and the most expensive to simulate properly. Buying two days of somebody trying to phish your staff tells you less than four days of somebody demonstrating what a single successful phish would cost you.

The report reads differently, and budget for that

An external report on a maintained perimeter is often short. A first internal report is usually long, because the interior of an organisation accumulates decisions that were reasonable individually and are uncomfortable in aggregate.

Plan for the volume before it arrives. Decide in advance who triages, what your severity thresholds mean in working days, and that findings will be grouped by cause rather than counted. Fifty findings that are really six patterns is a manageable piece of work; fifty tickets is not, and the difference is entirely in how they are written up.

Tell the team what is coming, too. A long internal report lands badly if people read it as an audit of their competence rather than the expected result of years of trade-offs, and a defensive team is a slower one to remediate.

Cloud has moved the boundary

The internal and external distinction was clean when internal meant a building. In a cloud estate the equivalent question is what an identity can reach: a compromised pipeline credential, an over-permissive role, a storage bucket readable by any authenticated principal rather than only yours.

If your systems live in a cloud account, the internal test worth buying is usually a review of identity and permissions rather than a network sweep, and firms differ in whether they treat that as internal testing or as a separate configuration review. Ask, because the words are used inconsistently.

What to buy, in what order

If you can only buy one, buy external, because the perimeter is where the automated attacks are and fixing it is the cheapest risk reduction available.

If you can buy two things, buy external annually and internal once, and expect the internal report to be longer and less comfortable. Do not read that length as a verdict on the team: the interior of almost every organisation is softer than its edge, because that is where the trade-offs were made deliberately and then never revisited.

If you hold other people’s data, do the internal one sooner. The question a regulator or a customer will ask after an incident is not whether your perimeter was tested. It is what the attacker could reach once past it.