Types of Penetration Testing Explained

Penetration testing is not a single service but a structured family of adversarial security disciplines, each targeting a distinct layer of an organization's attack surface. This page describes the principal engagement types recognized across professional standards bodies, the operational phases common to each, the scenarios that drive selection of one type over another, and the decision boundaries that distinguish overlapping categories. The classification framework here reflects terminology used by NIST, OWASP, and the Penetration Testing Execution Standard (PTES).

Definition and scope

Penetration testing encompasses authorized, human-driven attempts to exploit vulnerabilities across defined target environments. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, distinguishes penetration testing from automated scanning by requiring active exploitation — the tester must demonstrate that a vulnerability is reachable, exploitable, and consequential, not merely detectable.

The service sector organizes engagement types along two primary axes: target domain (what is being tested) and knowledge state (how much information the tester begins with). These axes produce overlapping but distinct categories. As described in greater detail on the black-box, white-box, and gray-box testing reference page, knowledge-state classifications apply across all target domains and are not independent engagement types themselves.

The primary target-domain categories recognized by PTES and NIST include:

  1. Network penetration testing — external and internal infrastructure including firewalls, routers, VPNs, and network segmentation controls
  2. Web application penetration testing — HTTP/HTTPS attack surfaces, authentication mechanisms, injection vectors, and session management
  3. Mobile application penetration testing — iOS and Android application logic, local data storage, and API communications
  4. Cloud penetration testing — cloud-hosted infrastructure, IAM configurations, storage permissions, and serverless functions
  5. API penetration testing — REST, SOAP, and GraphQL endpoints, authentication tokens, and authorization logic
  6. Wireless penetration testing — Wi-Fi protocols, rogue access points, and wireless authentication schemes
  7. Social engineering penetration testing — phishing, vishing, and pretexting campaigns targeting personnel
  8. Physical penetration testing — facility access controls, badge systems, and on-site intrusion scenarios
  9. Red team operations — full-scope, multi-vector adversarial simulations combining network, application, social, and physical vectors
  10. IoT and SCADA/ICS penetration testing — embedded devices, industrial control systems, and operational technology networks

Regulatory demand spans these categories. PCI DSS Requirement 11.4 (PCI Security Standards Council) mandates penetration testing of network and application layers for cardholder data environments. HIPAA's Security Rule, enforced by the HHS Office for Civil Rights, references risk analysis processes that penetration testing directly supports. FedRAMP's control baseline draws on NIST SP 800-53 CA-8, which explicitly requires penetration testing for federal cloud service authorizations.

How it works

Regardless of target domain, penetration testing engagements follow a structured sequence of phases. PTES defines six core phases applicable across engagement types:

  1. Pre-engagement — scope definition, rules of engagement, legal authorization, and target inventory. The rules of engagement document establishes the legal and operational boundaries for the entire test.
  2. Reconnaissance — passive and active information gathering about the target, including open-source intelligence (OSINT), DNS enumeration, and service fingerprinting.
  3. Threat modeling and vulnerability identification — mapping the attack surface and identifying candidate vulnerabilities through scanning, manual analysis, and tool-assisted enumeration.
  4. Exploitation — active attempts to compromise identified weaknesses, including chaining low-severity findings into high-impact attack paths.
  5. Post-exploitation — demonstrating impact through lateral movement, privilege escalation, data access, or persistence — the phase that differentiates penetration testing from scanning.
  6. Reporting — structured documentation of findings, evidence, severity ratings, and remediation priorities. NIST SP 800-115 provides a reporting framework that includes executive summaries and technical appendices.

The OWASP Testing Guide provides a parallel methodology specifically for web and API targets, organized around 11 testing categories covering authentication, authorization, input validation, and cryptography.

Knowledge-state variables modify execution within these phases. A black-box engagement begins reconnaissance from zero — the tester receives only the target's name or IP range. A white-box engagement provides full architecture documentation, source code access, and credential sets. Gray-box falls between: partial network diagrams, user-level credentials, or application role access without administrative context. White-box testing typically produces higher vulnerability coverage in less time; black-box testing more accurately simulates an external attacker's actual discovery process.

Common scenarios

Compliance-driven network testing is the most frequently contracted engagement type. Organizations subject to PCI DSS, HIPAA, or SOC 2 Type II (AICPA) must demonstrate that network segmentation controls function as intended and that known vulnerability classes have been actively tested, not merely scanned.

Web application testing is the default engagement for software development organizations and SaaS providers. OWASP's Top 10 list — updated in 2021 — identifies the 10 most critical web application risk categories and forms the baseline scope for most commercial web application tests. Broken access control ranked first in OWASP's 2021 classification, reflecting its prevalence across modern application architectures.

Red team operations are typically commissioned by organizations with mature security programs that have already addressed known vulnerability classes. A red team engagement operates without advance notification to the security operations team, testing detection and response capabilities rather than just technical controls. Engagements commonly run 4–12 weeks and involve coordinated network, social engineering, and physical vectors.

Cloud penetration testing addresses misconfigurations in AWS, Azure, and Google Cloud environments — including overprivileged IAM roles, publicly exposed storage buckets, and insecure serverless function triggers. Cloud providers impose specific rules of engagement: AWS's Customer Support Policy for Penetration Testing prohibits testing of infrastructure not owned by the customer and requires advance notification for certain test types.

SCADA and ICS penetration testing is a specialized discipline governed by guidance from CISA (Cybersecurity and Infrastructure Security Agency) and IEC 62443, the international standard for industrial automation and control system security. Testing in operational technology environments requires modified exploitation techniques to avoid disrupting physical processes.

Decision boundaries

Selecting the appropriate engagement type depends on four structured criteria:

Regulatory mandate takes precedence. PCI DSS Requirement 11.4 specifies both network and application-layer testing. FedRAMP's CA-8 control requires testing that aligns with NIST SP 800-53. HIPAA penetration testing requirements flow from the Security Rule's risk analysis mandate at 45 CFR §164.308(a)(1).

Attack surface composition determines scope. An organization with no externally accessible web applications has no basis for web application testing. Conversely, organizations with public-facing APIs require API penetration testing as a distinct engagement from general web testing — API attack surfaces include authentication token exposure, broken object-level authorization (BOLA), and mass assignment vulnerabilities not addressed by standard web test scripts.

Program maturity distinguishes point-in-time testing from continuous or adversarial simulation. Organizations in early compliance cycles typically commission network and web application tests. Organizations with functional security operations centers (SOCs) commission red team or purple team testing to validate detection logic and response playbooks.

Knowledge-state selection reflects threat modeling. External attackers — the threat model for most commercial environments — begin with no internal knowledge, supporting a black-box or gray-box approach. Insider threat modeling or pre-deployment code review supports white-box testing. The penetration-testing-vs-vulnerability-assessment reference page clarifies where automated scanning ends and human-driven exploitation begins — a boundary that directly affects engagement type selection and cost.

Engagement type also affects the legal authorization structure. Physical penetration testing and social engineering campaigns require explicit written authorization covering personnel, physical premises, and any impersonation scenarios — authorizations that differ structurally from standard network testing agreements. The rules of engagement documentation required for each engagement type is not interchangeable across categories.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator