Internal or External Penetration Testing: What Each One Actually Tells You

External testing asks whether somebody on the internet can get in. Internal testing asks what happens once they have. Most organisations buy 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, a contractor 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.

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.

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, 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.