Internal vs External Penetration Testing: Do You Need Both?

An external penetration test attacks your internet-facing perimeter from outside. An internal test assumes the attacker is already in, through a phished laptop, a reused VPN credential or a contractor's device, and measures how far they get from there. PCI DSS settles the question for anyone handling cardholder data: Requirement 11.4.2 mandates internal testing at least every 12 months and after significant change, and 11.4.3 says the same for external testing. For everyone else the answer is conditional, and the condition is not budget: a cloud-only company with no office network, no VPN and no directory usually gets more from a cloud and identity assessment than from a classic internal network test, while any company with offices or Active Directory needs both. The two tests find almost entirely different problems, so one is not a discounted substitute for the other.

Below: what each test simulates, what an internal test finds that an external one structurally cannot, the one framework that removes your discretion, and the cloud-native exception stated plainly enough to act on.

Key takeaways

• External testing answers "can someone get in from the internet"; internal testing answers "what happens after someone does".
• PCI DSS 11.4.2 and 11.4.3 require both at least every 12 months and after significant change. That is not a recommendation.
• Internal testing normally starts from assumed breach, because waiting for the tester to phish someone spends your budget on reconnaissance you already know the answer to.
• A cloud-native company with no corporate network should usually buy a cloud and identity assessment instead of a traditional internal test, not in addition to it.
• If you can only buy one this year and you are not bound by PCI, buy the external test, then fix what it finds before spending anything else.

What each test actually simulates

An external test takes the position of an attacker with no access and no credentials. The tester enumerates what you expose to the internet: web applications, VPN concentrators, mail infrastructure, remote access portals, forgotten staging environments and whatever a subdomain sweep turns up. Then they attempt to get through. The most common serious finding is not an exotic exploit; it is a system nobody remembered was exposed, or a login portal without multi-factor authentication.

An internal test takes the position of an attacker who is already inside the perimeter. The tester is placed on your network, or given a standard employee workstation and account, and works outward from there. The question is not whether they can get in. The question is what your environment lets them reach once they are.

Those are genuinely different exercises. A perimeter that holds beautifully can sit in front of a flat internal network where a single compromised laptop reaches the finance file share, the backup server and the domain controller. That is the normal case, not the pathological one, and it is invisible from outside.

Assumed breach: where an internal test starts

Most internal engagements begin from an assumed-breach position, meaning the tester is handed the foothold rather than earning it.

The reasoning is economic. Getting an initial foothold is the part of an attack that a real adversary can retry indefinitely and cheaply, using phishing, credential stuffing against reused passwords, or an unpatched edge device. Paying a tester by the hour to replicate that is spending your budget on the least uncertain part of the story. NIST SP 800-115 treats the discovery and attack phases as distinct precisely because the value differs between them.

Vulnerability exploitation is now the leading initial access vector, present in 31% of breaches according to the Verizon DBIR 2026. Assumed breach does not deny that. It concedes it, and spends the engagement on the question that is actually open: given that someone gets in eventually, how bad is the next hour.

If you specifically want to test whether the foothold is achievable, that is a different engagement with a different objective, and it is closer to a red team than a penetration test. We cover the distinction in red team versus penetration test.

What an internal test finds that an external test cannot

Four categories, roughly in the order we see them.

Directory attack paths

Active Directory accumulates permissions the way a garage accumulates boxes. Service accounts with domain admin rights nobody dares change, nested group memberships that grant more than anyone intended, delegation settings from a 2019 project. Directory attack paths are a chain of individually defensible permissions that add up to domain compromise, and none of the chain is visible from the internet.

Flat networks and missing segmentation

Whether a workstation VLAN can reach the database subnet, whether the guest wireless network is genuinely isolated, whether the finance systems sit behind anything at all. If you rely on segmentation for compliance scope, that isolation needs its own test, which for PCI is a distinct requirement covered in PCI segmentation testing.

Credential material lying around

Passwords in scripts, in group policy preferences, in a shared drive spreadsheet, cached on a workstation. Internal testers find these constantly, and they are the mechanism that turns one compromised laptop into domain-wide access.

Internal applications nobody threat-modeled

The intranet tool built in 2020, the reporting dashboard with a shared password, the printer web interface with default credentials and a stored scan-to-email account. Nobody exposes these to the internet, so nobody tests them, so they are exactly what an internal attacker uses.

PCI DSS is the framework that answers this for you

If you store, process or transmit cardholder data, the discussion above is interesting but not decisive. PCI DSS Requirements 11.4.2 and 11.4.3 make both tests mandatory at least every 12 months and after any significant infrastructure or application change, 11.4.1 requires you to have a documented methodology including your own written definition of significant change, and 11.4.4 requires exploitable findings to be corrected and the fix verified by retesting.

We still see companies arrive at a PCI DSS assessment with an external test only, having assumed the internal requirement was aspirational. A QSA will flag it, and the remediation is buying the test you skipped, on a deadline, at whatever the calendar allows. The full 11.4.x family, including segmentation cadences, is laid out in how often to run a penetration test.

Other frameworks are looser. SOC 2's criteria never require a penetration test; the words appear only in a point of focus under CC4.1, which the AICPA says need not be addressed. Auditors expect a test and rarely dictate its position. HIPAA requires a periodic evaluation without specifying the form. That looseness is why the conditional answer below matters.

The cloud-native exception

Here is the answer the ranking pages do not give, because most of them sell both tests.

If your company has no office network, no VPN, no Active Directory and no on-premises servers, and your production environment is a cloud account with infrastructure defined in code, then a traditional internal network penetration test has very little to attack. A tester placed inside a virtual private cloud with no lateral targets will produce a short report, and you will have paid for the discovery of that fact.

The equivalent risk for that company is in identity and configuration: roles that can assume other roles, service account keys checked into a repository, storage buckets readable by more principals than intended, a metadata service reachable from an application that accepts user-supplied URLs. A cloud and identity assessment goes after those directly. The provider rules that govern that testing, and what a cloud-scoped engagement covers, are in cloud penetration testing.

Two honest qualifications. First, the moment you have an office with shared infrastructure, a site-to-site VPN, or a directory that governs cloud access, the traditional internal test is back on the table. Second, hybrid environments are the common case and they need both, because the interesting attack path is usually the one that crosses between them: a corporate identity that also grants cloud console access.

If you can only buy one this year

Not everyone has budget for both, and the sequencing advice is straightforward.

Buy the external test first if you are not bound by PCI. It covers the surface that faces the population of attackers who are not targeting you specifically, which is most of them, and it is the test whose findings are most likely to be actively exploited before your next engagement.

Then fix what it finds before buying anything else. An internal test run against an environment with an unremediated external finding is a report with a known preamble.

And the concession that costs us work: if the external test comes back clean and your internal environment is three laptops and a cloud account, do not buy the internal test to fill a line item. Put the money into logging, multi-factor authentication coverage and an asset inventory, then test again next year with something worth testing. A firm that pushes you to buy both regardless of what you run is optimizing for its own scope, not your risk.

Where Top Floor fits

Our penetration testing practice runs both, and the scoping call decides which you need rather than assuming the answer is both. Internal engagements start from an assumed-breach position by default because that is where the value is, and the rules of engagement state exactly where the tester is placed and what is out of bounds.

Where the driver is PCI DSS, we scope the engagement against the cardholder data environment as assessed, so the report answers the requirement your QSA will actually read.

How to decide this week

Answer three questions in writing. Do you have an office network, a VPN or a directory service? Do you store, process or transmit cardholder data? Can a compromised employee laptop reach production?

If the answer to the second is yes, establish your validation type before you buy either engagement, because that is what decides whether Requirement 11.4 is in your scope at all. A Report on Compliance carries it and so does SAQ D; the lighter questionnaires each carry only a subset of PCI DSS, and storing, processing or transmitting cardholder data does not on its own settle which one you are eligible for. Work out which eligibility criteria you meet, confirm the validation type with your acquirer in writing, and read the 11.4.x section of the questionnaire you are actually filling in. Which PCI SAQ do I need is that decision logic. Where 11.4 is in scope, you need both tests annually and the discussion is over. If the answer to the first is no and the answer to the third is no, price a cloud and identity assessment alongside any internal test you were considering, and compare what each proposal says it will look for.

Then check when your last external test was. If it is older than twelve months, that is the engagement to book, whatever else you decide.

Frequently asked questions

Does PCI DSS require both internal and external penetration testing?

Where Requirement 11.4 is in your validation scope, yes. Requirement 11.4.2 requires internal penetration testing at least once every 12 months and after any significant infrastructure or application change, and Requirement 11.4.3 imposes the same cadence on external testing. The qualifier matters: a Report on Compliance and SAQ D carry the 11.4.x family, and the lighter self-assessment questionnaires carry only a subset of PCI DSS, so confirm your validation type with your acquirer before concluding that you owe two annual tests or that you owe none. Requirement 11.4.1 additionally requires a documented testing methodology that includes your own written definition of significant change, and 11.4.4 requires exploitable vulnerabilities found during testing to be corrected and the correction verified by repeating the test. An external test alone does not satisfy the requirement, and this is one of the more common findings when a QSA reviews testing evidence.

What does assumed breach mean in an internal penetration test?

It means the engagement starts with the tester already holding a foothold, typically network access plus a standard employee account, rather than requiring them to earn one through phishing or an external exploit. The reason is economic: gaining an initial foothold is the part of an attack a real adversary can retry cheaply and indefinitely, so paying a tester to replicate it consumes hours that could go toward the open question, which is how far the attacker gets afterward. If you specifically want to test whether initial access is achievable, and whether anyone notices, that is a red team objective rather than a penetration test objective.

Can a cloud-only company skip the internal penetration test?

Frequently, yes, if there is genuinely no corporate network, no VPN, no directory service and no on-premises infrastructure. A tester placed inside a cloud network with no lateral targets produces a thin report. The risk for that profile sits in identity and configuration instead: over-permissive roles, leaked service account credentials, storage readable by unintended principals, and a metadata service reachable through server-side request forgery. A cloud and identity assessment targets those directly. Once an office, a site-to-site VPN or a directory enters the picture, the traditional internal test becomes worth buying again.

Which should we buy first if we can only afford one?

The external test, unless PCI DSS binds you, in which case you owe both anyway. External testing covers the surface exposed to opportunistic attackers who scan the internet rather than choosing targets, and its findings are the ones most likely to be exploited before your next engagement. Remediate what it produces before buying anything further, because an internal test run against an environment with a known unfixed external exposure starts from a conclusion you already have.