Types of penetration test and when to use each

The type of test you buy decides what the report can tell you. Most companies buy black box testing because it sounds more like a real attack, and most of them get less for their money because of it.

Last reviewed 2026-08-16Written by Jacob Masse, TrazTech Inc.

Penetration tests are described two ways at once: by how much information the tester is given, and by what the engagement is trying to achieve. The first gives you black box, grey box and white box. The second gives you the distinction between a penetration test and a red team exercise. Choosing wrongly on either axis wastes a meaningful share of the budget.

The four in one table

Black box

The tester starts with what a stranger on the internet has: your domain name, or a range of addresses. Everything else is discovered. It is the closest simulation of an opportunistic external attacker, and it produces a genuine answer to one question, which is what an outsider can find and reach.

When it is the wrong choice. For any application with a login. You are paying senior day rates for reconnaissance you could have handed over in an email, and reconnaissance eats a third or more of a short engagement. Worse, a real attacker has unlimited time and your tester has five days, so the comparison to a real attack is flattering rather than accurate. The result is a report about your perimeter and TLS configuration, and silence about the authorization model where your actual risk lives.

Buy black box when the exposure surface itself is the question: after a merger, after a cloud migration, or when you genuinely do not know what your company has published to the internet.

Grey box

The tester gets credentials for each role, an architecture overview, and usually an API specification. This is the default for good reason. It skips the discovery phase and spends the budget on the testing that finds real problems, particularly the cross-role and cross-tenant work described on web application security testing.

The objection people raise is that a real attacker would not have credentials. In a SaaS product, a real attacker signs up for a free trial and now they do. In a corporate network, a real attacker phishes one person and now they have a workstation. Grey box is not a concession to convenience, it is the accurate threat model for most companies.

When it is the wrong choice. Rarely, but if the specific question is whether your perimeter is discoverable, credentials do not help answer it.

White box

Source code, configuration and design documentation are handed over, and testing runs alongside review of the code paths behind the behaviour observed. It finds the deepest issues per dollar, particularly logic errors, cryptographic mistakes, and flaws in code paths that are hard to trigger from the outside.

It costs more because reading code is slow, and it requires a tester who reads your language fluently. The output is different in kind: instead of a list of exploitable findings, you often get an architectural finding such as authorization being enforced per handler rather than centrally, which is worth more than any individual bug.

When it is the wrong choice. When you need evidence for a customer or an auditor that an outsider tested your defence. A white box review demonstrates code quality, and some procurement teams will read it as the developer marking their own work even when the reviewer is independent. It is also poor value on a system that is mostly configuration of third-party components, since there is little of your own code to read.

Red team

A red team engagement is not a bigger penetration test. It has an objective, such as reaching a specific dataset or obtaining domain administrator, and the team pursues it across whatever routes are permitted: external systems, phishing your staff, sometimes physical access. Testing typically runs for weeks, and detection is deliberately not warned.

What it measures is your security operations. Did anything alert. Did anyone notice. How long did it take, and what happened next. A red team report that lists vulnerabilities has missed the point. A red team report should read as a timeline: what was done, when, what fired, what did not, and what the responders did with the signals they got.

When it is the wrong choice. Most of the time, and this is the most commonly mis-bought product in security. If you do not have monitoring and someone whose job it is to respond, a red team will succeed on day two, tell you what you already knew, and consume $50,000 CAD or more that would have bought two thorough application tests. Red teaming is how a mature program finds its blind spots. It is not how an immature one gets started.

Types described by target rather than knowledge

The other vocabulary you will meet in proposals describes what is being tested rather than how much the tester knows. These combine freely with black, grey and white box.

Segmentation testing is worth naming separately because PCI DSS requires it explicitly. It verifies that the controls separating your cardholder environment from everything else actually hold, and it is the one test where a negative result is the entire deliverable.

Choosing without overthinking it

If a customer or an auditor asked for the test, buy grey box testing of the systems that hold their data, with a retest included. That satisfies SOC 2, ISO 27001 Annex A technical testing expectations, and most contractual clauses, and it puts the budget where findings actually are.

If you are testing because you are genuinely worried rather than because someone asked, say what you are worried about out loud and scope to that. The best engagement most companies could buy is a grey box application test with a white box element on the two or three components that would end the company if they failed.

Common questions