Business Guide

Types of Penetration Test: Black Box, White Box, and Grey Box Explained

> series: business_owners_guide —— part: 02/10 —— topic: types_of_penetration_test —— approach: know_your_options<span class="cursor-blink">_</span>_

Hedgehog Security 13 January 2026 11 min read

Not all penetration tests are the same.

When a penetration testing provider quotes you for an engagement, one of the first questions they should ask is what type of test you need. This is not a trick question — it directly affects the scope, methodology, duration, and cost of the engagement. Understanding the different types of penetration test ensures you commission the right assessment for your specific risks and objectives.

There are two dimensions to consider: the testing approach (how much information the tester starts with) and the testing category (what they are testing). This article covers both.


Recommended

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

How much does the tester know upfront?

The amount of information you provide to the tester before the engagement begins fundamentally changes the nature of the test. Each approach answers a different question, and the right choice depends on what you are trying to learn.

Approach What the Tester Knows What It Simulates
Black Box Nothing — or almost nothing. The tester receives your company name and perhaps a list of in-scope IP addresses or domains, but no internal documentation, credentials, architecture diagrams, or source code. They start from the same position as an external attacker with no inside knowledge. An opportunistic external attacker — a criminal who has identified your organisation as a target and is working from scratch. Tests your external attack surface and how much an attacker can discover and exploit without any insider assistance.
White Box Everything. The tester receives full documentation — network diagrams, architecture documents, source code, credentials, configuration files, and direct access to development and operations teams for questions. Nothing is withheld. A worst-case scenario — an attacker with complete inside knowledge, or a comprehensive security review that aims to find as many vulnerabilities as possible regardless of how an attacker might discover them. Maximises vulnerability discovery.
Grey Box Partial information. The tester receives some insider knowledge — typically user-level credentials, basic network documentation, or application architecture details — but not full access. The exact level of information is agreed during scoping. A range of realistic scenarios: an attacker who has compromised a user account, a disgruntled employee with standard access, or a partner with limited network connectivity. Balances realism with depth of testing.

Which Approach Should You Choose?

For most organisations, grey box testing offers the best balance of realism and value. Black box testing is realistic but time-limited — the tester may spend days on reconnaissance that could be bypassed with basic information, reducing the time available for actual exploitation. White box testing finds the most vulnerabilities but does not reflect a realistic attack scenario. Grey box gives the tester enough context to focus on exploitation rather than discovery, while still testing from a credible threat perspective.


What is being tested?

The testing approach determines how much information the tester has. The testing category determines what they are targeting. Most organisations need more than one category of test, and different categories may use different approaches.

External Infrastructure Testing
Tests everything visible from the internet — your public-facing servers, firewalls, mail servers, DNS, VPN gateways, and any other services exposed to the outside world. This is typically the first penetration test an organisation commissions, because external infrastructure is what attackers see first. The tester scans your IP ranges, identifies services, and attempts to exploit vulnerabilities to gain access.
Web Application Testing
Focuses specifically on your web applications — customer portals, e-commerce platforms, APIs, content management systems, and internal web tools. Tests for the OWASP Top 10 vulnerability categories including injection, broken authentication, cross-site scripting, and access control failures. Also tests business logic — can a user manipulate a price, access another user's data, or bypass a workflow?
Internal Infrastructure Testing
Simulates what an attacker could do from inside your network — either after breaching the perimeter or as a malicious insider. Tests Active Directory security, network segmentation, internal application security, privilege escalation paths, and lateral movement. Often reveals the most severe findings, as internal networks are frequently less hardened than external-facing infrastructure.
Wireless Network Testing
Assesses your Wi-Fi infrastructure — encryption standards, authentication mechanisms, rogue access point detection, client isolation, and segmentation between wireless and wired networks. Tests whether an attacker in your car park or reception area could connect to your network and what they could access if they did.
Social Engineering
Tests the human layer — phishing campaigns, vishing (telephone-based social engineering), pretexting, and physical access attempts. Measures how effectively your staff can identify and respond to social engineering attacks. Often combined with other test types to demonstrate realistic attack chains: a phishing email delivers initial access, followed by internal network exploitation.
Mobile Application Testing
Assesses your iOS and Android applications for vulnerabilities including insecure data storage, weak authentication, certificate pinning issues, and API security flaws. Relevant if your organisation publishes mobile applications for customers or employees.

Building a complete picture.

Real attackers do not limit themselves to a single attack vector. A comprehensive security assessment often combines multiple test categories to simulate realistic attack scenarios. For example, an attacker might use a phishing email to compromise a user's credentials, use those credentials to access a web application, exploit a vulnerability in that application to reach the internal network, and then escalate privileges through Active Directory misconfigurations.

This does not mean every organisation needs every type of test simultaneously. Prioritise based on your risk profile: if you have significant internet-facing infrastructure, start with external and web application testing. If your primary concern is insider threat, start with internal testing. If you have recently deployed security awareness training, a social engineering assessment measures its effectiveness.

Typical Testing Programme by Organisation Size
── Small Organisation (1–50 staff) ──────────────────────────
Year 1: External infrastructure + web application test
Year 2: Repeat external + add internal infrastructure
Year 3: Full cycle — external, internal, web app, social eng.

── Medium Organisation (50–250 staff) ────────────────────────
Year 1: External + internal + web application
Year 2: Repeat all + add wireless + social engineering
Ongoing: Quarterly web app testing for critical applications

── Large Organisation (250+ staff) ───────────────────────────
Annual: Full programme — all categories, all approaches
Quarterly: Web application testing for public-facing apps
Ongoing: Continuous external monitoring + ad-hoc testing
Event: Test after any major change (merger, migration, etc.)

Understanding the distinction.

You may also hear the term 'red team engagement'. This is not a synonym for penetration testing — it is a distinct activity with a different objective. A penetration test aims to find as many vulnerabilities as possible within a defined scope. A red team engagement aims to achieve a specific objective — such as accessing a particular database, exfiltrating specific data, or compromising a specific account — using any means necessary, over a longer timeframe, with stealth.

Red team engagements are typically commissioned by more mature organisations that have already addressed the findings from regular penetration testing and want to test their detection and response capabilities. They are more expensive, take longer, and are designed to answer the question 'can our security team detect and respond to a sophisticated, targeted attack?' rather than 'what vulnerabilities exist in our systems?'

For most organisations, penetration testing is the right starting point. Red teaming is the next step once your baseline security posture is solid.


What to remember.

The type of penetration test you commission should be driven by your organisation's risk profile, the threat model relevant to your industry, and your current security maturity. A reputable provider will help you determine the right combination during the scoping process — which we cover in detail in Part 5 of this series.

Next week, in Part 3, we address a critical question for business owners: when should you commission a penetration test? We cover the trigger events, compliance deadlines, and business scenarios that should prompt you to pick up the phone.


We will help you work it out.

Choosing the right type of penetration test does not need to be complicated. Our scoping consultations are free, obligation-free, and designed to help you understand exactly what testing your organisation needs and why.

Next Step

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Related Articles