Types of Penetration Testing: A Complete Guide

Not All Security Tests Are the Same

Penetration tests differ by how much the tester knows and what they target, and choosing the right one decides whether a test finds real risk or just ticks a box. This guide explains the types of penetration testing by knowledge level and by target, so you can scope the engagement your business actually needs.

Getting the type right the first time saves money. A test scoped to the wrong surface finds little of value and usually has to be commissioned again, so a short scoping call is always worth the time.

In short: penetration tests are grouped two ways. By knowledge level there is black box, grey box and white box testing; by target there is network, web application, mobile, API, cloud, wireless, social engineering and physical testing. Black box simulates an outside attacker with no prior information; white box gives testers full access to code and architecture; grey box sits in between and is the most common, balancing realism and efficiency. By target, each type examines a different attack surface. The right combination depends on your systems, threat model and compliance needs. Most organisations start with the highest-risk asset, often a public web application, and expand coverage over time.

Two Ways to Classify a Test

By knowledge level, testers work as black box, white box or grey box. By target, they focus on networks, web apps, mobile, APIs, cloud and people.

Both lenses matter. The knowledge level sets how realistic the simulation is; the target defines which attack surface is examined. A complete programme mixes them deliberately.

In practice, a grey box web application test plus an external network test, for instance, covers both how an attacker gets in and what they can reach once inside.

At a glance

• Black box: no prior knowledge, simulating an external attacker.
• White box: full access to code and architecture for depth.
• Grey box: limited access, balancing realism and efficiency.
• By target: network, web, mobile, API, cloud and wireless.
• Social engineering and physical testing of people and premises.

Black Box, Grey Box and White Box

Black box testing gives the tester no inside information, mimicking a real external attacker discovering your systems from scratch. It is realistic but slower, since time goes into reconnaissance.

White box testing is the opposite: testers get full access to source code, architecture and credentials, enabling the deepest, most thorough review in the least time.

Grey box sits between the two and is the most popular, giving testers limited access, such as a standard user account, to balance realism with efficiency.

There is no single best choice. Black box proves what an outsider can do; white box finds the most issues per hour; grey box is the pragmatic middle most teams pick for a first engagement.

Tests by Target

• Network (external and internal): exposed services, weak configurations and paths through Active Directory to critical systems.
• Web application: authentication, access control, injection and business logic, usually against the OWASP Top 10 and testing guide.
• Mobile application: app binaries, local storage, platform APIs and the backend they call.
• API: authorisation on every endpoint, object-level access and data exposure.
• Cloud: identity and access configuration, storage exposure and paths to privilege escalation.
• Wireless, social engineering and physical: the network edge, the people who can be persuaded, and the premises.

Choose among them based on where your sensitive data and exposure actually live, not on what is easiest to test. Most estates need several over time: a web app test, a network test and a cloud review together cover the surfaces that matter for a typical SaaS or enterprise environment.

Which Type Do You Need?

Start with risk. If a public web app holds customer data, a web application test comes first.

Compliance often decides for you. PCI DSS, SOC 2 and ISO 27001 each expect particular coverage, so the framework you answer to frequently sets which tests you run and how often.

Budget and maturity matter too. A lean team scopes tightly to the highest-risk target before broadening coverage. For typical ranges, see our guide to penetration testing cost in India.

How the Types Work Together

The types are complementary, not competing. A network test finds the way in; a web app test finds what an attacker does next; a red team engagement chains them into a full attack path and tests detection.

Think of it as building a picture over time. One test rarely covers everything, so mature teams rotate through the types across the year, revisiting the highest-risk assets most often.

The methods are the same worldwide. Recognised methodologies such as PTES, the OWASP testing guides and OSSTMM mean results from an Indian provider are understood by auditors and customers in any market.

How SecureRoot Helps

SecureRoot covers all the main types of penetration testing through its VAPT services, from web application and network penetration testing to cloud and mobile application testing, matched to your risk.

Every engagement delivers a developer-ready report with reproduction steps, CVSS severity ratings, proof-of-concept evidence and retesting.

Talk to SecureRoot →

Frequently asked questions

Straight answers, no marketing speak. If you don’t see your question here, just ask at info@secureroot.co or call +91 73071 48874.

How many types of penetration testing are there?

Broadly three by knowledge level and several by target, but the count matters less than the combination. The knowledge-level axis is black box, grey box and white box, and it decides how much the tester is told before starting. The target axis is network, both external and internal, web application, mobile application, API, cloud, wireless, social engineering and physical. Every real engagement picks one knowledge level and one or more targets, so a grey box test of a web application and its API is a single engagement described on both axes. Counting types is useful mainly as a scoping checklist: it forces you to name which surface you are buying coverage for, and how much information the tester is given. Anything left off that list is untested, whatever the report title says. A scoping call of thirty to forty-five minutes is where those choices get made explicit, before a written scope, timeline and fixed price are agreed.

What is black box penetration testing?

Black box means the tester starts with nothing but a company name or a domain, and has to find, map and exploit your systems the way an unknown outsider would. Reconnaissance is the work: enumerating hosts, subdomains, exposed services and forgotten assets before any exploitation begins. That realism has a cost. A large share of a fixed-length engagement goes on discovering what a grey or white box tester would simply be handed, so a black box test of the same duration usually surfaces fewer issues than the alternatives. It answers one question well: what can somebody with no relationship to you actually reach and do. Choose it when that is the question a board or a customer is asking, or when you want to test external exposure rather than inventory application logic. For a first engagement against a known application, grey box is normally the better use of the same budget.

What is white box penetration testing?

White box means the tester receives everything: source code, architecture diagrams, configuration detail, and credentials for each role in the application. Nothing is hidden, so the days go into analysis rather than discovery, and the same length of engagement buys the deepest review of the three knowledge levels. It reaches flaws that are effectively invisible from outside, including logic errors in code paths that need an unusual sequence of states, weak cryptographic choices, and authorisation checks that look correct in the interface but are missing in the handler behind it. Use it for critical applications and pre-release reviews, where finding as many real defects as possible matters more than simulating an outsider. It is not a code review under another name. SecureRoot runs this work as manual, exploit-driven testing, with a proof of concept for each finding and a retest included, so a fix is verified rather than assumed.

Which type is most realistic?

Black box is the closest simulation of an unknown external attacker, because the tester faces the same blank page a real one does. Realism and value are not the same thing, though. Grey box, where the tester holds a standard user account, is usually the better buy: it removes the guesswork and spends the engagement on what an attacker or a malicious customer can do once authenticated. That is where the serious findings tend to sit. Broken access control, object-level authorisation failures on APIs, and business logic that can be driven out of sequence are all reached far faster with a login than without one. A patient attacker would register an account anyway, so grey box is not less realistic in outcome, only in the route taken to get there. If you want both, scope an unauthenticated external phase first and hand over credentials for the authenticated work that follows.

Which type of penetration testing do we need first?

Start with the asset that carries the most risk, which for most organisations is an internet-facing application or API handling customer data. It is reachable by anyone, it holds the data that would hurt most if exposed, and it changes most often, so it is the surface where a test earns its cost fastest. Extend from there to the external network, then the cloud environment, then the internal network, revisiting the highest-risk asset most often rather than spreading one budget thinly across everything at once. Two things override that order. A framework or a customer contract may specify coverage, so check what it expects before scoping. And a recent change, a migration, a new payment flow or an acquisition, deserves attention ahead of the queue. Cost is the other input; our guide to penetration testing cost in India sets out the ranges that shape a realistic first scope.

Can we combine several types in one engagement?

Yes, and most mature programmes do exactly that. A combined engagement, for example an external network test alongside a grey box test of a web application and its API, shares one scoping exercise, one timeline and one report, and it shows how findings chain together rather than listing them as unrelated items. That chaining is the point. A weak service on the perimeter matters far more when it yields a credential the application accepts, and neither test on its own would have said so. Practical limits apply. Each added target still needs its own days, so combining types widens coverage without shortening the work, and a scope stretched across everything at once usually covers nothing in depth. A red team engagement goes further again, chaining techniques across targets to test whether detection and response notice the activity at all, which is a different question from whether the vulnerabilities exist.

Related services

VAPT Services · Network Penetration Testing · Cloud Penetration Testing

Get tested by certified experts

Talk to SecureRoot →