What Type of Penetration Test Do You Need?

Match the test to your attack surface, not to a vendor's catalogue. A B2B SaaS company needs a gray-box web application and API test first, run against the OWASP Web Security Testing Guide and the OWASP API Security Top 10; a company with offices, a VPN and Active Directory needs external and internal network testing, which PCI DSS Requirements 11.4.2 and 11.4.3 make mandatory every 12 months if you touch cardholder data; a cloud-native team needs a cloud and identity assessment layered on top; and a mobile app is half-tested until its backend API is in scope. Most first-time buyers need one or two of those, not five. If a proposal quotes all of them before anyone has asked what you run, you are reading a catalogue, not a scope.

This article maps company profiles to test types, then covers the four inputs that actually move a scope, and the compliance drivers that take the choice out of your hands.

Key takeaways

• The test type follows the attack surface. Buy the test that covers where your data actually lives, not the one with the most line items.
• A mobile application test without its backend API in scope is half a test, because the API is where the authorization logic lives.
• PCI DSS 11.4.2 and 11.4.3 decide the question for anyone handling cardholder data: internal and external network testing, every 12 months and after significant change.
• Scope is driven by user roles, endpoint count, environment complexity and the number of distinct applications, not by how many IP addresses you own.
• If you have never run a vulnerability scan or built an asset inventory, a penetration test will tell you what a scanner would have, at consulting rates.

Start from the attack surface, not the catalogue

Every testing firm publishes a list of nine or ten test types. The list is accurate and it is nearly useless as a buying guide, because it describes what can be sold rather than what you need.

The useful starting point is a boring inventory question: where does an attacker who wants your data have to get to? For most SaaS companies the answer is one production application, its API, and the cloud account they both run in. For a healthcare group with clinics, the answer includes a corporate network, a VPN, and workstations that clinical staff use. Those two companies should buy almost entirely different engagements, and the difference has nothing to do with maturity or budget.

NIST SP 800-115 frames technical security testing around planning, discovery, attack and reporting, and the planning stage is where the value is won or lost. A test that covers the wrong surface will still produce findings. They will just be findings about systems nobody would attack.

The five test types that cover most buyers

Firms sell more than five. Five cover the overwhelming majority of first and second engagements.

Web application testing. A tester works through your application's authentication, session handling, authorization model and business logic, usually with credentials for each user role. This is where the findings that end customer relationships live: one tenant reading another tenant's data, a support role escalating to admin, a workflow that can be driven out of order to skip a payment step. The OWASP Web Security Testing Guide is the reference methodology, and any serious proposal will name it or PTES.

API testing. Related, and not the same thing. The OWASP API Security Top 10 leads with broken object level authorization, which is the flaw where an endpoint checks that you are logged in and never checks that the record you asked for is yours. A tester driving your API directly, rather than through the browser your front end uses, finds a class of problem that a web-only test walks past.

Network testing, external and internal. External testing attacks your internet-facing perimeter. Internal testing assumes an attacker already has a foothold and measures how far they get. These are different engagements with different findings, and we treat the choice between them in internal versus external penetration testing.

Cloud and identity assessment. A test scoped to IAM roles and trust policies, storage permissions, service accounts, secrets handling and the metadata service, rather than to a list of IP addresses. If your infrastructure is cloud-native this is usually more valuable than a classic internal network test, and the provider rules that govern it are covered in cloud penetration testing.

Mobile application testing. Client-side analysis of the app itself, following the OWASP Mobile Application Security project, plus the backend API the app talks to. The client-side half finds hardcoded secrets, insecure local storage and weak certificate handling. The backend half finds the problems that let an attacker skip the app entirely, which is what a real attacker does.

Social engineering, wireless and physical testing are real disciplines and they are rarely the right first purchase. They test controls that most companies have not built yet.

Match by company profile

Here is the mapping we use on scoping calls, stated as bluntly as we can.

B2B SaaS, cloud-hosted, no office network. Buy a gray-box web application and API test of the production platform, tested across every distinct user role including any internal admin console. Add a cloud configuration and IAM assessment in the same engagement or the next one. Skip the classic internal network test until you have an internal network worth testing.

Multi-tenant platform holding customer data. Same as above, with cross-tenant access as a stated test objective in the scope document rather than an assumed part of the work. This is the single most valuable sentence you can add to a statement of work, and it is the finding that most damages a company when it is found by someone else.

Company with offices, a VPN and Active Directory. External network testing plus an internal test that starts from an assumed foothold. Directory misconfiguration and lateral movement are the point, and neither is visible from outside.

Mobile-first product. Mobile application testing with the backend API explicitly in scope. Ask the firm to state which half of the effort goes where, because the split is where quotes diverge.

E-commerce or anything touching cardholder data. The framework decides for you. Internal and external network testing at least every 12 months under PCI DSS 11.4.2 and 11.4.3, plus segmentation testing if you use segmentation to shrink your scope, which we cover in PCI segmentation testing.

Regulated healthcare, defense or financial services. Start from the framework obligation, then add whatever the obligation misses. Our article on how often to run a penetration test sets out what each framework actually requires, which is less than most vendors imply and more specific than most buyers expect.

The four inputs that actually move a scope

When a firm asks for these before quoting, they are pricing your environment. When they do not ask, they are pricing a process that runs identically against everyone.

User roles. Testing three roles means testing every permission boundary between them. Five roles is not slightly more work than three; the pairwise combinations grow faster than the count. Provide working credentials for every role, or accept that the test will not cover authorization properly.

Endpoint and application count. An API with forty endpoints and an API with four hundred are different jobs. So are one application and three, even when the three share a login.

Environment complexity. Single sign-on, service-to-service authentication, multi-tenancy and third-party integrations each add mapping time before any serious testing starts.

Environment and constraints. Production or staging, how faithful staging is, whether the web application firewall stays on, and what the testing window is. A firm testing through a WAF with rate limiting intact is testing your WAF as much as your application, which may or may not be what you wanted.

Note what is missing from that list: the number of IP addresses you own. Pricing that scales linearly with target count is scanner pricing, a point covered in our penetration testing cost breakdown, which is also the only place on this site that publishes ranges.

When compliance picks the test for you

Three frameworks override buyer preference, and it is worth knowing which one is binding before you scope anything.

PCI DSS is the most prescriptive. Requirements 11.4.2 and 11.4.3 mandate internal and external penetration testing at least every 12 months and after any significant infrastructure or application change, and 11.4.4 requires exploitable findings to be corrected and verified by retesting. There is no interpretation available to you there.

SOC 2 is the opposite case, and firms selling testing rarely say so plainly: the Trust Services Criteria name penetration testing only in a point of focus under CC4.1, and the AICPA states that use of the criteria does not require an assessment of whether each point of focus is addressed. Auditors expect a test anyway, because criteria like CC4.1 and CC7.1 need supporting evidence and an annual test with a remediation trail is the cleanest evidence available. That means the scope should follow your audit boundary. Paying to test systems your auditor will never ask about is a common and avoidable waste, and scoping the test to the boundary is part of how we run SOC 2 engagements.

HIPAA requires a periodic technical and nontechnical evaluation under 45 CFR 164.308(a)(8) and never names penetration testing. Whether that is about to change is covered in does HIPAA require penetration testing.

When you should not buy a test yet

The part that costs us work.

If you have never run a vulnerability scan, have no asset inventory, and already know there are unpatched internet-facing systems, a penetration test will produce a long report confirming what you suspect, priced at consulting rates. Run the scans, patch what they find, then test. A penetration test earns its fee against an environment someone has already tried to secure.

If the driver is a single customer questionnaire that asks for vulnerability scanning, buy the scan and say clearly that it is a scan. The difference between the two artifacts, and the reason reviewers increasingly notice, is set out in penetration test versus vulnerability scan.

And if a firm proposes five test types to a company with one application, the correct response is to ask which findings they expect each one to produce. A good answer names specific attack paths. A bad answer names coverage.

Where Top Floor fits

Our penetration testing practice covers network, web application, API, cloud, social engineering, wireless and physical assessments, and the scoping call exists to tell you which of those you actually need. Gray box by default, named senior testers, PTES and OWASP methodology stated in writing, a retest round, and an attestation letter you can hand to a customer without exposing your findings.

Where the test is driven by an audit, our SOC 2 and PCI DSS teams scope it to the boundary the assessor will actually examine, which usually makes the engagement smaller rather than larger.

How to decide this week

Write down where your customer data physically lives: which applications, which APIs, which cloud accounts, which office systems can reach it. That list is your scope, and most companies can produce it in an afternoon.

Then count your user roles and check whether you can issue working test credentials for each. If you cannot, fix that first, because authorization testing is where the serious findings are and it cannot happen without accounts.

Then send the same one-page brief to every firm you are considering, and compare what comes back. Quotes are only comparable when everyone priced the same thing.

Frequently asked questions

What is the difference between a web application test and an API test?

A web application test drives your application the way a browser does, working through authentication, session handling, authorization and business logic across each user role. An API test drives the endpoints directly, without the front end that normally constrains what can be requested. The distinction matters because the OWASP API Security Top 10 leads with broken object level authorization, the flaw where an endpoint verifies that you are logged in but never verifies that the record you requested belongs to you. A front end that only ever asks for your own records will hide that flaw from a web-only test. If your product has a public or partner-facing API, scope it explicitly.

Do I need an internal network penetration test if we are entirely cloud-hosted?

Often not, and that is an unusual thing for a testing firm to say. A classic internal network test assumes a corporate network with domain-joined workstations, file shares and lateral movement paths. A company with no office network, no VPN and no Active Directory has none of that, and the equivalent risk lives in cloud identity: over-permissive roles, exposed service account keys, and storage that is readable by more principals than anyone intended. For that profile a cloud and IAM assessment usually returns more than an internal network test. If you have offices, a VPN or a directory, buy both.

How many user roles should we include in the scope?

All of them, including the internal administrative roles nobody outside engineering uses. Authorization flaws live in the boundaries between roles, so a test covering only the standard customer role can only find a fraction of them. If cost is the constraint, it is better to test every role on one application than one role on three applications. Say which roles exist during scoping rather than after the engagement starts, because adding a role mid-test means re-testing work that is already done.

Is a mobile app test enough on its own?

No. The mobile client is one half of the system and usually the less interesting half. Client-side testing finds hardcoded secrets, insecure local storage and weak certificate validation, which are real and worth fixing. The backend API is where authorization, business logic and data access live, and an attacker who wants your data will talk to it directly rather than through your app. Scope both, and ask the firm how the effort splits between them.