Internal and external penetration testing assess your security from two different starting positions. First, an external pentest simulates an attacker on the internet targeting your public-facing systems – websites, APIs, email gateways, and VPNs. By contrast, an internal pentest simulates an attacker who already has a foothold inside your network. This could be a compromised employee workstation, a rogue insider, or an attacker who bypassed the perimeter. Because real attacks often combine the two, most compliance frameworks expect both. So this guide explains what each one covers, the threat models behind them, and why you need both.
Table of contents
Comparison Table
| External Pentest | Internal Pentest | |
|---|---|---|
| Starting position | Unauthenticated attacker on the internet | Attacker with network access (compromised workstation or insider) |
| Primary targets | Web apps, APIs, email gateways, VPNs, DNS, public cloud resources | Active Directory, file shares, internal apps, databases, network segmentation |
| Threat model | External attacker, opportunistic or targeted | Insider threat, compromised credentials, post-breach lateral movement |
| Common findings | Exposed services, web app vulns, misconfigured cloud, weak authentication | AD misconfigurations, excessive privileges, unpatched internal systems, weak segmentation |
| Typical duration | 3-10 working days | 5-15 working days |
| Access required | None (tests from outside) | VPN access or on-site presence with a laptop on the network |
| Compliance drivers | PCI DSS 11.4.3, ISO 27001, GDPR, SOC 2 | PCI DSS 11.4.2, ISO 27001, NIS Regs, CBEST |
What Is External Penetration Testing?
An external pentest targets everything an attacker can reach from the internet. To begin, the tester starts with no credentials and no insider knowledge – just your domain name and public IP ranges. Then they enumerate your external attack surface: web applications, APIs, mail servers, VPN endpoints, DNS records, cloud storage buckets, and any other service exposed to the internet.
Next, the tester attempts to find and exploit vulnerabilities in these services. For example, this includes SQL injection in web applications, authentication bypass on APIs, and default credentials on management interfaces. It also covers misconfigured cloud storage, exposed development environments, and information leakage through DNS, headers, or error messages.
Ultimately, the objective is to determine whether an external attacker can breach the perimeter – and so gain access to internal systems, extract sensitive data, or disrupt services from the outside.
What Is Internal Penetration Testing?
An internal pentest starts from inside the network. Here, the tester receives a laptop connected to the corporate network (or VPN access) with the access level of a standard employee. From there, they attempt to escalate privileges, move laterally across the network, and finally reach high-value targets – domain admin, database servers, file shares containing sensitive data, or production systems.
In most internal pentests, the primary target is Active Directory. Indeed, AD misconfigurations are the single most common finding in internal assessments, and they frequently provide a path to domain admin within hours. For instance, common issues include Kerberoastable service accounts, excessive delegation, GPP (Group Policy Preferences) passwords, NTLM relay opportunities, and overly permissive access controls.
In addition, beyond AD the tester examines network segmentation (can you reach internal production systems from a guest network?), internal application security, database access controls, and file share permissions. Finally, they check whether sensitive data is accessible to users who should not have it.
Threat Models
External testing models the outside attacker. For example, this could be an opportunistic attacker scanning the internet for easy targets, a competitor conducting corporate espionage, or a state-sponsored group targeting your organisation specifically. In each case, the assumption is that the attacker has no prior access to your systems and therefore must breach the perimeter first.
Internal testing models the post-breach scenario. By contrast, the assumption here is that the perimeter has already been breached – whether through phishing, a compromised third-party, a supply chain attack, or a malicious insider. The question is simple: once inside, how far can the attacker go? For example, can they reach domain admin? Can they access the customer database? Can they move from the corporate network to production systems?
This second scenario is increasingly relevant, because perimeter breaches happen regularly. Phishing, in particular, remains the most common initial access vector. So if your security model assumes the perimeter will hold, internal testing reveals what actually happens when it does not.
What Each Test Typically Finds
Common External Findings
- Web application vulnerabilities (injection, XSS, IDOR, broken authentication)
- Exposed management interfaces (admin panels, database consoles, CI/CD dashboards)
- Default or weak credentials on public-facing services
- Misconfigured cloud resources (open S3 buckets, exposed Azure Blob storage)
- Information disclosure through DNS records, HTTP headers, error messages
- Outdated software with known CVEs on internet-facing services
- Weak TLS configurations
Common Internal Findings
- Active Directory misconfigurations (Kerberoasting, AS-REP roasting, delegation abuse)
- Path to domain admin from standard user in under 24 hours
- Weak network segmentation (flat networks, no isolation between environments)
- Credentials in file shares, scripts, or GPO preferences
- NTLM relay and coercion attacks (PetitPotam, PrinterBug)
- Excessive permissions on databases and file shares
- Unpatched internal systems (often neglected compared to internet-facing systems)
- Lack of monitoring on lateral movement indicators
Compliance Requirements
Most compliance frameworks require or expect both internal and external testing:
- PCI DSS 4.0 explicitly requires both. Requirement 11.4.2 mandates internal pen testing. Requirement 11.4.3 mandates external pen testing. Both at least annually and after significant changes.
- ISO 27001 expects testing of technical security controls across both internal and external attack surfaces.
- GDPR requires regular testing of security measures. The ICO guidance does not distinguish between internal and external but expects both to be covered.
- SOC 2 auditors expect evidence of both internal and external testing as part of CC4.1.
- DORA and CBEST require testing from both perspectives as part of threat-led penetration testing for financial institutions.
Why You Need Both
External testing tells you whether attackers can get in. Internal testing, on the other hand, tells you what they can do once inside. As a result, doing only one gives you half the picture.
For example, organisations that only test externally often discover during a real breach that their internal network was wide open – flat architecture, domain admin reachable from any workstation, and sensitive data accessible to all employees. Conversely, organisations that only test internally miss exposed services, misconfigured cloud resources, and the web application vulnerabilities that provide the initial foothold.
Therefore, the most realistic assessment combines both: the external test identifies how an attacker gets in, while the internal test shows what they achieve once there. In fact, some engagements chain the two – the tester starts externally, attempts to breach the perimeter, and then continues with internal testing from whatever access they gained.
FORTBRIDGE is a CREST-accredited penetration testing company. We deliver both internal and external pen tests across web applications, APIs, networks, and cloud environments. Get in touch to scope your next assessment.
Frequently Asked Questions
What is the difference between internal and external penetration testing?
In short, external pen testing simulates an attacker on the internet targeting your public-facing systems. Internal pen testing, by contrast, simulates an attacker who already has network access – a compromised workstation, stolen credentials, or a malicious insider. So external testing finds perimeter weaknesses, while internal testing finds what an attacker can achieve once inside.
Which is more important?
Both are necessary. On one hand, external testing prevents breaches from the outside. On the other, internal testing limits the damage when a breach occurs. Indeed, most real-world attacks start externally (phishing, exposed services) and then move laterally inside the network. Ultimately, testing both perspectives gives you the full picture.
Does PCI DSS require both?
Yes. Specifically, PCI DSS 4.0 Requirement 11.4.2 mandates internal penetration testing, while Requirement 11.4.3 mandates external penetration testing. Both are required at least annually and after significant changes.
Can a single engagement cover both?
Yes. In fact, many organisations commission a combined internal and external pentest in a single engagement. This is often more cost-effective than running them separately, and it also allows the tester to chain external findings into internal exploitation for a more realistic assessment.
What does an internal pentest find that an external test misses?
Typically, it finds Active Directory misconfigurations, weak network segmentation, lateral movement paths, credentials stored in file shares and scripts, excessive database permissions, and unpatched internal systems. Although these are invisible from outside the network, they are often the most impactful findings in a real breach.
About Post Author
