Internal vs External Penetration Testing

An external penetration test attacks your organization from the internet, the way an outside attacker would, and an internal penetration test assumes the attacker is already inside and works toward your domain. That difference in starting point drives everything else: the scope, the methods, the findings, and the price. An external test measures your internet-facing exposure, from the firewall and VPN to the web and mail servers an attacker can reach without credentials. An internal test measures what happens after the first host falls, which is the realistic failure most organizations face, and it usually ends at the Active Directory domain controller. This guide sets the two side by side, names the compliance rules that require each with exact citations, explains how scope drives cost, and answers which one to run first.

The core difference: where the attacker starts

The two tests answer different questions because they begin in different places. The external test starts with no access and asks how far an outsider gets from the internet. The internal test starts with a foothold, a workstation or a VPN connection, and asks how far an attacker gets once inside. Neither is a substitute for the other, because an organization can have a hardened perimeter and a soft interior, or the reverse. The standard that underpins both, NIST SP 800-115, the technical guide to security testing, treats external and internal testing as distinct activities for this reason.

Internal versus external, side by side

Setting the two tests against the same criteria is the fastest way to scope the work and budget for it. The table compares where each starts, what it covers, and what it costs.

The cost ranges come from our penetration testing cost analysis, where an external test is priced mostly on live host count, and an internal test is priced on Active Directory size, segmentation, and the number of sites.

What an external penetration test covers

An external penetration test maps and attacks everything an outsider can reach without credentials, and its first job is finding what you forgot you exposed. The tester starts with attack surface discovery: enumerating domains, subdomains, IP ranges, and the services listening on them, because the asset nobody remembers is the one that is unpatched. From there the work covers exposed services and their known weaknesses, remote access and VPN gateways, and email security, including whether a phishing message would land and whether sender authentication is configured. Cloud edges count too, since a misconfigured storage bucket or an exposed management interface is reachable from the internet like any other host. The one boundary to set in scope is web application testing: a full application test of login flows, business logic, and authorization is a separate, deeper engagement, and the external network test covers the application only at the surface. Our penetration testing services scope that line explicitly so you are not paying twice or leaving a gap.

What an internal penetration test covers

An internal penetration test starts from an assumed breach and tests how far an attacker moves toward the domain, which is where the real damage happens. The tester begins on a standard workstation or a VPN connection, with the access a phished employee would have, and works the paths that matter in a Windows environment. Active Directory is the main target. Kerberoasting, tracked as T1558.003 in MITRE ATT&CK, lets any domain user request service tickets and crack them offline for service account passwords. Active Directory Certificate Services misconfigurations, the ESC1 through ESC8 paths documented by SpecterOps in Certified Pre-Owned, can hand an attacker a domain administrator certificate. NTLM relay turns one intercepted authentication into access on another system. The tester chains these into lateral movement and privilege escalation toward the domain controller, and tests segmentation along the way: whether the cardholder network, the OT segment, or the admin tier is truly isolated or only nominally so. We cover these paths in depth in Active Directory security attack paths.

Compliance requirements, with citations

Several frameworks drive penetration testing, and only one of them is prescriptive about internal versus external, so read the control text rather than a vendor summary. The table gives the exact requirements.

PCI DSS is the strict one. Requirement 11.4 of PCI DSS v4.0.1, published in June 2024, requires both internal testing, under 11.4.2, and external testing, under 11.4.3, at least once every 12 months and after any significant infrastructure or application change. Where network segmentation isolates the cardholder data environment, 11.4.5 requires testing those controls every 12 months, and 11.4.6 tightens that to every 6 months for service providers.

SOC 2 names no penetration test, yet nearly every SOC 2 report is backed by one, because auditors read it as evidence that the organization monitors for vulnerabilities and enterprise customers ask for it directly. HIPAA today requires a risk analysis under the Security Rule, and the January 2025 notice of proposed rulemaking would add explicit testing frequencies, but as of October 2026 that proposal is not final, so the risk analysis remains the operative duty. We cover the proposal in our reading of the HHS fact sheet, which states the proposed intervals directly. ISO/IEC 27001:2022 does not use the word penetration test, but Annex A 8.8 on technical vulnerabilities and 8.29 on security testing in development and acceptance are what a certification auditor reads a test against.

How often should you run internal and external penetration tests?

Test at least once a year and after any significant change, and test more often if your risk or your rules demand it. The annual floor is the common baseline and the explicit PCI DSS rule for both internal and external tests. The "after significant change" trigger matters as much as the calendar: a new internet-facing service, a cloud migration, a domain redesign, or a merger all change the attack surface enough to justify a fresh test. Organizations with a high rate of change or a strong compliance driver move to a continuous model, where testing runs against assets as they change rather than once a year, which we compare in continuous versus annual penetration testing. The point-in-time annual test still has a place, but it leaves long windows untested between runs.

How scoping drives the price

Scope is what you are paying for, and five numbers set it. For an external test, the count of live internet-facing hosts is the main driver, because each responding host is more to enumerate and attack. For an internal test, the size of the Active Directory environment, the number of forests and domains, the number of physical sites, and the number of cloud accounts drive the hours, because each adds paths to map and segmentation to prove. A test scoped at a single site with one small domain lands at the bottom of the range, while a multi-site estate with several forests and a large cloud footprint runs toward the top. Give a tester an accurate asset inventory up front, because a scope built on a guess produces a quote built on a guess, and the correction usually comes mid-engagement when it is most expensive.

A worked example shows how fast scope moves the number. A single-site retailer with one Active Directory domain, 40 live external hosts, and no cloud footprint sits near the bottom of both ranges, with an external test around $4,000 to $6,000 and an internal test around $8,000 to $12,000. The same test for a firm with three sites, two forests, 300 external hosts, and workloads in two cloud accounts carries several times the hours, because the tester has more segmentation to prove and more identity paths to map. The tooling barely changes between the two; the people and the days do, and that is what the price reflects.

Deliverables, remediation, and retesting

The deliverable from either test is a report of findings with proof, ranked by risk, plus the fixes and a path to confirm them. Each finding should carry the evidence that it is real and exploitable, a severity rating applied the same way across the report, and a specific remediation rather than generic advice. The value is in the retest: after you fix the critical and high findings, the tester reruns them to confirm the fix held, and the report is only closed when they do. A test that hands over a findings list with no retest leaves you guessing whether the remediation worked. Build the retest into the engagement from the start, because buying it later as a separate day-rate task usually costs more.

Which penetration test should you do first?

Run the external test first if you have never tested, because the internet-facing attack surface is where an unprompted attacker starts and where exposure is cheapest to find and fix. The external test tells you whether an outsider can get in at all, and closing those gaps removes the most common entry path. Once the perimeter holds, the internal test becomes the higher-value engagement, because assumed breach is the realistic scenario: someone will eventually be phished, and the question is how far they get. If a compliance rule such as PCI DSS requires both, run them in the same annual cycle. If you are weighing whether an internal test or a full red team is the right next step, the difference is secrecy and objective, which we explain in what is red teaming.

Frequently asked questions

What is the difference between internal and external penetration testing? An external penetration test attacks from the internet with no credentials and measures your internet-facing exposure, such as exposed services, VPN gateways, and email security. An internal penetration test assumes the attacker is already inside, starts from a workstation or VPN, and tests how far they move through Active Directory toward the domain controller. The starting point is the core difference.

Does PCI DSS require both internal and external penetration testing? Yes. PCI DSS v4.0.1 Requirement 11.4 requires internal testing under 11.4.2 and external testing under 11.4.3, both at least once every 12 months and after any significant change. Where segmentation isolates the cardholder data environment, 11.4.5 requires testing those controls every 12 months, and 11.4.6 requires every 6 months for service providers.

Which should you do first, internal or external? Run the external test first if you have never tested, because the internet-facing attack surface is where an outside attacker starts and where exposure is cheapest to find and fix. Once the perimeter holds, the internal test becomes the higher-value engagement, because assumed breach is the realistic scenario. If a rule such as PCI DSS requires both, run them in the same annual cycle.

How often should you run a penetration test? Test at least once a year and after any significant change, such as a new internet-facing service, a cloud migration, a domain redesign, or a merger. The annual floor is the common baseline and the explicit PCI DSS rule. Organizations with a high rate of change or a strong compliance driver move to continuous testing, which runs against assets as they change rather than once a year.

Does SOC 2 require a penetration test? No. SOC 2 names no penetration test in the Trust Services Criteria. In practice nearly every SOC 2 report is backed by one, because auditors read it as evidence that the organization monitors for vulnerabilities and enterprise customers ask for it directly. A current test with evidence of remediation is what satisfies both the auditor and the buyer.

How much do internal and external penetration tests cost? An external network test runs $4,000 to $15,000, priced mostly on the count of live internet-facing hosts. An internal network test runs $8,000 to $30,000, priced on Active Directory size, segmentation, and the number of sites. Scope is the lever: an accurate asset inventory up front produces an accurate quote, and a guess produces a correction mid-engagement.

If you are scoping either test, our network penetration testing team will size it from your real asset inventory and build the retest in, so a finding is closed only once the fix is confirmed.