Internal vs External Penetration Testing: What's the Difference?

What is Penetration Testing as a Whole?

Penetration testing puts ethical hackers against your systems before attackers do. They probe old servers, test for compromised credentials, and trace every viable path into your network. Whether that means external network testing against your internet-facing assets, or internal pen testing to map what happens after access is already gained, the goal is the same: expose real vulnerabilities before someone else exploits them.

Internal vs. external network penetration testing

External penetration testing answers one question: can an attacker get in? Internal penetration testing answers the harder one: what happens if they do?

Both tests evaluate your network. Neither replaces the other. External testing targets every asset your organization exposes to the internet. Internal testing starts from inside your network and maps how far an attacker with a foothold can actually go. This page explains what each covers, which you need first, and how to use both to build a defensible environment.

What external network penetration testing covers

External testing evaluates every asset your organization exposes to the internet. The test is scoped to public-facing infrastructure, which includes:

• IPv4 ranges and individual IPs reachable from outside your perimeter.
• Domains and subdomains, including DNS configuration, DMARC settings, and subdomain takeover exposure.
• Internet-facing servers, firewalls, and VPNs.
• Cloud-hosted assets with public exposure: EC2 instances, API gateways, web application firewalls, S3 or Blob storage buckets, and load balancers.

Testers approach your environment the way an attacker would before they have any access at all. They scan for open ports, probe exposed services, look for unpatched software, test authentication mechanisms, and attempt to gain initial access through any available path.

What external testing finds

Common vulnerabilities an external test surfaces:

• Services left exposed on non-standard ports.
• Outdated software versions with known exploits running on internet-facing hosts.
• Misconfigured DNS records that enable subdomain takeover.
• VPN appliances and firewalls running vulnerable firmware.
• DMARC or SPF misconfigurations that allow email spoofing.
• Authentication bypass vulnerabilities on login portals visible from the internet.
• Cloud assets with public-facing storage buckets or misconfigured access policies.

What external exposure looks like in practice

A SaaS company runs its customer portal behind a load balancer. Testers identify a legacy server still registered under a subdomain that the infrastructure team forgot to decommission after a migration. The server runs an unpatched version of a common web framework. Through that server, testers establish an initial foothold. That vulnerability did not appear in any internal scan because internal tools were not configured to reach it. External testing found it in the first day of reconnaissance.

That is the question external testing answers: can an attacker get in? In this case, yes, through a server no one remembered existed.

What internal network penetration testing covers

Internal testing starts from an assumed-breach position. Testers operate from inside your network, the same position a compromised employee device, a VPN-connected contractor, or an attacker who has already cleared your perimeter would occupy.

The test maps how far that access can be extended: through lateral movement, privilege escalation, and exploitation of trust relationships between systems.

Internal testing covers:

• On-premises Active Directory environments, including domain trusts, Kerberos configurations, and privileged account exposure.
• Microsoft Entra ID (formerly Azure AD) and hybrid identity environments.
• Internal servers, databases, and file shares accessible from within the network.
• Cloud environments accessed from inside the network: AWS, GCP, and Azure IAM configurations and segmentation between VPCs or VNETs.
• Network segmentation: whether a compromised segment can reach systems it should not.
• Endpoints and lateral movement paths between workstations and servers.
• Privileged accounts, service accounts, and overpermissioned users.

What internal testing finds

Vulnerabilities that commonly surface in internal testing:

• Active Directory misconfigurations that allow any domain user to extract credentials.
• Service accounts with domain admin privileges that have never been rotated.
• Flat network architecture where a compromised device in one segment can reach critical databases in another.
• NTLM relay opportunities in environments that have not enforced signing.
• Unpatched internal servers not visible from the internet but reachable from any internal workstation.
• IAM policies in cloud environments that allow a compromised EC2 instance to assume roles with excessive permissions.
• Stale accounts that were not deprovisioned after an employee departure.

What internal exposure looks like in practice

A standard domain user account, provisioned as the assumed-breach starting position, escalated to domain admin in under four hours through a combination of unconstrained delegation on a legacy server and an NTLM relay attack that had not been addressed since the Active Directory environment was last audited. The organization had a clean external test six months prior. No attacker had gotten in through the perimeter. But the internal question, what happens if they do, had never been tested. The answer was: full domain compromise in half a day.

That is what internal testing answers. Not whether someone can get in. What happens if they do.

Side-by-side comparison

How testing methodology applies to each type

The black-box, gray-box, and white-box distinction is a separate decision from internal or external scope. It controls how much information testers start with.

Black-box: Testers start with nothing. No credentials, no network diagrams, no inside knowledge. This approach mirrors an opportunistic external attacker scanning for any available entry point. It is the standard methodology for external tests.

Gray-box: Testers receive limited access: a standard user account, a VPN credential, or a workstation on the internal network. They do not have administrative visibility. This approach often surfaces the highest-impact vulnerabilities in internal testing because it replicates the exact position of a compromised employee or contractor. An account that appears limited at first can unlock far more than expected when tested by someone who knows where to push.

White-box: Testers receive full network diagrams, architecture documentation, and access credentials. This approach skips reconnaissance and focuses testing time on the highest-risk areas. It is most useful for internal tests where the goal is coverage depth over adversary simulation.

For external tests: black-box is standard. For internal tests: gray-box is the most realistic and most commonly used starting point. White-box internal testing makes sense when you need to validate specific controls rather than simulate an attacker's path.

Which test do you need?

External testing answers "can someone get in?" Internal testing answers "what happens if they do?" A mature security program requires both answers. But they are not equal starting points.

Start with external

External testing is the correct first test in every new security program. Attackers scanning for targets start with what is publicly visible: web applications, exposed services, and internet-connected infrastructure. If you have not tested your external perimeter, you do not yet know whether you have gaps an attacker could use to establish that first foothold.

Run external testing first if:

• You have not run a penetration test before.
• You are pursuing SOC 2 Type 1 or Type 2 for the first time.
• You have recently added cloud infrastructure or new internet-facing services.
• You have not tested your perimeter since a major infrastructure change.
• An enterprise customer has asked for evidence of a recent external penetration test.

Add internal testing when you are ready to answer the harder question

Once your external surface has been tested, the next question becomes: if an attacker gets past the perimeter, or if a trusted insider acts maliciously, how much damage is possible?

Internal testing becomes necessary when there is a genuine concern about what happens after access is gained. A deprovisioned account that was not fully removed. A misconfigured server accessible from within the network but not from outside it. Devices connected without proper segmentation. Internal testing identifies those vulnerabilities before an attacker with a foothold does.

Organizations often move to internal testing after their first major enterprise customer, because enterprise security questionnaires increasingly ask about it. It also becomes relevant after an acquisition, when a newly connected network brings its own architecture and risk profile into your environment. After migrating to hybrid cloud infrastructure, the trust paths between on-premises Active Directory and cloud workloads create lateral movement opportunities that neither an external test nor a cloud configuration review will catch on its own. And as remote employees, contractors, and third-party integrations expand the internal attack surface, the assumed-breach question becomes more urgent, not less.

Run internal testing if:

• You have completed at least one external test and want to understand your blast radius.
• Your organization has more than 500 employees, where lateral movement risk across segments is material.
• You have completed an acquisition that added a new internal network to your environment.
• PCI DSS requirements apply: Requirement 11 explicitly requires internal penetration testing of cardholder data environments.
• You run a hybrid environment with on-premises Active Directory and cloud workloads.
• You have had a security incident and need to understand what an attacker with internal access can reach.

Can you run both at once?

Yes, and they can be run in the same engagement. They are scoped and reported separately. Running them together is common for organizations with mature security programs that want a complete picture. For organizations running their first test, external testing first produces a cleaner remediation priority list before expanding scope.

How often should you test?

Testing frequency depends on what changes in your environment, not on a fixed calendar. Trigger events that warrant a new test:

• Launching a new internet-facing application or service.
• Migrating infrastructure to a new cloud provider or region.
• Completing an acquisition that adds a new internal network.
• Expanding headcount significantly, particularly when new VPN access or Active Directory accounts are provisioned at scale.
• Onboarding a new integration with elevated access to internal systems.
• Receiving a vulnerability report from a third party that identifies exposure in your network.

For organizations under active compliance programs, quarterly or biannual testing is common. For organizations building a security program for the first time, annual testing is a reasonable starting cadence, with the expectation that any major infrastructure change warrants a retest of the affected scope.

How these tests map to compliance requirements

SOC 2: The Common Criteria section (CC6) requires organizations to demonstrate that logical access controls prevent unauthorized access to systems and data. External testing validates that your perimeter does not expose access to unauthenticated external parties. Internal testing validates that access controls inside the network prevent unauthorized escalation. If you are using a compliance automation platform such as Vanta or Drata, confirm the specific evidence requirements with your auditor before scoping your test, as accepted formats vary.

PCI DSS (Requirement 11): PCI DSS explicitly requires both external and internal penetration testing of systems in and around the cardholder data environment. Internal penetration testing is required at least annually or after any significant infrastructure or application upgrade. Segmentation testing, which confirms that networks required to be isolated actually are, is also a PCI DSS requirement and is typically included as an add-on to an internal network test.

ISO 27001: Penetration testing supports Annex A controls related to network security and access control. Both external and internal tests provide evidence for these controls.

HIPAA: The Security Rule requires covered entities and business associates to conduct a risk analysis that identifies vulnerabilities in systems containing electronic protected health information. Penetration testing is a recognized method for satisfying this requirement, though specific documentation expectations should be confirmed with your compliance counsel or auditor.

Best practices for running network penetration tests

Define scope before testing begins. For external testing, identify all public IPs, IP ranges, and domains in scope. For internal testing, identify the IP ranges in scope and confirm whether segmentation testing is included. Clear scope produces results you can act on. Ambiguous scope produces a test that leaves gaps.

Share what has changed recently. If you have migrated infrastructure, changed cloud providers, added new services, or onboarded a major integration in the past six months, tell your testing team. That context shapes where testers spend their time.

Do not substitute automated scanning for manual testing. Automated scanners identify known CVEs against external IPs. They do not chain vulnerabilities together, test authentication logic, simulate lateral movement, or apply judgment to what they find. Internal testing in particular requires a human tester navigating the environment as an attacker would. The vulnerabilities that create the most risk are almost always the ones that require context to find.

Retest after remediation. A vulnerability marked as fixed in a ticket is not the same as a vulnerability that has been verified closed. Retesting confirms that the fix was implemented correctly and that the exploit path is no longer viable. Do not consider a test complete until remediation has been validated.

Triage by exploitability and blast radius. External and internal tests together can produce a large number of vulnerabilities at varying severities. A remediation process that treats every vulnerability as equal delays closure on the items that carry the most real risk. Address the vulnerabilities where the combination of exploitability and potential damage is highest, first.

Running external and internal tests together builds a complete picture

Attackers do not care whether a weakness sits on your perimeter or inside your network. They follow the path that gets them to valuable data with the least resistance. External testing answers "can someone get in?" Internal testing answers "what happens if they do?" A mature security program needs both answers. Skipping external testing leaves you exposed at the point where every attack begins. Skipping internal testing leaves you unable to answer the question every enterprise security questionnaire eventually asks: if your perimeter fails, what is the blast radius?

The two tests are not alternatives. They are sequential layers. The first validates that your perimeter holds. The second validates that your internal environment limits the damage when it does not.

Software Secured conducts both external and internal network penetration testing using a fully manual, attacker-driven methodology. Tests are not automated scans with a report attached. Testers navigate your environment, chain vulnerabilities together, and document the actual paths an attacker would follow.

Internal tests start from a realistic assumed-breach position: a standard domain user, a VPN-connected endpoint, or a compromised workstation, depending on what is most relevant to your environment. External tests cover your full internet-facing perimeter, including cloud-hosted assets across AWS, Azure, and GCP. Retesting is included. Vulnerabilities are tracked through the Software Secured portal, where your team can monitor remediation status, map vulnerabilities to compliance controls, and confirm when issues are closed rather than assumed fixed.

Concerned about lateral movement risk after your last external test? Preparing for a PCI DSS audit? Just completed an acquisition? Get in touch to scope the right test for your environment.