External and internal penetration tests answer different questions. An external test asks what an attacker on the public internet can reach and exploit. An internal test asks what they can do once they already have a foothold: a phished laptop, a stolen VPN account, or a compromised supplier connection. Mixing the two up wastes budget and leaves a blind spot that auditors and underwriters notice.
This post explains what each engagement covers, when UK organisations typically need one or both, and how compliance frameworks treat the split. It is not a scan-versus-pentest essay; both of these are human-led tests of infrastructure from different starting positions.
At a glance
- External: internet-facing hosts, remote access, email security posture, public cloud edges.
- Internal: lateral movement, privilege escalation, Active Directory paths, segmentation gaps.
- PCI DSS v4.0.1 expects both perspectives for in-scope environments (requirements 11.4.2 and 11.4.3).
- Start with external if you have never tested and have public services; add internal when you care about post-breach blast radius.
- Many mature programmes run both on a recurring cycle, not as a one-off.
Two starting positions, two attack paths
External penetration testing
An external test starts outside your organisation. The consultant has no VPN, no domain account and no insider knowledge beyond what is public. Typical scope includes:
- Public IP ranges and DNS names
- Firewalls, reverse proxies and load balancers
- VPN and remote desktop gateways
- Mail and collaboration edges (including SPF, DKIM and DMARC posture where relevant)
- Internet-facing web applications and APIs that sit on those hosts
- Cloud management planes and other services exposed to the internet
The useful output is a map of realistic entry points: outdated services, weak authentication on remote access, misconfigured cloud storage, forgotten staging hosts still on a public IP. Severity reflects whether an unauthenticated or lightly authenticated outsider can move from curiosity to compromise.
Internal penetration testing
An internal test assumes the perimeter has already failed, or that an insider or contractor is the threat. The consultant usually receives a low-privilege network position (VPN, jump host or standard user account) and works outward. Typical focus areas include:
- Host and service enumeration from inside the LAN or VNet
- Credential reuse, Kerberos and Active Directory misconfigurations
- Privilege escalation on workstations and servers
- Lateral movement to file shares, databases and management tools
- Whether network segmentation actually isolates sensitive systems
- Paths from a standard user to Domain Admin or equivalent cloud roles
Findings here are often about blast radius. A single phishing success should not become full domain compromise in an afternoon. Internal tests show whether your detection, least privilege and segmentation claims hold under pressure.
Decision guide: which do you need first?
| Situation | Usually start with | Why |
|---|---|---|
| Never tested; public IPs and remote access in use | External | Highest chance an outsider can walk in |
| Recent phishing or malware on a staff device | Internal | You already had a foothold scenario |
| PCI DSS cardholder data environment | Both | Standard requires internal and external testing |
| ISO 27001 / SOC 2 evidence for customers | Often both over a cycle | Risk treatment should cover perimeter and insider paths |
| Cyber insurance questionnaire mentioning "independent testing" | Often external first | Underwriters commonly focus on internet-facing exposure |
| Major network redesign or AD migration | Internal (plus external if edges changed) | New trust relationships create new lateral paths |
| Small estate, limited budget this quarter | External, tightly scoped | One clear attack surface; expand next cycle |
There is no universal rule that "external always comes first". Organisations that invested heavily in perimeter controls but neglected identity and segmentation sometimes learn more from an internal engagement. Organisations with sprawling public cloud estates and forgotten assets usually learn more from external work.
Compliance and framework notes
Do not invent legal duties that do not exist. UK law does not name "annual penetration testing" as a blanket statutory requirement for every company. What does exist:
- PCI DSS v4.0.1: Requirement 11.4 expects a documented methodology (11.4.1), internal penetration testing at least annually and after significant change (11.4.2), and external penetration testing on the same cadence (11.4.3). Retesting of exploitable issues and segmentation validation sit in the surrounding sub-requirements. If you process card data in scope, both perspectives matter.
- ISO/IEC 27001:2022: Annex A control 8.8 (management of technical vulnerabilities) and related configuration controls expect you to treat identified risks. Penetration testing is a common way to evidence that treatment; the standard does not prescribe "external then internal" in the same way PCI DSS does.
- SOC 2: Trust Services Criteria are control-objective based. Many service organisations commission external and application testing because customers and auditors ask for independent evidence of how production systems behave under attack.
- NCSC guidance: The NCSC describes penetration testing as a way to gain assurance in your vulnerability assessment and management processes, not as the primary way to find vulnerabilities.
How attackers actually move
Think in paths rather than vulnerability counts.
- Internet to foothold: exposed management interface, weak VPN MFA, vulnerable CMS plugin, misconfigured object storage.
- Foothold to domain or tenant admin: reused local admin passwords, unconstrained delegation, over-privileged service accounts, flat networks.
- Admin to data: unencrypted file shares, databases reachable without jump hosts, backup stores without MFA.
External testing stresses path 1. Internal testing stresses paths 2 and 3. If you only ever fund path 1, you are hoping the first phishing email never lands. If you only ever fund paths 2 and 3, you may miss the open door that made the phishing email unnecessary.
Finance teams often care about SWIFT-adjacent or payment environments and segregation. Healthcare organisations care about clinical systems and NHS-aligned assurance. Media and technology firms often have complex SaaS and cloud edges. The split between external and internal still maps to the same two questions: how do they get in, and how far can they go?
What each test does not cover
- An external test is not a full web application or API assessment unless those applications are explicitly scoped with role-based credentials and methodology suited to application logic.
- An internal test is not a red team or a phishing campaign unless those are agreed separately.
- Neither test "proves you are secure". Each produces evidence of identified weaknesses within a defined window and scope.
- Attack Vector identifies security weaknesses and reports them clearly so your team can prioritise remediation. We do not take over day-to-day patching or claim to remediate your systems for you.
If you are unsure whether this year's budget should go to external, internal or a combined infrastructure engagement, start with a short scoping conversation about public IPs, remote access, Active Directory (or Entra ID) complexity, and any compliance wording you must satisfy.
Use the instant quote calculator for an indicative effort estimate, or email [email protected]. For typical UK ranges, see the pricing guide. Engagements start from £1,500 for a small, well-defined job.
FAQ
Is an external penetration test the same as a vulnerability scan?
No. A scan lists potential issues from signatures and configuration checks. An external penetration test uses scanning as one input, then manually validates and chains weaknesses to show real attack paths into or across internet-facing systems.
How long does each type usually take?
Small external scopes may be a few days. Internal work often takes longer because host counts, identity stores and segmentation add depth. Exact duration depends on IP counts, AD complexity and whether testing is remote or on site.
Do we need Active Directory to benefit from an internal test?
No. Cloud-only and hybrid estates still have lateral movement, privilege escalation and segmentation questions. The techniques differ; the question does not.
Will external testing disrupt production?
Rules of engagement, rate limits and change freezes reduce risk. Intrusive exploits against fragile production systems should be agreed in advance. Many organisations still prefer to run the most aggressive application checks in a staging environment with documented parity.
What should we ask suppliers about credentials?
Ask who will actually do the work, their individual certifications, and whether your procurement needs company CREST/CHECK. For Attack Vector, lead consulting credentials include Cyber Scheme Team Leader (CSTL), from The Cyber Scheme, and Chartered Cyber Security Professional (ChCSP), the UK Cyber Security Council's chartered title.
Can we combine internal and external in one engagement?
Yes. Combined infrastructure scopes are common and often more efficient because context transfers. Price and duration still track total attack surface, not a flat package label.
Suggested Resources
Ready to strengthen your security?
Talk to our consultants about your penetration testing requirements, or get a fast, transparent quote.