Black Box, Grey Box or White Box Pentest: When Do You Choose What?
When you request a penetration test, one of the first questions is: which approach do we use? Black box, grey box or white box? Each method has a different starting point, a different goal and different effectiveness. This article helps you choose.
Quick overview
| Approach | Tester’s prior knowledge | Best for | Time investment |
|---|---|---|---|
| Black box | None | External attack scenarios, perimeter | High |
| Grey box | Limited (user-level) | Web applications, APIs, SaaS | Medium |
| White box | Full | Compliance, code review, DigiD, ISO | Low (for equivalent coverage) |
Black box: the external attacker
The tester starts with zero information — just like a real attacker. The entire reconnaissance phase is part of the test. This gives the most realistic picture of what an external malicious actor could achieve.
Choose black box if:
- You want to know how robust your external perimeter is
- You want a realistic attack simulation with no hints
- You want periodic external validation (annual, red-team-like)
Downside: the reconnaissance phase takes time. You pay for hours that aren’t needed with grey box. For complex web applications, black box is often less efficient.
Grey box: the authenticated user
The most commonly used approach. The tester has a user account, but no admin rights or source code. This simulates an attacker who has obtained an account — via phishing, credential stuffing, or a leaked password list.
Choose grey box if:
- You’re testing a web application or portal
- You’re commissioning an API pentest
- You want efficiency without losing realism
- You’re testing a SaaS platform (see also SaaS pentest)
White box: the complete assessment
The tester receives source code, architecture documentation and sometimes admin rights. This enables a thorough assessment in less time — but doesn’t simulate an external attacker.
Choose white box if:
- You’re commissioning a DigiD IT security assessment (NIBAD requires this)
- You’re commissioning an ISO 27001 pentest
- You develop software in-house and want the code thoroughly reviewed
- You want maximum coverage in minimum time
Combinations are also possible
In practice, we often combine approaches. For example: a black box external reconnaissance followed by a grey box application test. Or a white box code review supplemented with a grey box runtime test. The combination depends on your scope, budget and objective.
What does MonkeysICT recommend?
- Web application or API → grey box
- External infrastructure, perimeter → black box
- Compliance-driven test (DigiD, ISO 27001) → white box
- Healthcare or government (NEN 7510, BIO) → grey or white box depending on scope
More on our methodology on the pentest methodology page.