Types of Penetration Testing Explained: Which One Does Your Organization Need?

Penetration testing is not a single service — it's a category of security assessments that can target different parts of your environment using different methods. Choosing the right type of test for your situation determines whether you get meaningful security insights or a report that misses your actual risk.

This guide covers the main types of penetration testing, when each is appropriate, and how compliance requirements map to specific test types.

The Main Types of Penetration Testing

1. External Network Penetration Testing

External network testing targets your internet-facing infrastructure — the systems visible from the public internet. This is where most attackers begin: probing your perimeter to find a way in.

What it covers:

• Firewalls and network edge devices
• VPN and remote access portals
• Mail servers and DNS infrastructure
• Publicly accessible management interfaces
• Cloud-hosted infrastructure with public IP ranges

When it's appropriate: Any organization with internet-facing infrastructure. External testing is the baseline — if you do nothing else, start here. It is required by PCI DSS Section 11.4, expected by NIS2 regulators, and asked for by most cyber insurers.

What it doesn't cover: Threats from inside the network — for that, you need internal testing.

2. Internal Network Penetration Testing

Internal testing simulates an attacker who has already gained access to your network — whether through a phishing attack, a compromised VPN credential, a rogue device, or physical access. The question it answers: once inside, how far can an attacker go?

What it covers:

• Lateral movement paths through internal network segments
• Active Directory and identity infrastructure attacks
• Privilege escalation to domain administrator
• Access to sensitive file shares and databases
• Network segmentation validation (can systems that should be isolated actually be reached?)

When it's appropriate: Organizations that handle sensitive data, operate critical services, or are subject to NIS2, DORA, or PCI DSS. Internal testing is required by PCI DSS Section 11.4 and is standard for any comprehensive security program. It is also essential after a suspected breach — to determine how far an attacker may have moved.

3. Web Application Penetration Testing

Web application testing targets your browser-accessible applications — customer portals, SaaS platforms, internal tools, APIs, and e-commerce infrastructure. Web applications are the most targeted attack surface for most organizations because they're accessible to anyone with a browser.

What it covers (following OWASP Testing Guide):

• Authentication and session management flaws
• SQL injection, command injection, and other injection vulnerabilities
• Cross-site scripting (XSS) and cross-site request forgery (CSRF)
• Broken access controls and insecure direct object references
• Business logic vulnerabilities (flaws specific to your application's workflow)
• API security: authentication, authorization, rate limiting, and data exposure

When it's appropriate: Any organization that operates customer-facing web applications, processes payments online, or exposes APIs to third parties. Required by PCI DSS Section 6.2.4 for applications that handle cardholder data. Expected in SOC 2 programs and under NIS2 for digital service providers.

Web application testing can be conducted as a standalone engagement or combined with external network testing for full perimeter coverage.

4. API Penetration Testing

APIs have become the primary attack surface for many modern applications — particularly SaaS platforms, fintech services, and mobile-backed applications. API testing focuses specifically on the interfaces between systems, where authorization flaws and data exposure are most common.

What it covers:

• Broken object-level authorization (BOLA / IDOR)
• Broken function-level authorization
• Mass assignment and data exposure vulnerabilities
• Rate limiting and resource consumption weaknesses
• Authentication token security
• Third-party API integrations and supply chain touchpoints

When it's appropriate: Organizations building or operating API-heavy platforms, particularly those in fintech, healthcare technology, SaaS, and any sector subject to DORA or NIS2 where third-party connectivity must be validated.

5. Cloud Penetration Testing

Cloud environments — AWS, Azure, GCP — introduce a different category of misconfiguration and privilege escalation risks compared to traditional on-premise infrastructure. Cloud penetration testing evaluates your cloud architecture for weaknesses specific to the cloud model.

What it covers:

• Misconfigured S3 buckets, blob storage, and cloud object stores
• IAM policy weaknesses and privilege escalation paths
• Public-facing cloud services and metadata service exploitation
• Container and Kubernetes security
• Serverless function vulnerabilities
• Cross-account trust relationships

When it's appropriate: Any organization operating workloads in public cloud. Cloud misconfigurations are consistently among the leading causes of data breaches — yet many organizations have never had their cloud posture independently tested.

6. Social Engineering Testing

Technical controls are only as strong as the humans who operate them. Social engineering testing evaluates whether employees can be manipulated into disclosing credentials, clicking malicious links, or allowing unauthorized physical access.

What it covers:

• Phishing simulations: email-based attacks designed to harvest credentials or deliver payloads
• Spear phishing: targeted campaigns against specific individuals or departments
• Vishing: voice-based pretexting attacks
• Physical pretexting: tailgating, impersonation, and badge cloning

When it's appropriate: Organizations seeking to assess human-layer risk alongside technical controls, or those required to demonstrate security awareness program effectiveness under NIS2 or ISO 27001.

7. Threat-Led Penetration Testing (TLPT) / Red Team

TLPT and red team exercises are the most advanced form of adversarial simulation. Rather than testing against a defined vulnerability list, they use real threat intelligence to simulate the specific TTPs (tactics, techniques, and procedures) of threat actors known to target your sector.

What distinguishes it from standard pentesting:

• Engagement duration: weeks to months rather than days
• Scope: entire organization, including people, processes, and technology
• Objective: test detection and response capabilities, not just preventive controls
• Intelligence-driven: based on real threat actor TTPs from the financial sector or relevant vertical

When it's required: TLPT is mandated under DORA for financial entities designated as significant by national competent authorities. It is also used by organizations seeking the most realistic assessment of their resilience. Read our full guide on DORA TLPT requirements.

How Test Types Map to Compliance Requirements

Choosing the Right Test for Your Organization

The right combination of test types depends on your risk profile, infrastructure, and compliance obligations. As a general guide:

• Starting from scratch? Begin with an external network test to understand your internet-facing exposure, then add internal and web application coverage in subsequent engagements.
• PCI DSS in scope? You need external network, internal network, application layer, and segmentation testing — all annually. A combined engagement is more efficient than four separate ones.
• NIS2 or DORA regulated? Annual external + internal + application testing forms the core of a compliant testing program. Q-Sec can scope this to cover multiple frameworks in a single engagement.
• SaaS or cloud-native? Prioritize web application and API testing alongside cloud configuration review. Your perimeter is your application.
• Mature security program? Consider social engineering testing and periodic red team exercises to test whether your detection and response capabilities have kept pace with your preventive controls.

Q-Sec's compliance consulting team can map your specific obligations across frameworks and recommend the most efficient test scope — rather than defaulting to the most expensive option.

Frequently Asked Questions

Can we combine multiple test types in one engagement?

Yes — and for most organizations, a combined engagement is more cost-effective than separate tests. A single engagement covering external network, internal network, and web application testing can generate evidence for NIS2, ISO 27001, and PCI DSS simultaneously, with one scoping call, one reporting cycle, and one fixed fee. Q-Sec structures engagements to maximize compliance coverage per euro spent.

What's the difference between API testing and web application testing?

Web application testing covers the full browser-accessible application, including its frontend, authentication, and business logic. API testing focuses specifically on the machine-readable interfaces — REST or GraphQL endpoints — that may not be visible through a browser but carry significant data. Modern applications often warrant both: Q-Sec includes API testing as part of web application engagements where APIs are in scope.

We're a small team. Do we need all of these?

No. A focused external network test is better than no test at all, and for many mid-sized organizations it's the right starting point. The key is to match the scope to your actual risk — not to buy the most comprehensive option available. Q-Sec works with organizations of all sizes; our pricing is flat-fee and scoped to what you actually need.