Penetration Testing Types and Scope: Black, White, Grey Box and Target Types

Quick answer: A pentest is not a single service. It is chosen along two separate axes: how much information the tester is given (black box means zero knowledge, grey box partial, white box full knowledge including source code) and the type of target (network, web, API, mobile, cloud, wireless, social engineering, physical). The right type is decided not by budget but by what you want to prove. Are you resilient to an outside attack, or how far does someone who gets inside actually go? These are two separate tests.

A company calls us and says, "we want a pentest, what is the price?" That is like saying, "we want surgery, how much?" Which organ? Which method? What are we treating? In penetration testing, the first question is not price either. The first question is: what do you want to prove? The answer determines, from the start, which type and which scope the test will cover. Choose the wrong type and the report looks full, but your real risk sits untouched.

In this article we open the pentest along its two axes: the knowledge level given to the tester, and the type of target. We covered how the process runs step by step, how long it takes and how it is priced in our penetration testing process and pricing guide; here the focus is entirely on choosing the type and scope.

First axis: How much does the tester know? (Black, White, Grey Box)

The first distinction in a pentest is how much information the testing team is given. This choice directly determines the realism, speed and depth of the test. The difference between the three is not academic; in practice it produces completely different reports.

Black box: zero knowledge, like a real attacker

In a black box test, the team knows only what an outside attacker would know: maybe just a domain name, maybe an IP block. No source code, no architecture diagram, no account. The team discovers everything from scratch, exactly like an attacker who has never met you.

The strength of this approach is its realism. The attacker does not see your internal documents either. But it has a cost: the reconnaissance phase consumes time, part of the scope is never reached before the budget runs out, and flaws in the deeper layers (a logic bug that would be obvious in source code, for example) may never be found. Black box answers the question "can an outsider get through the door?" most honestly, but there is rarely time left to walk every room inside.

White box: full knowledge, including source code

In a white box test the team is given everything: source code, architecture documents, network diagrams, privileged accounts, even access to the developers. Here the goal is not to imitate an attacker but to find every possible flaw in the system as quickly and as deeply as possible.

White box is both the fastest and the most thorough. No time is spent on discovery; the team goes straight to the risky points. Combined with source code review, it surfaces logic flaws, hidden endpoints and authorization errors that black box testing could never see. Its drawback is that it does not answer "could a real attacker have found this?" But if you genuinely want to raise security, and the goal is to find and close the most flaws rather than to prove a scope, white box is often the smartest choice.

Grey box: partial knowledge, balanced middle ground

Grey box sits between the two. The team is given limited information: maybe a standard user account, maybe basic architecture knowledge, but not the full source code. This is the most commonly chosen approach in the industry, and for good reason.

Grey box most realistically models the "authorized but malicious insider" or "attacker who has obtained credentials" scenario. It shortens the reconnaissance time spent under zero knowledge, but by not telling the tester everything, it preserves realism. The most efficient balance between budget and depth is usually here.

Dimension Black box Grey box White box
Information given None (only the target) Partial (account, basic architecture) Full (source code, diagrams, accounts)
Realism Highest High Low (not an attacker simulation)
Speed Slowest Medium Fastest
Depth of flaws found Limited (surface) Good balance Deepest (logic + code)
Best suited for "What do we expose outside?" Most corporate tests "Find every flaw, close it fast"
Typical cost/time High Medium Efficient

As DSET we say this plainly: black box is not automatically the best choice just because it sounds cooler. For most companies, grey box or white box closes far more real flaws for the same budget. We choose black box when you need to prove the resilience of the externally visible surface, for example for a compliance audit or a customer requirement.

Second axis: Where does the test start? (External and Internal)

Independent of the knowledge level, there is a second distinction: the position of the test.

External pentest targets your internet-facing assets: websites, mail servers, VPN gateways, open ports. The question is clear: can someone outside get in?

Internal pentest assumes the attacker is already inside the network. Maybe they slipped onto a machine through a phishing email, maybe it is an insider. Now the question changes: how far can someone who is already inside go? From a user machine to the domain administrator, and from there to all the databases, in how many steps?

A clear warning from our field experience here: the internal network test is most companies' biggest blind spot. Organizations spend the entire budget on the outer wall, because the belief is that "the threat comes from outside." Yet in most real breaches the attacker is already inside at the first step; a password, a phishing email, a supplier account is enough. If your internal network is flat and unprotected, no matter how high your outer wall is, everything is open after the first gap. This is why the modern testing approach shifts toward the "assumed breach" model: we start the test as if the attacker is already inside and measure the blast radius of the damage.

Third axis: What are we testing? (Target types)

After choosing the knowledge level and position, the real scope comes: which technology surface are we testing? Each has its own method, its own toolset and its own expertise.

Network and infrastructure pentest

Servers, firewalls, routers, Active Directory, exposed services. Unpatched systems, weak configurations, default passwords and in-network lateral movement chains are tested here. This is the backbone of the corporate internal network test.

Web application pentest

The most requested type. The target is the business logic and input-handling layer of your web application: SQL injection, XSS, broken access control, authorization bypass, session management. Here the methodology aligns with the OWASP Web Security Testing Guide (WSTG); it provides a systematic and repeatable scope.

API pentest

Modern applications are no longer a "page" but run through the APIs behind them. REST, GraphQL, mobile backends. API testing differs from web testing: without a browser interface, endpoint authorization, object-level access control (BOLA/IDOR), excessive data exposure and rate limiting are tested directly. It requires separate expertise. We detail how the API layer is tested and protected in our API security testing and protection service.

Mobile application pentest (Android and iOS)

Mobile testing has two fronts: the client app on the device (local storage, certificate pinning, resistance to reverse engineering) and the backend API. The methodology follows the OWASP Mobile Application Security Testing Guide (MASTG). The distinct storage and encryption behaviors of the Android and iOS platforms are handled separately.

Cloud pentest (AWS, Azure)

In the cloud the target is not the server but the configuration. Misconfigured IAM roles, publicly exposed storage buckets (S3 buckets), over-privileged service accounts, open management panels. Cloud testing targets the layer that falls under your responsibility within the provider's shared responsibility model; it is a completely different discipline from classic network testing.

Wireless (WiFi) pentest

The security of corporate wireless networks: weak encryption, rogue access points, WPA handshake capture, and whether the guest network is truly separated from the corporate network. It requires physical proximity and is usually done on site.

Social engineering and phishing

Even the strongest firewall cannot stop an employee from entering their password into a fake email. The social engineering test targets the human layer: spear phishing campaigns, phone-based information disclosure (vishing), fake login pages. The goal is not to punish the employee but to measure the organization's awareness and response maturity.

Physical pentest

Unauthorized entry to the building, access card cloning, unlocked sessions left on desktops, access to cabling cabinets. No matter how solid the digital security is, if someone can walk into the server room the story changes. It is the least requested type but critical in some sectors.

Assumed breach: the standard of modern testing

A classic external test asks "can they get in?" But if advanced attackers are already finding a way, that question alone is insufficient. In the assumed breach approach, we accept that the attacker has already obtained a foothold and start the test from there: a user machine, a limited account, a small gap.

This model, without spending the entire budget on the front door, measures where the real damage occurs. Once an attacker is inside, how far can they advance, what data do they reach, how long do they go unnoticed? Mature organizations are increasingly shifting their tests to this model, because the "unbreakable" assumption is no longer realistic. What matters is what happens once they are in.

Which type, and when? A decision guide

  • You need to prove the external surface for compliance/audit: External + black/grey box, web and network scope.
  • A new application is going live: White or grey box web + API pentest, together with source code review.
  • You want to measure your internal network's post-breach resilience: Internal + assumed breach, Active Directory focused.
  • You have a mobile application: MASTG-aligned mobile + backend API test.
  • You moved to the cloud: Configuration-focused cloud test, prioritizing IAM and storage.
  • You are unsure about employee awareness: Social engineering + phishing campaign.

There is no single right answer. Most mature organizations spread these across an annual plan: external web every year, internal network and assumed breach every two years, application testing on major releases. We covered what to watch for when choosing a firm in our how to choose a penetration testing firm article. For regional service, see our Istanbul penetration testing page.

Frequently Asked Questions (FAQ)

Is a black box test more reliable than white box? No, it is only more realistic. Black box answers "what does an outsider see?" but can miss deep flaws. White box usually finds far more real vulnerabilities for the same budget. Which one is right depends on what you want to prove.

Is an internal network test really necessary if we invested heavily on the outside? Yes, and for most companies it is the most critical gap. In most real breaches the attacker is already inside at the first step. No matter how high your outer wall is, if your internal network is flat and unprotected, everything is exposed after the first gap.

Is API testing not part of web testing? No, it is a separate discipline. APIs have no browser interface; authorization, object-level access control and data exposure are tested with different methods. Assuming the API layer is tested just because a web test was done is a common and dangerous mistake.

Does an assumed breach test mean admitting we failed? No, on the contrary, it is a sign of maturity. Modern security focuses on "what happens once they are in and how fast do we notice" rather than "they will never get in." This test measures the real blast radius so you can direct your defense there.

Should we do all the types at once? Usually no. For most organizations the most efficient path is to spread the types across an annual plan by risk priority. First the highest-risk surface (usually external web and internal network), then application and API tests on major releases.

Sources

DSET has been providing cyber security and penetration testing services since 2003 at Hacettepe Teknokent Beytepe, Ankara. If you are not sure which type and scope of test you need, let us start with the question "what do you want to prove?" Let us define the right scope together. Phone: +90 536 662 38 09