If you’re scoping your first penetration test — or expanding an existing security program — one of the first decisions you’ll face is whether to start with an external assessment, an internal one, or both. It’s a reasonable question, and the answer depends on what you’re trying to protect and what risks concern you most.

This guide explains the practical difference between internal and external penetration testing, the scenarios where each is most valuable, and how to make the right call for your organization.

The Core Difference

The simplest way to think about this: external testing simulates an attacker who has no access to your environment. They’re on the internet, probing for ways in. Internal testing simulates an attacker who is already inside — whether through a compromised credential, a phishing email that succeeded, a malicious insider, or a contractor with network access.

Both represent real threats. They’re not mutually exclusive, and mature security programs typically run both. But understanding what each test actually examines helps you prioritize given your budget, risk profile, and compliance requirements.

—

External Penetration Testing

What It Tests

An external penetration test targets the systems and services your organization exposes to the internet:

  • Public-facing websites and web applications
  • Email infrastructure (mail servers, spoofing controls)
  • Remote access services (VPNs, Citrix, RDP gateways)
  • DNS configuration and zone transfer vulnerabilities
  • Cloud infrastructure exposed to the internet (S3 buckets, public APIs, exposed admin panels)
  • Network perimeter firewall rules and port exposure

The tester starts with no inside knowledge or access — only what an attacker with your company name and public footprint could discover.

What It’s Good For

External testing answers a specific question: can someone get in from the outside?

This is often the first test organizations run, and with good reason. Internet-facing systems are continuously probed by automated scanners and opportunistic attackers. If there are exposed services with known vulnerabilities, misconfigured cloud storage, or weak authentication on a remote access portal, an external test will surface them.

It’s also the most directly applicable test for many compliance requirements. PCI DSS mandates external penetration testing for cardholder data environments. SOC 2 auditors increasingly expect evidence of external assessments. CMMC Level 2 requires external network testing as part of the control assessment process for defense contractors handling CUI.

Limitations

An external test only tells you whether an attacker can breach your perimeter. It doesn’t tell you what happens if they do — or if someone is already inside. Organizations that pass an external pentest with flying colors sometimes assume they’re in good shape. The more uncomfortable question is what an attacker could accomplish once past the perimeter.

—

Internal Penetration Testing

What It Tests

An internal penetration test starts from a position of assumed access — typically a standard user account on the network, or in some engagements, simply a network connection point (a foothold on the internal LAN). From that starting position, the tester attempts to:

  • Escalate privileges to administrator or domain admin
  • Move laterally across the network to reach sensitive systems
  • Access high-value targets: domain controllers, financial systems, HR data, source code repositories, intellectual property
  • Identify credential exposure, misconfigured services, or unpatched internal systems
  • Test detection and response — does your SOC see what’s happening?

What It’s Good For

Internal testing answers a harder question: if an attacker gets in, how much damage can they do?

The honest answer at most organizations is: more than they’d like. Internal networks are often built for availability rather than security. Trust relationships between systems are broad. Older systems run unpatched because they “work fine.” Service accounts have excessive privileges because restricting them felt risky at the time.

An internal penetration test maps those paths to compromise before a real attacker does. It’s especially valuable for organizations that:

  • Have completed external testing and want to understand their next layer of risk
  • Are concerned about insider threats or third-party vendor access
  • Have undergone recent mergers, acquisitions, or significant network changes
  • Operate in regulated industries where lateral movement to sensitive data is a specific audit concern
  • Want to validate their detection and response capabilities under realistic conditions

—

How to Decide

If you’re working within a budget and need to choose one:

Start with external if:

  • You haven’t had any professional penetration testing done before
  • You have publicly-facing applications or web services handling customer data
  • You have a specific compliance requirement that calls for it
  • Your primary concern is reducing your internet-facing attack surface

Start with internal if:

  • You’ve already assessed your external perimeter
  • You’ve experienced a security incident that involved lateral movement or credential misuse
  • You have a complex internal network with legacy systems or broad trust relationships
  • You want to validate whether your SOC can detect real attacker behavior

Run both if:

  • You’re building or maturing a security program and want comprehensive coverage
  • You have compliance requirements that call for both (CMMC Level 2, for example, requires both network and application testing)
  • You’re in a high-risk vertical — healthcare, financial services, defense — where breach consequences are severe

—

A Note on Scope

Whether you choose internal or external testing, scope definition matters enormously. The value of a penetration test is directly proportional to the honesty of the scoping conversation — which systems are included, what the testing objectives are, and what success looks like beyond a generic vulnerability report.

A good penetration testing partner will push back on scopes that are too narrow to be meaningful. They’ll also help you understand which findings are critical versus which represent acceptable risk given your environment.

—

How Compliance Frameworks Specify Testing Types

If your testing decision is driven by a regulatory requirement, here’s how the major frameworks map to internal vs. external assessments:

CMMC Level 2: Defense contractors handling Controlled Unclassified Information (CUI) must satisfy CA.2.157, which requires testing security controls for operational effectiveness. Both external and internal assessments are expected. CMMC Level 3 raises the bar further with an explicit penetration testing practice (CA.3.162) requiring overt, covert, and targeted testing components — scope that typically requires both test types running in combination. See our full guide to CMMC penetration testing requirements.

SOC 2 Type II: The Trust Services Criteria don’t prescribe specific test types, but the monitoring and control effectiveness criteria (CC7.1, CC7.2) create an expectation of meaningful security testing over the audit period. Auditors increasingly ask for both external and internal testing evidence, particularly for cloud-hosted SaaS products where internal network segmentation and privilege controls are as critical as the external perimeter. See our SOC 2 penetration testing requirements guide.

HIPAA Security Rule: The risk analysis requirement (45 CFR 164.308(a)(1)) is interpreted to require assessment of all technical threats to ePHI — which includes both external attack vectors and insider threats or lateral movement paths within the network. Healthcare organizations are most commonly targeted through their patient portals (external) and through phishing that leads to internal lateral movement, making both test types relevant.

PCI DSS: Explicitly requires both external and internal penetration testing for cardholder data environment systems (Requirement 11.4). The external test covers systems facing the internet; the internal test covers the CDE network from the perspective of a compromised internal segment.

One consistent principle across all frameworks: if a compliance requirement calls for penetration testing, a scoped assessment that tests only your easiest-to-defend systems does not satisfy the spirit of the requirement. Scoping decisions should be made based on where sensitive data lives and how an attacker would realistically reach it — not on what’s most convenient to test.

For a full breakdown of what to look for when evaluating penetration testing vendors for compliance purposes, see our guide to how to choose a penetration testing company. And if you’re thinking about how often to schedule assessments beyond an annual cycle, our post on why annual penetration tests aren’t enough covers the case for more frequent testing.

—

Ready to Scope Your Assessment?

If you’re trying to figure out which type of test is right for your organization — or whether you need both — StrikeHaven can help you work through that decision before any contract is signed. We conduct external network and application testing, internal network assessments, and full-scope red team engagements for organizations across healthcare, financial services, technology, defense, and manufacturing.

> Tell us about your environment and we’ll recommend the right assessment scope →

>

> No commitment required. We’ll give you an honest recommendation on internal vs. external vs. combined based on your risk profile and compliance requirements.