Choosing between internal and external penetration testing is one of the first scoping decisions UK organisations face when planning a security assessment. Get it wrong and you test the wrong things or pay for coverage you don't need. Get it right and you walk away with a clear picture of where your actual risks sit.

This guide covers what each engagement type includes, the attack paths they typically uncover, how to scope effectively, and how to avoid procurement mistakes that waste budget. Whether you're writing your first brief or refining an established programme, the aim is to help you procure the right test first time.

What External Penetration Testing Covers

External penetration testing targets your internet-facing attack surface: everything a remote attacker could discover and try to exploit without prior internal access. The goal is to find out how well your perimeter holds up against realistic outside threats.

Assets typically in scope:

• Public-facing web applications and APIs
• Email gateways and DNS infrastructure
• VPN endpoints and remote access portals
• Cloud-hosted services and storage (Azure, AWS, etc.)
• Firewalls, load balancers, and edge network devices

Common Attack Paths

External tests frequently uncover vulnerabilities that map to well-documented initial access techniques in frameworks like MITRE ATT&CK. Common findings include:

• Unpatched or misconfigured services exposed to the internet, giving attackers a direct route in
• Web application flaws like SQL injection, broken authentication, and insecure direct object references
• Weak or default credentials on externally accessible portals
• Information disclosure through verbose error messages, exposed metadata, or publicly indexed files
• Subdomain takeover where dangling DNS records point to decommissioned services

The Verizon Data Breach Investigations Report consistently shows that exploitation of public-facing applications and stolen credentials remain top initial access vectors. External testing directly validates your exposure to these.

When to Prioritise External Testing

External testing is usually the right starting point when you're launching or significantly changing a public-facing service, migrating infrastructure to the cloud, preparing for a compliance audit (PCI DSS, ISO 27001), or assessing your perimeter for the first time.

What Internal Penetration Testing Covers

Internal penetration testing simulates what happens after an attacker already has a foothold inside your network, or what a malicious insider could achieve. It starts from an assumed-breach position and focuses on how far an attacker could move laterally and what sensitive data they could reach.

If you're new to penetration testing more broadly, it's worth understanding the fundamentals before diving into internal scoping.

Assets and scenarios typically in scope:

• Active Directory environments and domain trust relationships
• Internal file shares, databases, and data stores holding sensitive information
• Network segmentation between business units, environments, or VLANs
• Privileged and service accounts with elevated permissions
• Endpoint controls like EDR, application whitelisting, and local admin policies

Common Attack Paths

Internal tests surface a different category of weakness, often related to configuration, access management, and network architecture rather than software vulnerabilities alone:

• Weak or reused passwords, especially for service accounts and local admin accounts
• Over-privileged user accounts granting unnecessary access to critical systems
• Poor network segmentation that allows unrestricted lateral movement between zones
• Kerberoasting and AS-REP roasting attacks against Active Directory
• Cleartext credentials stored in scripts, Group Policy Preferences, or shared drives
• Missing monitoring or alerting on privilege escalation and abnormal access patterns

When to Prioritise Internal Testing

Internal testing should be a priority when you need to understand the damage a compromised user or insider could cause, validate segmentation after architectural changes, test detection and response capabilities, assess Active Directory security in complex or legacy environments, or satisfy regulators who expect evidence of internal controls testing.

When You Need Both

Testing only one side of the boundary leaves a gap. External testing tells you whether an attacker can get in. Internal testing tells you what they can do once inside. Neither validates the full attack chain on its own.

A combined approach makes sense when:

• Your organisation processes sensitive personal data and must demonstrate appropriate security measures under UK GDPR. The ICO's guidance on keeping personal data secure references technical testing as part of a broader security programme.
• You want to model a realistic scenario from initial access through to data exfiltration or domain compromise.
• You're preparing for certification that expects both perimeter and internal assurance (certain ISO 27001 implementations, for instance).
• Previous external tests found routes into the network, and you need to understand post-compromise impact.

Running both in the same engagement window is often more cost-effective too, since the testing team can reuse reconnaissance findings and maintain context.

Designing the Scope Effectively

Poor scoping is the most common reason penetration tests disappoint. A well-defined scope keeps the testing team focused on what matters and makes findings actionable.

Collaborate Early

Good scoping needs input from risk owners (who understand what matters to the business) and technical teams (who understand the environment). Neither group has the full picture alone. Start this conversation before you approach suppliers.

Define Boundaries and Depth

Be explicit about:

• In-scope assets: IP ranges, domains, applications, user roles, physical locations
• Out-of-scope assets: production systems with zero-downtime requirements, third-party services you don't have authorisation to test
• Test depth: whether the engagement stops at discovery or includes exploitation and post-exploitation to prove impact
• Starting position: for internal tests, clarify whether the tester gets a standard user account, a VPN connection, a laptop on the corporate network, or nothing at all

Set Constraints and Windows

Some environments have periods where testing could cause disruption. Define these upfront: blackout periods (month-end processing, peak trading hours), whether denial-of-service testing is permitted, whether social engineering is in or out of scope, and how to handle notification and escalation if a critical vulnerability turns up mid-test.

Agree Reporting Standards

Specify what you expect in the final report. At minimum: findings mapped to a recognised severity framework like CVSS, clear remediation guidance with prioritisation, evidence of exploitation (screenshots, proof-of-concept details), and an executive summary suitable for non-technical stakeholders.

Common Procurement Mistakes

Even experienced teams fall into these traps.

Vague or incomplete asset lists. If you can't tell the supplier exactly what's in scope, they can't price or plan accurately. Incomplete inventories lead to under-testing or unexpected scope creep.

Choosing on price alone. Testing quality varies enormously. The cheapest quote may reflect a heavily automated scan rather than a skilled manual assessment. Understanding what a pen test should cost helps you benchmark quotes fairly.

Ignoring supplier credentials. For UK government work, CHECK accreditation from the NCSC is typically required. For commercial work, CREST certification is widely recognised as a quality benchmark. Verify individual tester qualifications, not just company-level accreditations.

Not defining success criteria. Without clear objectives, it's hard to judge whether a test delivered value. Decide what you want to learn before it begins.

Failing to plan for remediation. A report is only useful if findings get fixed. Make sure you have resource and budget for remediation before commissioning the test.

Testing too infrequently. A single annual test is a point-in-time snapshot. If your environment changes rapidly, you may need more frequent or continuous testing.

Key Pricing Drivers

UK penetration testing costs vary considerably. Rather than quoting fixed figures, it's more useful to understand what moves the price:

• Scope size: more IPs, applications, or user roles means more time.
• Environment complexity: a flat network with 50 endpoints is faster to test than a segmented enterprise with multiple AD forests, cloud tenancies, and legacy systems.
• Test depth: a vulnerability assessment takes less time than full exploitation and post-exploitation.
• Accreditation requirements: CHECK and CREST-certified testers command higher day rates, reflecting the cost of maintaining those credentials.
• Reporting and debrief needs: detailed technical workshops, re-testing after remediation, or board-level presentations all add time.
• Logistics: on-site internal testing involves travel and possibly accommodation. Remote internal testing via a pre-shipped hardware implant or VPN can reduce this.

When comparing quotes, make sure you're comparing like-for-like scope and methodology, not just the headline number.

Buyer's Checklist

Use this when planning and procuring a test:

• Defined clear business objectives (not just "find vulnerabilities")
• Identified whether internal, external, or combined testing is needed based on risk
• Compiled a complete, accurate asset inventory for the target scope
• Agreed test depth: discovery, exploitation, or full attack simulation
• Set constraints, blackout windows, and escalation procedures
• Specified reporting requirements including severity framework and remediation guidance
• Verified supplier accreditations (CREST, CHECK, or equivalent) and individual tester qualifications
• Confirmed whether authenticated testing is required and prepared test accounts
• Allocated internal resource for remediation after the test
• Planned a re-test to validate fixes

Sample Procurement Brief Structure

A well-structured brief helps suppliers respond accurately and makes comparing proposals straightforward.

1. Background and Objectives

Describe your organisation, the purpose of the test, and what you want to achieve. Be specific. "Validate the security posture of our new customer portal before go-live" is far more useful than "Test our security."

2. Scope Definition

List all in-scope assets (IP ranges, URLs, applications, environments). State explicitly what is out of scope. Define the assumed starting position for internal tests.

3. Test Type and Depth

Specify whether you require external, internal, or both. State whether exploitation and post-exploitation should be included. Note any specific scenarios you want tested, such as a compromised standard user or a rogue device on the network.

4. Constraints and Logistics

Cover blackout periods, permitted testing windows, whether on-site access is required or remote testing is acceptable, and any restrictions on techniques (no DoS, no social engineering, etc.).

5. Accreditation and Qualifications

Required certifications (CREST, CHECK, OSCP, or similar). Number and seniority of testers expected on the engagement.

6. Reporting and Deliverables

Expected report format and severity classification (e.g., CVSS v3.1). Executive summary requirements. Whether a technical debrief or workshop is needed. Re-test policy and timeline.

7. Commercial and Evaluation Criteria

Budget range or constraints (if you're willing to share). Evaluation weighting (e.g., methodology 40%, experience 30%, price 30%). Submission deadline and expected engagement dates.

Providing this detail upfront reduces back-and-forth, improves the quality of responses, and makes it easier to compare proposals fairly.

Bringing It Together

For most UK organisations, the choice between internal and external testing isn't either/or. It depends on your current risk profile, the maturity of your security programme, and what you're trying to learn. External tests validate your perimeter. Internal tests reveal post-breach impact. Together, they give you a realistic view of your organisation's resilience.

Invest time in scoping and procurement. A well-defined brief with clear objectives, accurate asset lists, and specified reporting standards will deliver better results than a loosely defined engagement, regardless of supplier. And the test itself is only valuable if you act on the findings.