What is the difference between internal and external penetration testing?
The difference is where the tester starts. NIST SP 800-115 describes external testing as conducted from outside the organization's security perimeter, usually as seen from the internet, and internal testing as working from the internal network while assuming the identity of a trusted insider or an attacker who has already got past the perimeter.
The two tests answer different questions. External: can someone on the internet get in? Internal: once someone is in, how bad does it get? An attacker after sensitive data usually needs both answers to be yes, which is why PCI DSS requires both tests.
How do internal and external tests compare?
| Aspect | External penetration test | Internal penetration test |
|---|---|---|
| Starting position | The public internet, no credentials | Inside the network, often with a standard user account |
| Simulates | An outside attacker looking for a first foothold | A malicious insider, or an attacker after phishing or a compromised device |
| Targets | Public IPs, web apps, APIs, VPN and remote access, mail, DNS | Servers, workstations, directory services, file shares, internal apps, the paths into sensitive segments |
| Typical findings | Exposed admin interfaces, unpatched internet-facing services, weak remote access, forgotten hosts | Credential reuse, privilege escalation to domain admin, flat networks, cleartext protocols, unpatched internal hosts |
| Main controls tested | Perimeter filtering, patching and exposure management | Segmentation, least privilege, credential hygiene, detection |
| PCI DSS v4.0.1 | Requirement 11.4.3 | Requirement 11.4.2 |
External tests are usually shorter, because the surface is smaller. Internal tests often produce the more severe findings, because controls behind the perimeter tend to be looser. NIST notes that internal testing is less limited than external testing since it happens behind perimeter defenses.
What is assumed breach, and where should an internal test start?
Assumed breach means skipping the question of how the attacker got in and starting the test from a realistic foothold. It is the normal model for internal tests. NIST SP 800-115 says internal assessors are often given access as general users, with the information users of similar privilege would have, and then try to escalate.
The starting point is a scoping decision, and it changes what the test measures. Choose one or more and write them into the rules of engagement:
- Network drop, no credentials. A laptop plugged into an office port or a guest VPN. Tests what an unauthenticated device can reach and whether it can capture credentials from network traffic.
- Standard employee account and managed laptop. Simulates a phished user. Tests privilege escalation, lateral movement, and whether endpoint detection notices.
- Compromised workload. A shell or container in a production subnet or cloud VPC. Simulates an exploited web server. For cloud-native companies with no office network, this is the realistic "internal" test.
- Third-party or contractor access. The VPN profile or SaaS role a vendor receives. Tests whether partner access is limited to what the contract needs.
- Out-of-scope segment. A host on a network that should not reach the cardholder data environment. This is a segmentation test.
A useful internal report states the starting point, then traces each path from it to the objective, for example "standard user on workstation segment to database administrator in the CDE in four steps."
What do compliance frameworks require?
PCI DSS names both tests explicitly; FedRAMP defines attack vectors that cover both positions; SOC 2 and ISO 27001 do not name either.
PCI DSS v4.0.1. Requirement 11.4.1 says the entity's penetration testing methodology must include "testing from both inside and outside the network," covering the entire CDE perimeter and critical systems, with both application-layer and network-layer testing. Then:
- 11.4.2: internal penetration testing is performed per the entity's defined methodology, at least once every 12 months, after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party, with organizational independence of the tester (not required to be a QSA or ASV).
- 11.4.3: external penetration testing, with the same five conditions.
- 11.4.4: exploitable vulnerabilities and security weaknesses found are corrected according to the entity's risk ranking, and penetration testing is repeated to verify the corrections.
- 11.4.5: if segmentation isolates the CDE, segmentation controls are tested at least every 12 months and after changes. 11.4.6 tightens this to every six months for service providers.
- 11.4.7: multi-tenant service providers must support their customers' external penetration testing.
The PCI SSC's penetration testing guidance adds scope detail. The external test covers the exposed external perimeter of the CDE and critical systems, including remote access such as VPN connections and services restricted to individual external IPs. The internal test covers the internal CDE perimeter and critical systems, and may continue into the CDE once access is gained.
FedRAMP. The Penetration Test Guidance defines six mandatory attack vectors. "External to CSP Target System" is the external test, and its guidance says web application firewalls and similar blocking controls are bypassed to facilitate testing. "Tenant to CSP Management System" and "Tenant-to-Tenant" test from an inside position: a customer account trying to reach the provider's management plane or another customer's data.
SOC 2 and ISO 27001. Neither requires an internal or external test by name. Auditors look at whether the scope you chose matches the system described in the report.
Which one do you need?
Most organizations need both, weighted by where their risk sits:
- SaaS with no corporate network of note. A thorough external test of the application, API and cloud perimeter, plus an internal test from a compromised workload and from an employee's cloud console access.
- Company with offices and a directory service. Both, with the internal test starting from a standard user account.
- In PCI scope. Both, annually and after significant change, plus segmentation testing if you rely on it.
Whichever you run, the report and any attestation letter should say which positions were tested. "Penetration test completed" with no starting position tells a reviewer almost nothing. For the full list of test types, see types of penetration testing.
Common mistakes
- Treating an external vulnerability scan as the external penetration test. They are separate PCI requirements (11.3.2 and 11.4.3).
- Running the internal test from an administrator's machine, which skips the escalation the test exists to measure.
- Letting the WAF block the tester and calling the result clean. FedRAMP bypasses blocking controls for its external vector, and the PCI SSC's guidance encourages configuring active protection so it does not interfere, since the aim is to test the service itself. Whatever you choose, the report should say.
[ Sources ]
Written by Parameter · Last reviewed
