Internal vs External Penetration Testing: Scope, Methods And Which To Run First
David Roberts
Founder & CEO - ReVerb
10.22.2026
The difference in internal vs external penetration testing is where the attacker starts. An external test attacks your internet-facing systems from the outside with no access, while an internal test starts inside your network (or with a normal user account) and measures how far an intruder can get from there. Most organizations should run the external test first because it covers the systems anyone on the internet can reach, then follow with an internal or assumed breach test, and repeat both at least once a year.
This guide covers what each test actually examines, the findings that come up again and again, how segmentation testing fits in for PCI DSS, how to scope each engagement and how to get your team ready. If you are new to the topic, start with our explainer on what penetration testing is.
What Is External Penetration Testing?
External penetration testing simulates an attacker on the public internet who has no credentials and no foothold. The tester starts from your company name, domains and IP ranges, maps everything that answers from the outside and then tries to break in through it.
Typical targets include firewalls and VPN gateways, remote access portals, email and file transfer services, public web servers, DNS, exposed cloud services and any forgotten host that still has a public IP. You will also see this work sold as external infrastructure penetration testing, which usually means the network and service layer rather than deep testing of a web application’s business logic. Full application testing is normally a separate line item.
The question an external test answers is simple: can someone with nothing but an internet connection get into your environment, or get data out of it?
What Is Internal Penetration Testing?
Internal penetration testing assumes the attacker is already on your network. That might be a phished employee laptop, a malicious insider, a compromised contractor account or a device plugged into a conference room port. The tester connects through a physical drop box, a virtual machine you deploy, or a VPN account, and then tries to escalate privileges and move toward your most sensitive systems.
In a Windows shop, internal testing is usually dominated by Active Directory: how quickly can an unprivileged position become domain admin, and what does that unlock? The test also covers internal servers, databases, file shares, management interfaces, backup systems and the segmentation between network zones.
Both tests fall under the broader label of network penetration testing. Many vendors sell them together as one engagement with two phases, which is often the most efficient way to buy them.
Internal Vs External Penetration Testing At A Glance
Factor
External Penetration Test
Internal Penetration Test
Attacker position
Public internet, no credentials
Inside the network, often with a standard user account
Main targets
Firewalls, VPNs, remote access, email, public web servers, exposed cloud services
Active Directory, internal servers, databases, file shares, management interfaces, segmentation
Credential relay and poisoning, weak passwords, excessive privileges, AD misconfigurations, lateral movement paths
Access needed from you
IP ranges, domains, written authorization, provider permissions where required
Network connection (drop box, VM or VPN), a test user account, written authorization
Typical duration
Roughly 3 to 10 testing days depending on asset count
Roughly 5 to 15 testing days depending on network size and number of sites
Main question answered
Can an outsider get in?
If someone gets in, how much damage can they do?
Durations vary widely by vendor and environment. Treat the ranges above as a planning starting point, not a quote.
What An External Penetration Test Typically Finds
Exposed And Forgotten Services
The first phase of most external tests is discovery, and it regularly turns up assets the client did not know were public: an old staging server, a database port left open, a remote desktop service, a printer or camera management page, or a cloud storage bucket from a past project. Each one is a door that nobody is watching.
VPN And Remote Access Weaknesses
Edge devices have become a favorite entry point. The 2025 Verizon Data Breach Investigations Report, as summarized by Tenable, found that vulnerability exploitation was the initial access vector in 20% of breaches, and edge devices and VPNs made up 22% of the vulnerabilities exploited, up from 3% the year before. A good external test checks VPN appliance versions against known exploited vulnerabilities, tests whether MFA is enforced on every remote access path and looks for legacy portals that bypass it.
Misconfiguration And Weak Authentication
Other common external findings include default credentials on admin interfaces, login pages that allow unlimited password guessing, outdated TLS configurations, verbose error messages that reveal software versions, email security gaps (missing or permissive SPF, DKIM and DMARC records) and DNS records that leak internal hostnames. Many of these are low severity on their own but can combine into a working attack path.
Well-patched, tightly scoped perimeters often produce short external reports. That is a good result, not a sign the test was shallow, provided the tester shows the coverage they achieved.
What An Internal Penetration Test Typically Finds
Active Directory Attack Paths
Internal reports tend to be longer, and Active Directory is usually the reason. Testers look for service accounts with weak passwords that can be cracked offline (Kerberoasting), misconfigured certificate services templates, overly broad delegation settings, stale admin accounts and permission chains that let an ordinary user reach a privileged group in a few hops.
Credential Issues
Credentials are the thread that runs through most internal findings. Legacy name resolution protocols such as LLMNR and NBT-NS let an attacker on the same network segment capture password hashes, a technique MITRE documents as name resolution poisoning and SMB relay. Where SMB signing is not enforced, those captured authentications can be relayed to other hosts. Microsoft now requires signing by default only on newer releases (Windows 11 version 24H2 Enterprise, Pro and Education for inbound and outbound, and Windows Server 2025 for outbound, per Microsoft’s SMB signing documentation), so mixed estates remain exposed. Testers also find passwords in scripts, shares and configuration files, and the same local administrator password reused across many machines.
Lateral Movement And Flat Networks
Once a tester has one set of credentials, the question is how far they travel. Flat networks, where a workstation can talk directly to servers, backups and management interfaces, make that easy. The joint NSA and CISA advisory on the top ten cybersecurity misconfigurations lists lack of network segmentation, poor credential hygiene, improper separation of user and administrator privilege and insufficient access controls on network shares, all of which line up closely with what internal testers report.
Detection Gaps
An internal test also shows whether anyone noticed. If a tester ran password spraying, dumped credentials and reached domain admin without a single alert, that detection gap belongs in the report alongside the technical findings. The same advisory names insufficient internal network monitoring as a top misconfiguration.
[EXPERT QUOTE: White Knight Labs, John Stigerwalt, on the internal findings that most often lead to domain compromise]
What Is Assumed Breach Testing?
Assumed breach testing is a form of internal testing that skips the break-in. The tester is handed the same starting point a real attacker would get after a successful phish: a standard domain user account and, often, a typical corporate laptop or virtual desktop with your normal security tools running. From there, the goal is to reach agreed targets such as domain admin, a finance system or a sensitive data store.
The approach reflects a practical reality: given enough attempts, someone will click. Rather than spending test days on whether initial access is possible, assumed breach spends them on what happens next. It is closer to how ransomware operators actually work, and because the tester works from a managed endpoint, it also tests your EDR and monitoring.
Assumed breach sits between a classic internal test and a full red team exercise. A red team usually covers initial access, stealth and longer timelines, while assumed breach is shorter and more focused. Our comparison of red teaming vs penetration testing goes deeper on where the line falls.
Segmentation Testing And PCI DSS
If you handle card data, the internal vs external choice is partly made for you. PCI DSS v4.0.1 requirement 11.4 calls for both internal (11.4.2) and external (11.4.3) penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. Exploitable findings must be corrected and retested (11.4.4).
Segmentation testing is a separate requirement. If you use segmentation to shrink the cardholder data environment (CDE), you must prove that the controls actually isolate it. Requirement 11.4.5 sets this at least every 12 months for all entities and after changes to segmentation controls, and 11.4.6 tightens it to every six months for service providers. In practice the tester sits in each out-of-scope network zone and tries to reach CDE systems, documenting every port and protocol that should be blocked.
Segmentation testing is worth doing outside PCI too. It is the fastest way to check whether guest Wi-Fi, OT networks or development environments can reach production. Our guide to penetration testing for compliance covers the other frameworks that ask for testing.
How To Scope Each Test
Scoping An External Test
List every public IP range and domain you own, including cloud-hosted assets and subsidiaries.
Decide whether the tester should also run their own discovery to find assets you missed. This is usually worth it.
Confirm ownership of anything hosted by a third party and check the provider’s testing policy. Some providers allow testing of listed services without approval; others require notice.
Agree on whether password spraying against login portals is allowed, and at what rate, so you do not lock out real users.
Separate infrastructure testing from in-depth web application testing, and price them separately if both are needed.
Scoping An Internal Test
Count the sites, subnets and approximate number of live hosts. Vendors price mostly on size and number of locations.
Choose the starting point: unauthenticated network access, a standard user account (assumed breach), or both.
Name the crown jewels the tester should try to reach, such as domain admin, ERP, backup servers or a specific database.
List fragile systems that are off limits or need care, such as OT, medical devices or legacy servers.
Decide whether your security team should know the test is running. A quiet test measures detection; an announced one avoids wasted incident response.
Scope drives price more than anything else. Our penetration testing cost guide breaks down typical ranges for network tests by size and depth.
Which To Run First And How Often
Start With External In Most Cases
For most organizations, the external test comes first. The perimeter is reachable by everyone, it is scanned constantly by automated tools, and an exploitable VPN or exposed service is the kind of problem that gets fixed in days once it is found. External tests are also usually shorter and cheaper, which makes them a sensible first engagement with a new vendor.
When Internal Should Come First
There are good reasons to reverse the order. If your external footprint is tiny (a SaaS-heavy company with almost no public infrastructure), an external test may produce little, and an assumed breach test will tell you more. The same goes if you have just had a phishing incident, are preparing for a ransomware tabletop, or your board is asking what an intruder could reach. Mergers and acquisitions are another trigger: an internal test of the acquired network before you connect it to yours is cheap insurance.
How Often To Test
Once a year for each test is the common baseline, and it matches PCI DSS. Add a test after significant changes such as a new firewall or VPN platform, a cloud migration, a new office or a major AD restructure. Many teams also run continuous external scanning between annual tests, since the perimeter changes more often than the internal network. Scanning is not a substitute for a manual test, though; our guide to vulnerability scanning vs penetration testing explains why.
How To Prepare For Each Test
Get written authorization. A signed scope and rules of engagement document should list targets, dates, testing hours, exclusions and emergency contacts on both sides.
Tell the right people. At minimum, your IT lead and whoever runs your SOC or MSSP should know the test window and the tester’s source IPs, unless you are deliberately testing detection.
Set up access early. For internal tests, ship or deploy the drop box or VM and create the test account a week ahead. Delays here are the most common reason internal tests start late.
Clear out known issues. If you already know a system is unpatched, fix it first or tell the tester. Paying someone to rediscover known problems wastes test days.
Back up and check fragile systems. Confirm backups and identify anything that cannot handle scanning traffic.
Plan for remediation and retest. Book time for your team to fix findings and confirm whether the vendor includes a retest in the price.
What To Ask A Vendor
Will a named, experienced tester do the manual work, or is the engagement mostly automated scanning?
Do you run your own external asset discovery, or test only the list we provide?
For internal tests, how much of the time goes to Active Directory, and do you test from a user endpoint with our EDR running?
Is a retest included, and how soon after the report?
If we need PCI DSS evidence, will the report map to requirement 11.4 and include segmentation results?
Frequently Asked Questions
Is Internal Or External Penetration Testing More Important?
Neither replaces the other. External testing reduces the chance of a break-in, and internal testing limits the damage when one happens anyway. If budget allows only one this year, most organizations should start external, unless their public footprint is very small.
Can Internal Penetration Testing Be Done Remotely?
Yes. Most internal tests today run through a small physical device shipped to your office or a virtual machine deployed in your environment, which the tester connects to over an encrypted tunnel. On-site testing is still useful when physical or wireless security is in scope.
Is Assumed Breach The Same As Internal Penetration Testing?
It is a type of internal penetration testing with a specific starting point: a valid user account and usually a standard managed endpoint. A traditional internal test may start with only a network connection and no credentials.
Does PCI DSS Require Both Internal And External Testing?
Yes. PCI DSS v4.0.1 requires both at least every 12 months and after significant changes, plus segmentation testing if you rely on segmentation to reduce scope, every six months for service providers.
Conclusion
The internal vs external penetration testing decision is really about sequence, not choice. External testing closes the doors an outsider can reach today, and internal or assumed breach testing shows how much an intruder could take once inside. Run the external test first in most cases, follow with an internal test, and repeat both annually and after major changes.
