What is the difference between external penetration testing and vulnerability scanning?

Vulnerability scanning is automated: a tool checks a target against a database of known vulnerabilities and reports what it finds. It is fast, repeatable, and useful for maintaining a baseline — but it only finds what it is programmed to look for, generates false positives, and cannot reason about how vulnerabilities interact. External penetration testing is manual and adversarial: a skilled tester approaches the target as an attacker, chaining together weaknesses that individually appear low-risk but combine to create a serious impact. Testers identify logic flaws, authentication bypasses, and business-level vulnerabilities that no automated tool would flag. Vulnerability scanning answers 'what is exposed'; penetration testing answers 'what can an attacker do with what is exposed'.

What are the 6 phases of an external penetration test?

An external penetration test follows six phases. Phase 1 — Planning and scoping: defining target systems, out-of-scope assets, testing methods, testing windows, rules of engagement, and escalation procedures. This phase also includes an onboarding call where the client walks the testing team through the platform. Phase 2 — Reconnaissance: passive and active information gathering about the target — DNS records, subdomains, exposed services, employee information, technology stack identification, and any publicly available data that an attacker would use to plan an attack. Phase 3 — Scanning and enumeration: active probing of target systems to enumerate services, open ports, running software versions, and potential entry points. Phase 4 — Vulnerability analysis and exploitation: identifying vulnerabilities confirmed through scanning and manually testing each, attempting exploitation to determine real-world impact and how far access can be extended. Phase 5 — Post-exploitation: demonstrating the impact of successful exploitation — what data is accessible, what further systems can be reached, and what the realistic business impact of a real attack would be. Phase 6 — Reporting and debrief: delivering a report covering executive summary, technical findings with reproduction steps and evidence, attack narratives showing how vulnerabilities chain together, risk prioritisation, and actionable remediation guidance. A debrief session walks through the findings with the client team.

What is the difference between external penetration testing and red teaming?

External penetration testing and red teaming both simulate adversarial attacks, but with different goals, scopes, and methods. External penetration testing is structured and time-boxed: testers work through a defined set of target systems within a defined scope, attempting to find and document as many vulnerabilities as possible. The goal is comprehensive vulnerability coverage and a prioritised remediation list. Red teaming is campaign-style and objective-driven: a small team simulates a specific threat actor pursuing a defined objective — such as accessing a particular database or compromising an executive account — using any technique available, without a predefined list of target systems. The goal is not to find all vulnerabilities but to test whether the organisation's detection, response, and containment capabilities would stop a real attacker. Penetration testing tells you what vulnerabilities exist; red teaming tells you whether your security operations would catch and contain an attacker exploiting them.

External Penetration Testing: A Practical Overview

Q: What is external penetration testing?

External penetration testing is a simulated cyberattack conducted against internet-facing systems — web applications, APIs, cloud infrastructure, network perimeters, and any other assets reachable from the public internet. Testers approach the target as an attacker would, with no prior credentials or internal access, identifying vulnerabilities and attempting to exploit them to determine how far an attacker could reach. Unlike automated vulnerability scanning, which identifies known weaknesses from a list, external penetration testing applies human judgment to find logical flaws, chained vulnerabilities, and misconfigurations that scanners miss. The result is a report showing what was found, how it was exploited, and what to fix — prioritised by the real-world impact of each finding.

Q: What should a penetration test report include?

A quality external penetration test report includes four components. An executive summary: a non-technical overview of the engagement scope, the overall risk posture, and the most critical findings — written for leadership and board-level stakeholders. Technical findings: a detailed write-up for each vulnerability covering the affected asset, a description of the issue, evidence of exploitation (screenshots, request/response logs), a risk rating based on exploitability and potential impact, and specific remediation guidance — not generic advice, but the exact change needed to address the vulnerability in this system. Attack narratives: explanations of how individual vulnerabilities were chained together to achieve a meaningful objective, giving the technical team a clear picture of the actual attack path rather than isolated findings. Risk prioritisation: a framework for deciding what to fix first, accounting for the likelihood of exploitation and the business impact — not just the raw CVSS score, but the contextual severity for this organisation's specific environment and data.

Red team expert simulating realistic, sophisticated, and targeted cyber-attacks to evaluate an organization's detection and response capabilities

Your security tools can tell you what’s exposed. They can’t always tell you what an attacker can do with it.

An internet-facing application may have a vulnerability that looks low-risk in isolation but becomes serious when combined with weak access controls. A misconfigured cloud service may expose more than your asset inventory suggests. A forgotten subdomain may lead to a system your security team no longer monitors.

External penetration testing tests those assumptions.

Rather than relying solely on automated vulnerability scans, security testers approach your public-facing environment as an attacker would. They identify vulnerabilities, attempt to exploit them, and trace how individual weaknesses could be combined to reach sensitive systems or data.

This guide explains how external penetration testing works, what a thorough engagement should include, how it differs from vulnerability scanning and red teaming, and what to look for when selecting a testing provider.

What is External Penetration Testing?

External penetration testing is a controlled simulation of an attack against systems accessible from the public internet.

These systems can include:

Web applications
APIs
VPN gateways
Mail servers
Cloud infrastructure
DNS infrastructure
Public-facing network services

The objective is to identify vulnerabilities before a real attacker can exploit them.

The important distinction is between finding a potential vulnerability and demonstrating that it creates a meaningful security risk.

A vulnerability scanner can identify an exposed service or match a software version to a known CVE. A penetration tester goes further. They investigate whether the vulnerability is exploitable in your environment, determine what access it could provide, and look for ways to chain it with other weaknesses.

That human-led analysis turns a list of vulnerabilities into an assessment of your actual attack surface.

External penetration testing also differs from internal penetration testing. External testing starts from the perspective of an attacker with no assumed access to your network. Internal testing begins from inside the environment, such as with a compromised employee account or workstation.

Both approaches can reveal important weaknesses, but external testing focuses specifically on the defenses protecting your public-facing systems.

Why External Penetration Testing Matters

A public-facing vulnerability is more than a technical issue. It can become the starting point for unauthorized access, data theft, service disruption, or further compromise.

External penetration testing helps organizations identify these weaknesses before attackers do. It also provides evidence about whether existing security measures are working as intended.

There are several practical reasons to run an external penetration test.

Validate your security controls

Organizations invest in firewalls, web application firewalls, endpoint protection, identity controls, and monitoring systems. Testing helps determine whether those controls actually prevent or detect realistic attack attempts.

A correctly configured security tool can still fail to protect an application if the underlying architecture contains another path around it. Manual testing helps uncover these gaps.

Identify vulnerabilities that automated tools miss

Automated scanners are useful for finding known vulnerabilities at scale. They are less effective at understanding application logic, business processes, and attack paths that depend on combining several weaknesses.

A penetration tester can investigate those relationships and demonstrate their impact.

Support compliance and customer requirements

For many organizations, external testing isn’t optional. PCI DSS v4.0 requires external penetration testing at least every 12 months and after any significant change. DORA requires designated financial entities to run threat-led penetration testing at least every three years. NIS2 and GDPR Article 32 are less prescriptive: they require you to regularly assess whether your security measures actually work. An independent penetration test report is often the clearest evidence an auditor will accept. In the UK, public sector and critical infrastructure work typically requires an NCSC CHECK-approved provider.

Prioritize remediation

Security teams rarely have unlimited time or resources.

A useful penetration test helps distinguish between a vulnerability that requires immediate action and one that presents limited practical risk. This gives technical and business teams a clearer basis for deciding where remediation effort should go.

The 6 Phases of an External Penetration Test

A well-run engagement follows a defined process. The exact methodology varies by provider and scope, but most external penetration tests include the following stages.

01
Planning and Scoping

The engagement starts by defining what will be tested and how. That agreement is captured in two documents.

The Statement of Work sets out what will be delivered and when:

Target systems and applications
Systems that are out of scope
Testing methods and depth
Testing dates
Deliverables and reporting requirements

The Rules of Engagement set out how testing will be carried out:

Testing hours and windows
Rules for handling sensitive findings
Communication and escalation procedures

Clear rules of engagement are particularly important when production systems are involved. They establish boundaries for testing and provide a process for escalating unexpected issues.

The most useful part of scoping is often the onboarding call, where the client walks the testing team through the platform itself. Seeing the system in use shows testers what it does, which functions matter most to the business, and where a compromise would hurt. That context shapes where testers focus their effort and how they rate the impact of what they find.

02
Reconnaissance

The testing team gathers information about the organization and its external attack surface.

This can include:

DNS records and subdomains
Publicly exposed services
Technology and software information
Public code repositories
Employee and organizational information
Other publicly available intelligence

This stage shows what an attacker can learn before attempting to compromise the environment.

03
Scanning and Enumeration

The testers then actively examine the systems within scope.

They identify open ports, running services, software versions, authentication mechanisms, application functionality, and other potential entry points.

Automated tools are valuable here because they can cover large numbers of systems quickly. The results then inform the manual testing that follows.

04
Vulnerability Analysis and Exploitation

This is where penetration testing goes beyond vulnerability scanning.

Testers investigate discovered weaknesses and attempt controlled exploitation. Depending on the environment, that might involve:

Exploiting an injection vulnerability in a web application
Testing broken authentication or access controls
Exploiting a vulnerable service
Assessing cloud configuration weaknesses
Combining several lower-severity findings into a larger attack path

The objective is not to cause unnecessary damage. It is to demonstrate what an attacker could realistically achieve.

05
Post-Exploitation

If testers gain access, they assess the extent of that access.

They may determine whether they can:

Escalate privileges
Access sensitive information
Reach other systems
Move laterally
Access administrative functionality
Establish a path toward a defined objective

This helps establish the potential impact of a successful compromise.

06
Reporting and Debrief

The engagement concludes with a detailed report covering the findings, evidence, risk levels, and recommended remediation.

A strong provider should also hold a debrief with the relevant technical and leadership teams. This gives stakeholders an opportunity to understand the findings, ask questions, and agree on remediation priorities.

For a mid-sized environment, an external penetration test may take several weeks from initial scoping through reporting. Larger or more complex environments can require considerably more time.

Methodologies and Tools Used in External Penetration Testing

The quality of a penetration test depends on more than the tools being used.

Established methodologies give testers a structured approach and help ensure important areas are not overlooked.

Common penetration testing methodologies

PTES (Penetration Testing Execution Standard) provides guidance across the penetration testing lifecycle, from pre-engagement activities through reporting.

OWASP Testing Guide provides a structured approach to web application security testing, including authentication, authorization, injection, session management, and other common application security risks.

For organizations with substantial web and API exposure, experience with OWASP testing practices is particularly important.

Common penetration testing tools

Professional testers typically combine automated tools with manual investigation.

Common examples include:

Nmap: Network discovery and port scanning
Nessus or Qualys: Automated vulnerability identification
Burp Suite: Web application and API testing
Metasploit: Controlled exploitation and validation

These tools help testers work efficiently, but they do not replace human analysis.

A scanner might identify a vulnerable service. A tester needs to determine whether the vulnerability can actually be exploited, what access it provides, and whether it can be combined with another weakness.

Human Expertise Still Matters

The biggest difference between an automated vulnerability assessment and a penetration test is what happens after a tool produces its findings.

Experienced ethical hackers investigate how vulnerabilities relate to one another and how they affect the organization’s actual environment.

For example, an individual finding may appear to have moderate impact. When combined with weak access controls and an exposed administrative interface, it could provide a path to sensitive customer data.

Understanding that relationship requires technical expertise and knowledge of the environment.

AI-powered penetration testing tools are also becoming more common. They can accelerate activities such as reconnaissance, vulnerability discovery, and initial analysis.

Treat them as an additional capability rather than a replacement for human testers. Exploitation, post-exploitation analysis, business-context assessment, and decisions about testing boundaries still require experienced security professionals.

How to Choose an External Penetration Testing Provider

Not every provider approaches penetration testing in the same way. The right partner should be able to demonstrate both technical capability and a clear understanding of your environment.

Look at practitioner expertise

Start with the company, then the team.

Provider-level accreditations such as CREST and NCSC CHECK mean the methodology, staff vetting, and reporting have been independently assessed. That is what regulators and auditors look for.

For intelligence-led or red team work, CREST STAR is the relevant standard. At the individual level, CREST CRT/CCT and OSCP are strong signals of hands-on testing skill. Then ask who will actually do the work on your engagement.

Review the Statement of Work

Before testing begins, two documents should be in place. They cover different things.

The Statement of Work (SOW) defines what will be delivered and when. It sets out the contractual obligations:

Systems and applications in scope
Type and depth of testing
Timeline and testing dates
Deliverables, such as the report, debrief, and retesting
Liability and legal boundaries, including authorization to test

The Rules of Engagement (ROE) define how the testing will be carried out. They are the operational guidelines for the team doing the work:

Testing windows and hours
Permitted and prohibited techniques
Handling of sensitive data encountered during testing
Points of contact on both sides
Escalation procedures for critical findings or service disruption

The scope should reflect what you actually need to understand about your security posture. A generic package may not cover a complex environment.

Ask about relevant experience

Experience with similar environments can make findings more useful.

For example, a provider testing a financial services application should understand the security and regulatory considerations that shape that environment. A team testing a healthcare platform should be familiar with the sensitivity of patient data and the implications of its exposure.

Ask for relevant case studies or anonymized examples of previous work.

Consider recurring testing

Penetration testing is becoming less of a once-a-year exercise for organizations with rapidly changing environments.

Penetration Testing as a Service (PTaaS) can provide recurring assessments, centralized findings, and easier retesting.

This approach can make sense for organizations that release frequently or regularly change their external attack surface.

How Much Does External Penetration Testing Cost?

There is no meaningful universal price for an external penetration test.

The cost depends primarily on the scope and complexity of the environment.

Scope

Testing a handful of public IP addresses and one web application is very different from assessing dozens of systems, multiple applications, APIs, and cloud services.

More targets generally require more testing time.

Application complexity

A simple marketing website is relatively straightforward to assess.

An application with authentication, role-based access control, payment functionality, APIs, and third-party integrations requires much deeper testing.

Testing depth

The engagement can range from vulnerability identification through full exploitation and post-exploitation analysis.

The more deeply the team needs to validate attack paths, the more time and specialist expertise the assessment requires.

Team expertise

Senior penetration testers bring experience that can significantly affect the quality of an engagement.

The cheapest assessment is not necessarily the most cost-effective if it produces a long list of findings without demonstrating which ones represent meaningful risk.

Common pricing models include:

Fixed price: A defined fee based on an agreed scope.
Time and materials: Billing based on the time required for the engagement.
Subscription or retainer: Recurring testing at an agreed cadence, often including retesting.

Be cautious of providers that quote a fixed price before understanding your environment. A credible estimate should be based on the systems, applications, objectives, and testing depth involved.

Pentesting vs. Red Teaming: Choosing the Right Assessment

External penetration testing and red teaming are related, but they serve different purposes.

External penetration testing is vulnerability-focused. The objective is to identify and validate as many relevant vulnerabilities as possible within a defined scope.

Red teaming is objective-focused. A red team member simulates a realistic adversary attempting to achieve a specific goal, such as accessing a sensitive database or compromising an executive account.

The differences extend to how the exercises are conducted.

	External penetration testing	Red teaming
Primary goal	Identify and validate vulnerabilities	Achieve a defined objective
Scope	Usually defined around specific systems	Often broader
Defensive team awareness	Usually aware of the engagement	May be unaware
Duration	Typically shorter	Often longer
Techniques	Primarily technical testing	Can include technical, social, and physical techniques
Main focus	Security weaknesses	Detection, response, and attack resilience

If you haven’t assessed your external attack surface recently, penetration testing is usually the better starting point.

Red teaming becomes more valuable when you already have mature cybersecurity defenses and want to test whether your organization can detect and respond to a realistic attack.

In other words, penetration testing asks “What can an attacker exploit?” Red teaming asks “Can an attacker achieve this objective without us stopping them?”

What Should a Penetration Test Report Include?

The report should turn technical findings into decisions your organization can act on.

A strong report typically includes four components.

Executive summary

The executive summary should explain the overall security posture in language that business leaders can understand.

It should highlight:

The most significant findings
Overall risk
Potential business impact
The highest-priority remediation actions

Technical findings

Each finding should provide enough evidence for your technical team to understand and reproduce the issue.

This normally includes:

Vulnerability description
Affected asset
Evidence of exploitation
Risk rating
Potential impact
Specific remediation guidance

Remediation advice should be actionable. “Fix the SQL injection” is less useful than identifying the vulnerable endpoint, explaining the underlying issue, and specifying the control or development change required to address it.

Attack narratives

The strongest reports explain how individual vulnerabilities can be combined.

For example, a report might show how an exposed service led to initial access, how a privilege escalation weakness expanded that access, and how the resulting permissions exposed sensitive information.

This gives your team a better understanding of the attack path rather than presenting each vulnerability in isolation.

Risk prioritization

Not every finding deserves the same response, and the same finding doesn’t always carry the same risk.

A generic severity score treats a vulnerability the same wherever it appears. In practice, its risk depends on where it sits. An outdated component on a static marketing site may be a low priority. The same component on an API that handles payment data may need fixing this week.

Recognizing that difference is what an experienced tester brings. They assess each finding against the system under test and against the organization: what the system does, what data it holds, and what a compromise would mean for the business.

The report should make those priorities clear, so remediation effort goes where the real risk is.

Once fixes are implemented, retesting can confirm whether the vulnerabilities have been resolved.

From Findings to Stronger Security

A penetration test only creates value if its findings lead to better security measures.

That means connecting the assessment to your broader security program. Findings may result in application changes, infrastructure hardening, access-control improvements, additional monitoring, or changes to development practices.

It is also worth looking beyond individual vulnerabilities. Recurring findings can reveal weaknesses in the way your organization designs, deploys, or maintains systems.

For example, repeated access-control issues across applications may indicate a development process problem rather than isolated bugs. Similarly, recurring cloud configuration findings may point to missing infrastructure controls or insufficient security review.

The assessment therefore becomes more useful when findings are treated as evidence about the security of the wider engineering environment.

Secure Your External Attack Surface With Infinum

External penetration testing should answer a practical question: if an attacker targeted your public-facing systems today, what could they reach?

At Infinum, our security work combines automated discovery with manual testing to identify vulnerabilities, validate their impact, and understand how individual weaknesses can form realistic attack paths.

We focus on more than producing a scan report. Our assessments are designed to give engineering and security teams actionable information about what needs to change and why.

That matters particularly in complex digital environments where applications, APIs, cloud infrastructure, third-party services, and legacy systems can create an attack surface that automated scanning alone can’t fully assess.

Our teams work alongside client engineering and security stakeholders to understand the environment, define appropriate testing boundaries, communicate critical findings clearly, and help prioritize remediation.

If you need to validate your external security posture, prepare for a compliance assessment, or identify vulnerabilities across your internet-facing systems, Infinum can help you scope an assessment around your actual environment and objectives.

Secure your external attack surface with AMR CyberSecurity

Infinum’s penetration testing is delivered by AMR CyberSecurity – Part of Infinum, an NCSC CHECK, CREST, and STAR accredited provider. Because AMR is part of Infinum, findings that point to deeper problems, such as recurring access-control flaws or missing infrastructure controls, reach teams that design and ship software for a living, not just a remediation spreadsheet.

Talk to our experts. We’ll define your targets, testing depth, and the compliance evidence you need, and give you a fixed-scope estimate.

Talk to Infinum about your external penetration testing requirements.