Types of penetration testing: how to choose the right pentest for your security goals

Penetration testing is not one activity. Web apps, APIs, networks, cloud environments, mobile apps, and red team exercises answer different security questions. The best program combines the right depth, timing, and scope.

June 29, 202611 min readUpdated June 29, 2026

Penetration testingSecurity testingWeb application securityAttack surface management

Quick answer

Penetration testing is a controlled security assessment that looks for exploitable weaknesses in a defined scope. But there is no single "pentest" that fits every situation. A web application pentest answers different questions from a cloud pentest. A red team exercise tests different outcomes from an API assessment. A black-box test creates a different view from a white-box review.

The best security programs choose the type of penetration testing based on the asset, the business risk, the maturity of the team, and the decision the test must support. The goal is not to buy a label. The goal is to get evidence that helps the organization reduce real exposure.

Selection framework

Choose the pentest type by the question you need answered.

Scope, knowledge level, and depth shape the outcome more than the name of the engagement.

Security testing

Goal

Define whether the test should find vulnerabilities, validate a release, satisfy an audit, test detection, or reduce exposed attack paths.

Scope

Choose the systems, domains, apps, APIs, cloud accounts, networks, identities, or workflows that are authorized for testing.

Knowledge level

Decide how much information testers receive: black box, gray box, or white box changes both realism and efficiency.

Depth

Balance broad coverage, expert analysis, business logic review, chained exploitation, and retesting needs.

The main types of penetration testing

Each pentest type has a different center of gravity. Some focus on internet-facing exposure. Others focus on authenticated application behavior, internal movement, cloud control planes, or security operations readiness.

Web application penetration testing

Best for: Customer portals, SaaS apps, dashboards, ecommerce flows, authentication, and user-facing business logic.
Often finds: XSS, SQL injection, IDOR, CSRF, authentication flaws, broken access control, insecure uploads, and risky configuration.
When to use it: Use before major releases, after significant product changes, and for systems that process sensitive data.

API penetration testing

Best for: REST, GraphQL, mobile backends, partner APIs, internal APIs exposed through gateways, and machine-to-machine workflows.
Often finds: Broken object authorization, excessive data exposure, weak tokens, schema abuse, rate-limit gaps, and unsafe input handling.
When to use it: Use when APIs power customer data, integrations, automation, billing, or privileged platform actions.

External network penetration testing

Best for: Internet-facing hosts, ports, VPN gateways, remote access services, mail infrastructure, and public administration surfaces.
Often finds: Exposed services, weak remote access, outdated software, certificate issues, default pages, and known exploitable paths.
When to use it: Use when validating what an attacker can discover and reach from outside the organization.

Internal network penetration testing

Best for: Corporate networks, office environments, segmented systems, identity paths, shared services, and post-breach assumptions.
Often finds: Weak segmentation, privilege escalation paths, credential reuse, exposed shares, insecure protocols, and lateral movement risk.
When to use it: Use to understand what happens after a workstation, VPN account, or internal foothold is compromised.

Cloud penetration testing

Best for: Cloud infrastructure, storage, IAM, workloads, container platforms, serverless functions, and managed services.
Often finds: Over-permissive roles, public storage, exposed secrets, unsafe network rules, metadata exposure, and insecure deployment patterns.
When to use it: Use when cloud accounts, CI/CD pipelines, or hosted workloads are central to the business.

Mobile application penetration testing

Best for: iOS and Android apps, mobile APIs, authentication flows, local storage, device permissions, and app transport behavior.
Often finds: Insecure local data storage, weak certificate validation, hardcoded secrets, broken API authorization, and unsafe session handling.
When to use it: Use before app store releases, after SDK changes, and when mobile apps handle credentials, payments, or personal data.

Social engineering assessment

Best for: Human workflows, help desks, finance approvals, password reset processes, and phishing resilience.
Often finds: Process weaknesses, impersonation risk, missing verification steps, awareness gaps, and unsafe escalation paths.
When to use it: Use only with strong authorization, careful safeguards, and clear rules of engagement.

Red team assessment

Best for: Detection engineering, incident response, executive risk validation, and realistic multi-step attack simulation.
Often finds: Control gaps across people, process, identity, endpoints, cloud, network, and monitoring.
When to use it: Use after baseline security hygiene exists and the goal is to test detection and response under realistic conditions.

Black box, gray box, and white box testing

These terms describe how much information testers receive before and during the assessment. They are not maturity levels. They are different lenses. A mature program may use all three depending on the objective.

Model	Tester view	Strength	Tradeoff
Black box	Little or no internal information. Testers begin from public exposure and behave closer to an outside attacker.	Useful for external discovery, reconnaissance realism, and understanding what public signals reveal.	Can spend more time finding context that the organization already knows.
Gray box	Some information is shared, such as test accounts, API docs, architecture notes, or scoped URLs.	Often the best balance for web apps, APIs, SaaS products, and authenticated workflows.	Less pure attacker realism, but usually more efficient and higher-value.
White box	Testers receive deeper access, such as source code, architecture diagrams, credentials, and configuration context.	Strong for secure design review, complex authorization, cryptography, and high-risk business logic.	May miss issues that depend on real-world discovery or deployment drift if not combined with external validation.

Engagement models: point-in-time, continuous, PTaaS, and red team

A penetration test also has a delivery model. This matters because security risk changes after the report is delivered. New code ships, domains appear, APIs change, certificates expire, and forgotten services come back online.

Point-in-time pentest

A focused assessment over a defined window, often before launch, after major change, or for compliance.

Deep expert review of a specific app, API, network, or cloud scope.

Continuous security testing

Recurring checks, scheduled scans, and retesting that keep watching as assets and deployments change.

Fast-moving teams, external attack surface monitoring, regression checks, and remediation verification.

PTaaS

A platform-supported model that blends ongoing testing, findings, evidence, retesting, and expert input.

Teams that want continuous visibility without waiting for a yearly PDF report.

Red team exercise

A goal-driven simulation designed to test detection, response, and cross-control resilience.

Mature programs that want to validate response readiness against realistic attack paths.

Which type should your team choose?

A useful pentest starts with the business scenario. The same company may need a web app pentest for a product launch, cloud testing for infrastructure migration, and a red team exercise once detection and response controls are mature enough to test.

Scenario	Recommended testing	Why
Launching a SaaS application	Web application and API penetration testing, supported by automated external checks.	The main risks are authentication, authorization, business logic, sensitive data flows, and public entry points.
Opening partner integrations	API penetration testing with gray-box documentation and scoped test accounts.	Partner APIs need strong authorization, token handling, rate limits, and data minimization.
Moving workloads to cloud	Cloud penetration testing and configuration review.	Cloud risk often comes from identity permissions, public storage, network rules, secrets, and deployment automation.
Preparing for compliance	Point-in-time pentest plus evidence from continuous monitoring.	Audits often need defined scope and documentation, while continuous checks reduce surprise findings.
Reducing ransomware entry paths	External network testing, credential leak monitoring, and internal network assessment.	Ransomware often begins with exposed services, reused credentials, weak segmentation, or unpatched systems.
Testing the security operations team	Red team assessment or purple team exercise.	The question is not only whether a vulnerability exists, but whether the organization can detect and respond.

Practical workflow

A pentest should produce action, not only findings.

Define the objective

Write the question the test must answer: can this app protect customer data, can this API enforce tenant boundaries, or can this team detect intrusion behavior?

Set authorized scope

List allowed domains, subdomains, APIs, IP ranges, cloud accounts, test users, dates, and excluded systems.

Choose the test type

Match the objective to the right method: web, API, cloud, network, mobile, social engineering, red team, or continuous testing.

Run testing safely

Use agreed rate limits, data handling rules, escalation contacts, test credentials, and production safeguards.

Report evidence and impact

Turn findings into reproducible evidence, business impact, severity, owner routing, and remediation guidance.

Retest and monitor

Confirm fixes after deployment and keep watching because assets, endpoints, dependencies, and exposure keep changing.

The marketing truth: testing must match how teams ship

Penetration testing has business value when it helps teams ship with confidence, reduce audit stress, prioritize remediation, and prove that risk is going down. That value drops when testing is treated as a yearly checkbox disconnected from deployments.

Annual pentests are too slow for fast teams

If your product ships every week, a once-a-year test cannot see every new endpoint, subdomain, dependency, or exposed workflow.

Manual expertise is most valuable when focused

Automation should handle recurring discovery and known checks so experts can spend more time on business logic and chaining.

External exposure changes constantly

DNS records, certificates, staging hosts, APIs, and public services drift whenever teams deploy, migrate, test, or forget cleanup.

Retesting is where security work becomes real

A finding only reduces risk when it is fixed, verified, and monitored for recurrence.

Where Splorix fits

Splorix is not a replacement for every kind of manual penetration test. It supports the always-on external layer that makes testing more current: asset discovery, exposed endpoints, SSL intelligence, technology signals, leak checks, and recurring vulnerability checks on authorized domains.

External attack surface visibilityTrack authorized domains, subdomains, endpoints, SSL status, Whois context, and public metadata between manual tests.

Automated vulnerability signalsUse scheduled checks to detect known patterns, risky exposure, and recurring issues across public assets.

Endpoint and API discovery contextReview discovered URLs, resource types, and last-seen data before planning deeper manual API or web testing.

Remediation workflowKeep findings, evidence, alerts, recommendations, and retesting context close to the teams that need to act.

Pentest preparationGive manual testers a cleaner starting point with fresh inventory, exposed services, and known external signals.

Related Splorix resources: automated vs manual pentesting , attack surface reduction , and endpoint tracking .

FAQ

What are the main types of penetration testing?

The main types include web application, API, external network, internal network, cloud, mobile, social engineering, wireless, physical, and red team testing. The right choice depends on the assets, risks, and security question you need answered.

What is the difference between black-box, gray-box, and white-box testing?

Black-box testing starts with little information, gray-box testing gives testers partial context, and white-box testing provides deeper internal knowledge. Gray-box is often the most practical model for web apps and APIs.

Is automated testing a type of penetration testing?

Automated testing can support penetration testing by discovering assets, checking known weaknesses, and retesting fixes. It does not replace expert manual analysis for business logic, chained exploitation, or ambiguous impact.

How often should penetration testing happen?

High-risk systems should be tested before major releases, after architectural changes, after serious incidents, and on a recurring schedule. Continuous monitoring helps cover the gaps between formal engagements.

Which pentest type should a SaaS company start with?

Most SaaS teams should start with web application and API testing, plus external attack surface monitoring. This combination covers customer-facing workflows, authorization, exposed assets, and recurring drift.

References and further reading

This article is original Splorix content, informed by public security testing standards and guidance.

NIST SP 800-115 technical security testing guide OWASP Web Security Testing Guide OWASP Application Security Verification Standard Penetration Testing Execution Standard MITRE ATT&CK Enterprise

Ready to make external testing continuous?

Create a workspace and keep authorized domains, endpoints, exposure signals, and remediation context visible between manual tests.

Create account