What Are the Different Types of Penetration Testing?

Before you start a penetration test, decide what you need it to answer. Could someone exploit your internet-facing systems? Access another customer’s records? Use a compromised employee account to reach sensitive business data? Each question calls for different testing.

The main types include web application, API, mobile application, external network, internal network, and wireless penetration testing. Social engineering assessments examine how people and procedures respond to deceptive requests.

Many businesses need a combination. A mobile app may require testing of both the software on the device and the APIs supporting it. Understanding what each category covers helps you choose an assessment that addresses your risks and recognize where additional testing may be needed.

Types of penetration testing at a glance

1. Web application penetration testing

Web application penetration testing examines how a browser-based application handles users, data, and business actions. Testers investigate login and account recovery, session handling, permissions, input handling, and workflows such as document uploads or payment approvals.

Suppose your customer portal separates records by organization. Testing could investigate whether a user from one customer can retrieve another customer’s documents, or whether an ordinary user can perform an administrator’s actions.

Businesses often request this testing before launching an application, after substantial changes, or during a customer security review.

Clarify which roles, customer organizations, administrative functions, and supporting APIs are included. Access to a public login page alone provides limited coverage of what happens after users sign in.

2. API penetration testing

API penetration testing examines the interfaces applications use to exchange data and request actions. Testing can cover REST, GraphQL, SOAP, and other agreed services, with attention to authentication, permissions, exposed information, and business logic.

An API may accept requests the application’s interface never allows a user to make. For example, hiding an administrative button does not establish that the underlying API rejects an ordinary user’s request.

API testing is useful when launching an integration, adding mobile functionality, or assessing services used by customers and partners.

Specify the API versions, operations, authentication methods, and user roles in scope. Confirm whether coverage extends beyond the API calls exercised through a web or mobile application.

3. Mobile application penetration testing

Mobile application penetration testing examines an app’s behavior on a device and its interactions with supporting services. Areas can include sensitive information stored locally, session handling, network communication, platform-specific protections, and data exposed through logs or other app behavior.

A business preparing to release an app may want to understand whether account information remains on the device after logout or whether weaknesses in communication could expose sensitive data.

Agree on the platforms and builds to test. An assessment of the Android app does not establish coverage of the iOS version.

Also confirm the depth of backend API testing. Examining the mobile client and assessing every relevant server-side permission boundary can require different work.

4. External network penetration testing

External network penetration testing investigates authorized infrastructure and services reachable from the internet. Targets may include VPN endpoints, remote access services, network devices, and exposed server software.

The assessment explores what an attacker could discover and exploit from that outside position. Testing may investigate vulnerable services, configuration weaknesses, and access restrictions.

Businesses request external testing to assess their perimeter, review newly exposed infrastructure, or investigate risks following network changes.

Confirm the domains, IP addresses, and services included, along with how newly discovered assets will be handled. A network assessment may examine a web server’s exposure without allocating time for detailed testing of the application’s customer roles and workflows.

5. Internal network penetration testing

Internal network penetration testing examines what someone could do from an agreed position inside the environment. Testers may investigate internal services, exposed credentials, identity permissions, privilege escalation, and opportunities to move between systems.

An engagement might begin with access to a designated network segment or a standard employee account. From there, testers could investigate whether that access permits them to reach sensitive file shares or obtain additional privileges.

This is useful when evaluating the consequences of a compromised account or workstation, reviewing network separation, or examining internal access controls.

Define the starting access and network position carefully. The connection method and placement affect which systems and traffic testers can reach. Our guide to internal versus external penetration testing explains how these starting positions change the assessment.

6. Wireless penetration testing

Wireless penetration testing examines the security of agreed wireless networks, including authentication, encryption, access point configurations, and separation between guest and business systems.

For an organization with office or warehouse Wi-Fi, testing could investigate whether an unauthorized device can connect or whether a guest connection provides unintended access to internal resources.

Consider wireless testing when introducing a wireless deployment, changing authentication, or reviewing an existing site.

Specify the locations, wireless networks, and access points included. Agree on the equipment and proximity needed to perform the work. Wireless coverage should be planned explicitly rather than assumed to be part of an internal network test.

7. Social engineering assessments

Social engineering assessments evaluate how people and procedures respond to authorized deceptive scenarios. Depending on scope, these may include targeted phishing emails, phone calls, or impersonation attempts.

A scenario could examine whether a help desk follows its identity verification process when someone requests an account reset. Another could assess how employees report a suspicious message and what happens after they report it.

These assessments can help businesses investigate specific weaknesses in verification, reporting, or escalation procedures.

Agree on the people, communication channels, scenarios, and permitted actions. Define the evidence you need: clicking a link, disclosing information, granting access, and reporting a message are different outcomes.

8. Physical penetration testing

Physical penetration testing evaluates whether an unauthorized person could enter a facility or reach restricted areas, equipment, or information. Depending on the engagement, it may examine visitor procedures, badge controls, and access to sensitive spaces.

Organizations may request it when reviewing office security or protections around facilities housing valuable equipment or data. The authorized locations and permitted techniques need their own scope.

Halo Security does not offer physical penetration testing. Businesses that need this coverage should engage a provider specializing in physical security assessments.

Where does cloud penetration testing fit?

A cloud environment can contain web applications, APIs, public services, private networks, storage, and identity systems. “Cloud penetration testing” needs more detail before it describes a useful scope.

Testing a customer portal hosted in the cloud could focus on application permissions and workflows. Assessing the cloud environment supporting it could examine identity permissions, storage access, and network configurations. Those activities require different access and testing effort.

Cloud providers also divide security responsibilities between themselves and their customers. AWS’s shared responsibility model, for example, explains how customer responsibilities vary with the services used.

Describe the resources and access paths you want assessed. Confirm whether the proposal includes application testing, cloud configuration review, exploitation of permitted weaknesses, or a combination.

What do black-box, gray-box, and white-box testing mean?

These terms describe the information and access provided to testers:

• Black box: Limited prior information or access.
• Gray box: Selected information and access, such as application documentation and ordinary user accounts.
• White box: Extensive information or access, potentially including source code, architecture, and configuration details.

Suppose you want to assess a customer portal. A black-box engagement might begin with its public address and investigate what can be discovered from there. A gray-box engagement could supply accounts from two customer organizations so testers can examine whether their data stays separate. A white-box engagement could also provide source code to help investigate how access checks work.

Choose the access that supports your objective, and have the proposal name the actual accounts, documents, and systems testers will receive. An external network test can include detailed documentation; an internal test can begin with limited information.

Is compliance penetration testing a separate type?

Compliance shapes what a penetration test must cover, how it is performed, and what evidence it needs to produce. An engagement may combine application, external network, internal network, and segmentation testing to meet those requirements.

PCI DSS is specific about penetration testing. Requirement 11.4 defines expectations for methodology, coverage, tester qualifications and independence, testing frequency, and verification of fixes. Its defined approach calls for internal and external testing at least every 12 months and after significant infrastructure or application upgrades or changes, with additional requirements for segmentation testing where applicable. The standard is available in the PCI Security Standards Council’s document library.

Other security frameworks can be less prescriptive. The NIST Cybersecurity Framework, for example, defines security outcomes while leaving organizations discretion over how to achieve them. Testing decisions may therefore depend on your risk assessment, chosen controls, and any additional customer or audit expectations.

Bring the actual requirement to your provider. Confirm which systems need testing, the required timing, and what the reviewer expects to receive. Halo’s compliance penetration testing services can help translate those requirements into an agreed scope and deliverables.

Where does red teaming fit?

Red teaming pursues a defined attacker objective across authorized systems while evaluating relevant defenses. An engagement might investigate whether a compromised employee account can reach a designated dataset and whether defenders recognize and interrupt the activity.

That objective can involve several testing categories, but it does not imply detailed coverage of every application or network encountered along the way.

Choose this approach when you need evidence about a particular attack scenario and the controls intended to prevent, detect, or contain it. Our guide to red teaming versus penetration testing explains how their objectives and coverage differ.

How do you choose the right combination?

Start with three questions:

1. What system, data, or business process are you concerned about? Name the application, network, account access, or workflow you want examined.
2. What prompted the assessment? Share the upcoming launch, customer request, audit requirement, or security concern.
3. What do you need the results to help you decide or demonstrate? Your developers may need evidence for fixes, while a customer may need documentation covering a particular service.

Suppose your company is launching a mobile app. Mobile and API testing may address risks in the product and its backend. Assessing what a compromised employee could reach on your corporate network would require additional internal network coverage.

Use those answers to define your penetration testing scope. When comparing offers, review the coverage behind the penetration testing cost and use our questions to ask a penetration testing company to evaluate how providers will investigate your specific concerns.

FAQ

Find the right penetration testing scope for your business

Tell Halo what you need to protect and what prompted the test. We’ll help you choose the appropriate testing and define the scope.