Internal vs External Penetration Testing: What You Need to Know
Internal vs external penetration testing comes down to one question: where does the attacker start? An external penetration test simulates an attacker on the internet targeting your public-facing systems, while an internal penetration test simulates someone who is already inside your network, such as a compromised laptop, a malicious insider or a visitor on your Wi-Fi.
Most Australian organisations need both, but not always at the same time or at the same depth. If you can only fund one test this year, start with the one that matches your biggest realistic risk and the evidence your auditors, insurers or customers are asking for.
In our own Network VAPT engagements across internal and external assets, findings have included critical authentication and access control flaws, as well as brute-force risks on SSL VPNs and weak firewall monitoring. Neither view alone shows you the full picture.
This guide explains how the two tests differ, which compliance frameworks ask for which, and how to scope both without paying for overlap. If you want the wider picture first, start with our vulnerability assessment and penetration testing (VAPT) services, then see how we deliver Network VAPT and Infrastructure VAPT.
The Short Answer: Which Test Do You Need?
Choose external testing if your main exposure is internet-facing systems such as websites, VPNs and email gateways. Choose internal testing if you need to know how far an attacker could move after a phishing click or a stolen credential. Choose both when a framework, customer or insurer expects them, or when a breach would be costly in either scenario.
Which Test Should You Start With?
Internet-facing exposure is your main risk
Start here if you run public websites, customer portals, VPN gateways or cloud-hosted services. It shows what an attacker can reach and exploit without any access to your network.
You are concerned about lateral movement and insiders
Start here if your perimeter has already been tested or you hold sensitive data on internal systems. It shows how far an attacker could travel after a single compromised account or device.
An auditor, insurer or customer expects both
Choose a combined engagement when PCI DSS applies or supplier assurance questionnaires ask for internal and external evidence. One scoped project is usually simpler than two separate ones.
The sections below compare the two tests side by side, map them to the frameworks Australian businesses are asked about most, and show how to scope both smartly.
Internal vs External Penetration Testing: Side-by-Side Comparison
The two tests use many of the same techniques, but they start from different positions and answer different questions. External testing asks what an outsider can break into. Internal testing asks what an insider, or an outsider who has already got in, can reach and take.
Use the table below to compare them on the points buyers ask about most. Scroll sideways on a phone to see every column.
| Factor | External Penetration Test | Internal Penetration Test |
|---|---|---|
| What it simulates | An attacker on the internet with no prior access | A malicious insider, a compromised device or an attacker who has already gained a foothold |
| Starting position | Outside your network, usually with only your domains and IP ranges | Inside your network, on a office LAN, VPN or test laptop, often with a standard user account |
| Typical targets | Websites, web applications, APIs, VPN and remote access gateways, mail servers, firewalls, public cloud services | Servers, workstations, Active Directory, switches, internal applications, file shares, network segmentation |
| What it commonly finds | Unpatched internet-facing services, weak or missing authentication, exposed admin panels, brute-force exposure, misconfigured firewalls | Weak passwords and reused credentials, excessive privileges, missing network segmentation, insecure internal services |
| Question it answers | Can someone break in from the internet? | How far could someone get, and what could they take, once they are inside? |
| Main cost drivers | Number of public IPs and domains, number and complexity of web apps and APIs, depth of manual testing | Number of hosts and network segments, Active Directory size, sites and locations, access level given to the tester |
| Best for | Organisations with a large public footprint, SaaS platforms and online services | Organisations holding sensitive data internally, or worried about phishing, ransomware and insider risk |
What Each Test Finds in Practice
The findings below come from the kinds of issues our team reports in real network engagements. They show why a clean result on one side does not guarantee the other.
Perimeter weaknesses
On external and server-facing assets, we have reported brute-force risks on SSL VPN logins and weak firewall monitoring. These are the gaps an outsider tests first, because a single weak login page can become the way in.
Weak internal segmentation
On internal switches and firewalls, we have reported weak Spanning Tree Protocol configurations, missing VLAN segmentation and MAC flooding risks. An external test would never see these, yet they decide how far an intruder can move.
What Affects the Cost of Each Test
Price follows scope, not the label on the test. A small external test of a few IP addresses can cost less than an internal test across several sites, while a test covering dozens of web applications and APIs can cost more than both.
The biggest cost levers are the number of assets, how much manual testing you want beyond automated scanning, and whether you include a retest to confirm your fixes. Ask every provider to quote against a written asset list so you can compare like with like.
Next, we look at which compliance frameworks ask for internal testing, external testing, or both.
How to Scope Internal and External Penetration Testing Together
The smartest way to scope both tests is to start from your assets and your compliance obligations, then decide the attacker’s starting point for each. One combined engagement under a single methodology usually reduces duplicated effort in kickoff, reconnaissance and reporting. It also shows the full attack path, for example how a weakness on a public server could lead to your internal network.
The diagram below shows the five-step process we recommend.
The Five Scoping Decisions in Detail
List every asset, including the forgotten ones
Build one inventory of public IPs, domains, web applications, APIs, cloud services, internal subnets and sites. Include old subdomains, test servers and retired VPN gateways, because these are often the weakest entry points.
Map each asset to a requirement
Link every asset to the framework, contract or audit scope that makes it matter, such as the cardholder data environment, your ISO 27001 scope or your SOC 2 system description. This keeps the test focused on what you must evidence.
The PCI Security Standards Council publishes penetration testing guidance on scope, methodology and segmentation checks. It was written before PCI DSS v4.0, so confirm requirement numbers against the current standard.
Choose the starting position for each test
Run the external test from the internet with no access, as a real outsider would. Run the internal test as an assumed breach, with a standard user account on an ordinary corporate network, so the result reflects a phishing click rather than a perfect-world scenario.
Agree the rules of engagement in writing
Document authorisation, testing windows, exclusions, emergency contacts and escalation steps. For cloud systems, check the provider’s penetration testing policy, and confirm who is responsible for any approvals before testing starts.
Run one methodology, one report and one retest
Ask for a single findings list ranked by business risk, with each issue mapped to the framework it affects. Include a retest in the quote, because auditors usually want proof that critical findings were fixed, not only found.
Common Scoping Mistakes to Avoid
Buying a scan and calling it a pentest
A vulnerability scan lists known weaknesses, while a penetration test proves which ones can actually be exploited and chained together. Auditors treat them differently, so check the proposal says manual testing.
Scoping by IP count alone
Ten IP addresses can hide a customer portal with dozens of roles and several APIs. Quote against applications and user roles as well, or the test will skim the surface where your data actually sits.
Testing once and never again
A report only describes the day it was written. Plan a retest after fixes and a fresh test after major changes such as a new application, a cloud migration or a network redesign.
The next section answers the questions buyers ask most about internal and external penetration testing.
Frequently Asked Questions About Internal vs External Penetration Testing
These are the questions Australian buyers ask us most often when they are deciding what to test and when.
What is the difference between internal and external penetration testing?
External penetration testing simulates an attacker on the internet targeting your public-facing systems, such as websites, VPNs and mail servers. Internal penetration testing simulates someone already inside your network, such as a compromised laptop or a malicious insider, and shows how far they could move. Together they show how an attacker could get in and what they could reach afterwards.
Do I need both internal and external penetration testing?
Most organisations benefit from both, and PCI DSS Requirement 11.4 requires both for entities in scope. For ISO 27001, SOC 2 and APRA CPS 234, the right mix depends on your risk assessment and audit scope. If your budget is limited, start with the test that matches your biggest risk and add the other as your scope allows.
How much does an internal or external penetration test cost?
Cost depends on scope rather than on whether the test is internal or external. The main drivers are the number of assets, how many web applications and APIs are included, how much manual testing you want, and whether a retest is part of the quote. Ask every provider to quote against a written asset list so you can compare offers fairly.
How often should penetration testing be done?
At least once a year and after any significant change to your network, applications or cloud environment. PCI DSS sets this cadence explicitly at every 12 months for both internal and external tests, and many auditors and insurers treat it as a sensible baseline for other frameworks. Higher-risk or fast-changing environments may justify more frequent testing.
How long does a penetration test take?
Most engagements take from several days to a few weeks, depending on scope. A small external test with few assets finishes sooner, while internal tests across several sites or large application portfolios take longer. Allow extra time for reporting and for a retest once your team has fixed the findings.
Content Reviewed By
Ketki Tidke
Cyber Security and GRC Lead Auditor
ISO 27001 Lead Auditor
ISO 27001 Certified
Ketki is a certified ISO 27001 Lead Auditor specialised in Governance, Risk and Compliance, with experience consulting public, private, and government clients. She evaluates threats, risk impacts, and regulatory requirements across multiple industry frameworks.
