The difference between black-box, grey-box and white-box pentests lies in how much prior knowledge and access the pentester receives before the test begins. Nearly all commercial pentests in the industry are performed as grey-box, because this approach offers the best balance between realism and depth. DongIT works with grey-box by default, unless your situation calls for a different approach.
Black-box pentest
The pentester starts without prior knowledge of the internal structure, code, architecture or documentation. This approach simulates an external attacker who encounters your application for the first time and attempts to break in.
When suitable
- When you want to know how well your perimeter (firewalls, WAF, IDS/IPS) detects an external attack
- For red-teaming assessments where realism matters more than completeness
- For compliance scenarios that specifically require an external attack simulation
When less suitable
- When you want full application coverage within a fixed budget: black-box is less efficient
- When you want to find vulnerabilities behind authentication or in business logic: these are often unreached
Grey-box pentest
The pentester receives limited prior knowledge: for example, test accounts for different user roles, a high-level architecture description and access to API documentation. This is the industry standard for commercial pentests and the default approach at DongIT.
When suitable
- For most web, mobile and API pentests within a fixed budget
- When you want to investigate both external and authenticated internal threats
- For compliance audits under ISO 27001, DigiD, NIS2 and NEN 7510
- For SaaS platforms with multiple user roles and tenants
When less suitable
- When you want to specifically test perimeter detection (choose black-box instead)
- When you want a thorough code analysis (choose white-box or add a source code review)
White-box pentest
The pentester receives full access to source code, architecture documentation, configuration files and internal systems. This delivers the most thorough analysis, often in combination with a source code review.
When suitable
- For critical applications processing financial transactions, medical data or government data
- For compliance requirements mandating code review (PCI DSS, DORA, MIAUW methodology)
- For pre-release verification of software before production deployment
- When you want to find vulnerabilities only visible at code level (race conditions, cryptographic flaws, unsafe deserialization)
When less suitable
- When you want a realistic external attack simulation: white-box is inherently less realistic
- For applications with limited scope and budget: white-box requires significantly more time
Comparison table
Black-box | Grey-box | White-box | |
|---|---|---|---|
Prior knowledge | None | Limited (accounts, docs) | Full (incl. source code) |
Perspective | External attacker | External and authenticated | Insider with full access |
Realism | High | Medium to high | Lower |
Depth | Limited to perimeter | Balanced | Maximum |
Duration | Longer per finding | Most efficient | Extensive analysis |
Best suited for | Perimeter and red-team | Regular pentests | Compliance and code |
Which approach fits my situation?
For most organizations, grey-box is the right choice and this is also the default approach in all DongIT pentest packages. Our pentesters receive test accounts for different user roles, a high-level architecture description and access to relevant documentation. This delivers a balanced test that covers both external and authenticated threats.
For critical applications, we offer a source code review as an addition to the pentest, where our experts analyze the source code for vulnerabilities that are only visible at code level. For red-teaming assessments, we work with a black-box approach when requested.
Not sure which approach fits your situation? Contact us for a complimentary scoping conversation, or view our pentest packages.
Nederlands