Types of Penetration Testing: Every Kind, Explained

“Penetration testing” is an umbrella term. Underneath it sit more than a dozen distinct engagements, each aimed at a different part of your attack surface, run with a different amount of knowledge, and bought for a different reason. Choosing the right type, or the right combination, is the difference between a test that reflects your real risk and one that quietly misses it.

This guide maps the types four ways: by what is tested, by how much the tester knows, by where the tester starts, and by how often the testing happens. New to the concept entirely? Start with what penetration testing is and come back.

Types by target

The most common way to classify a penetration test is by what it points at. Each target has its own attack surface, its own tooling, and its own failure modes, which is why a good provider scopes and prices them separately.

• Web application penetration testing. The OWASP Top 10, business logic, authentication, session handling, and access control in browser-based applications. The most common engagement and the one most compliance frameworks expect first. Fixed price from $5,200.
• API penetration testing. REST, GraphQL, and SOAP endpoints, with the emphasis on authorization, object-level access, rate limiting, and data exposure, the failures the OWASP API Security Top 10 catalogs. Fixed price from $4,000.
• Mobile application penetration testing. iOS and Android apps tested against the OWASP MASVS: local storage, transport security, runtime tampering, and the backend APIs the app talks to.
• External network penetration testing. Your internet-facing perimeter: exposed services, VPNs, mail, remote access, and anything a stranger can reach. It answers the question an attacker asks first, where is the way in. Fixed price from $4,200.
• Internal network penetration testing. The assumed-breach view: a tester starts on your network with one ordinary user or one workstation and works toward Domain Admin, testing segmentation, Active Directory, and lateral movement. Fixed price from $6,000. We compare the two network tests in external vs internal penetration testing, and both are scoped together on the network penetration testing page.
• Cloud penetration testing. AWS, Azure, and GCP configuration, identity and access management, storage exposure, serverless functions, and the cloud-native attack paths that do not exist on a traditional network.
• Hardware and IoT penetration testing. Firmware, debug interfaces, radio, the companion app, and the cloud backend of a connected device. Our IoT penetration testing guide walks through it layer by layer. Fixed price from $5,200.
• Source code review. Finding flaws in the code before they run in production, usually paired with an application test so that what the review finds can be confirmed at runtime.
• Social engineering and phishing. Testing the human layer with realistic email, voice, and SMS lures, measured by who clicks, who enters credentials, and who reports. Fixed price from $3,600.
• AI and LLM penetration testing. Prompt injection, jailbreaks, data leakage, and unsafe tool use in systems built on large language models, including the integrations that give a model the ability to act.

Most organizations start with whatever holds their most sensitive data or faces the most exposure, then widen coverage over time. A SaaS company usually begins with the web application and its API. A firm with an office network and a domain usually begins with an external test, then an internal one.

Types by knowledge

The second axis is how much the tester is told before the test starts. Every target above can be tested any of these three ways.

• Black box. No prior knowledge and no credentials. The tester approaches like an outside attacker with nothing but your public footprint. It is the most realistic view of an opportunistic attack, and the slowest, because discovery eats time that could have gone into depth.
• White box. Full access: source code, architecture diagrams, credentials for every role. The most thorough option, because nothing is hidden, and the right choice for high-stakes systems where completeness matters more than realism.
• Gray box. The middle path: credentials for one or more roles, documentation, and context, but not the source. It mirrors the attacker who already has a foothold or a legitimate account, and it spends the budget on exploitation rather than guesswork. For most engagements it produces the strongest results per dollar.

We break down what each method finds, misses, and costs in black box vs white box vs gray box penetration testing.

Types by starting position

Closely related, and often confused with the knowledge axis, is where the tester begins.

• External. Starting from the internet, against whatever is publicly reachable.
• Internal, or assumed breach. Starting from inside the network, the position an attacker holds after a successful phishing email, a stolen laptop, or a malicious insider. Internal tests routinely find that the perimeter was fine and the inside was not.
• Authenticated versus unauthenticated. Whether the tester holds valid credentials to the application. Authenticated testing is where authorization flaws, the most common serious finding in web applications, actually surface.

Types by cadence

The third axis is timing.

• Point-in-time testing. One engagement, one report, usually annual or tied to a release, a compliance deadline, or a customer request. This is what most buyers mean by “a pentest.”
• Continuous penetration testing. Scheduled manual tests around your release cycle, validated scanning between them, and retests on demand, run as a program rather than a project. It suits teams that ship weekly and cannot wait a year between tests.
• Penetration testing as a service. The delivery model behind continuous testing: a standing engagement with a platform for tracking findings, rather than a single PDF. We explain how it differs from a one-off test in the PTaaS guide.

Types by reason for buying

Finally, tests are often named for why they were bought, which shapes the scope more than people expect.

• Compliance-driven. SOC 2, PCI DSS Requirement 11.4, HIPAA, NYDFS 23 NYCRR 500, and ISO 27001 each expect specific coverage and specific evidence, so the scope is written to satisfy the auditor as well as to find flaws.
• Risk-driven. A new product, a recent acquisition, a system that just moved to the cloud, or a board that asked a hard question. Scope follows the exposure rather than a checklist.
• Third-party, or independent, testing. A test performed by a firm with no stake in the system, bought because an auditor, an enterprise customer, or a cyber insurer asked for independent evidence. The report and attestation letter matter as much as the findings.

Related, but not types

A few engagements get grouped with penetration testing and are worth separating.

• Vulnerability scanning. Automated, broad, and fast. It finds known weaknesses; it does not exploit them or chain them. See penetration testing vs vulnerability scanning. When the two are bought together the engagement is usually called vulnerability assessment and penetration testing, or VAPT.
• Red teaming. A goal-based, stealthy adversary simulation that tests detection and response as much as vulnerabilities. It is broader, longer, and more expensive than a penetration test, and it assumes the basics have already been tested. The differences are laid out in red teaming vs penetration testing.
• Automated “penetration testing.” Tools that scan and, in some cases, attempt exploitation on their own. Useful between manual tests; not a substitute for them. See automated vs manual penetration testing.

How to choose

Match the type to your risk, in this order.

1. What holds your most sensitive data? Test that first. For most companies it is a web application, an API, or a cloud environment.
2. What is your compliance driver? SOC 2, PCI DSS, and HIPAA often dictate the minimum scope and the evidence format, so start there and add to it rather than testing around it.
3. What is your largest exposure? Anything internet-facing, anything new, and anything you inherited through an acquisition.
4. What method fits? Gray box for most engagements, white box for critical systems, black box when realism is the point of the exercise.
5. How often do you change? If you ship continuously, a point-in-time test is stale within a quarter. A continuous program fits better.

Not sure which combination reflects your risk? That is what scoping is for. Scope your assessment and you get a written fixed price back within one business day, or see every published price on the pricing page first.