Our Approach to Penetration Testing: Black-Box, Grey-Box, and White-Box Explained

"How much access should the testing team have?" is one of the first questions in scoping any penetration test, and the answer meaningfully changes what the engagement can find. Here's how we think about it.

The three testing models

Black-box testing gives testers no prior knowledge or access, the same starting position as an external attacker with no inside information. It's the most realistic simulation of an opportunistic outside attacker, but it spends a meaningful share of the engagement on reconnaissance rather than deep exploitation, which limits coverage within a fixed timeframe.

White-box testing gives testers full access up front, source code, architecture diagrams, credentials, internal documentation. This maximizes coverage and depth: testers can review logic that would take days to reverse-engineer from the outside, and focus their time on finding and validating real issues instead of mapping the environment blind.

Grey-box testing sits in between, testers get partial information or limited credentials, similar to what a malicious insider, a compromised low-privilege account, or an attacker who's already gained an initial foothold would have. For most organizations, this is the highest-value default: it skips the reconnaissance overhead of black-box testing while still exercising realistic privilege-escalation and lateral-movement paths, rather than starting from a position of full trust.

How we choose

There's no universally "correct" model, it depends on what you're actually trying to learn:

• Testing your perimeter's realistic exposure to an outside attacker with zero prior access? Black-box.
• Trying to get maximum coverage of a specific application before a release, on a fixed timeline? White-box.
• Simulating what happens after a phishing click or a leaked low-privilege credential? Grey-box.

Many of our engagements actually combine models, a black-box external phase to validate perimeter exposure, followed by a grey-box internal phase once initial access is assumed. The point is to match the test to a realistic, relevant threat scenario for your organization, not to default to whichever model is easiest to scope.

What doesn't change between models

Regardless of access level, our process stays the same: manual validation of every finding (not just automated scan output), risk ratings tied to actual business impact, a report written for both engineers and leadership, and retesting to confirm fixes actually close the gap. The access model changes what we can look at, not the rigor we apply to it.

See our Penetration Testing service page for the full methodology, or get in touch to talk through which model fits your situation. For a concrete look at what "chaining findings" actually means in practice, see our piece on Active Directory attack paths.