Black Box vs Grey Box vs White Box Penetration Testing

These terms describe how much knowledge the tester is given before testing starts. Black box gives nothing — the tester starts with only a URL or IP, simulating an external attacker. Grey box gives partial knowledge — credentials for normal user accounts, documentation, role descriptions — simulating an authenticated user. White box gives everything — source code, architecture, admin credentials — simulating an insider or supporting a code-level security review.

For most Australian engagements: grey box. It produces the best depth-to-time ratio and tests the authorisation and business-logic flaws that cause real-world breaches. Choose black box for red team exercises or testing your external attack surface. Choose white box for high-stakes components (authentication, cryptography, payment flows) or insider-threat scenarios. Combinations are common — black-box external testing plus grey-box authenticated testing in the same scope.

Most frameworks don’t specify, but auditors have expectations. ISO 27001 Annex A.8.8, SOC 2 Trust Services CC7.1, PCI DSS v4.0.1 Req 11.4 and APRA CPS 234 are all framework-agnostic — they expect documented testing, not a specific knowledge model. In practice, grey box is the default expectation for most compliance-driven engagements because it produces the most useful evidence in the available budget.

Only for one attack scenario — the unauthenticated external attacker. For most actual breaches, attackers either get credentials (phishing, credential stuffing, leaked secrets) or have legitimate access (insider, compromised partner). Grey box testing — simulating an authenticated user — better matches the realistic attacker post-initial-access, which is where most damage happens. Both have legitimate realism claims; they simulate different stages of an attack.

Because testers spend the first several days re-discovering what you already know — your assets, technologies, user roles, authentication mechanism, URL structure. That’s days of expert time before any actual vulnerability testing starts. Grey box engagements skip that rediscovery phase, putting more testing hours into the parts of the work where bugs actually live. Same budget, deeper coverage.

Only for white box engagements where it’s necessary for code-level review of high-stakes components. For grey box engagements, source code isn’t required and often isn’t beneficial — testers benefit from operating as an authenticated user would, not as a developer reviewing code. If you do share source code, ensure your NDA covers it explicitly and the tester team includes someone with code-review credentials.

Yes, in sequence or in combination, but it’s rarely cost-effective for a single engagement. The typical pattern is: grey box for the main annual pentest, black box for periodic external-attack-surface testing or red team exercises, and white box for one-off code-level reviews of new high-stakes features. Most Australian businesses run grey box annually with occasional supplementary engagements rather than running all three at once.

No, but they overlap. A code review is a structured manual reading of source code looking for vulnerability patterns. White box pentesting uses the source code as an input to inform testing of the running system. The pentest still exercises the application; the source code informs where to look and helps explain unexpected behaviour. Code review + white box pentesting together produces the deepest security signal — but at significantly higher cost.

These are alternative names for white box testing — the tester has full visibility into the system being tested, like looking through a clear container. The terms are used interchangeably. ‘Crystal box’ is sometimes preferred when emphasising visibility; ‘glass box’ when emphasising transparency of the testing approach. They’re the same model.

Yes — grey box. Unless your scope, compliance framework, or specific scenario requires otherwise, Penva Security engagements run as grey box because it produces the best results for the typical Australian buyer. We’ll specifically ask during the scoping call whether your engagement needs black box (red team / external focus) or white box (code-level review) instead. The choice is always yours, not ours.