Black box, gray box, white box. Three ways to scope a pentest.

Black box. The tester starts with the same information a random outside attacker would have: a name, a URL, an IP range. No credentials, no documentation, no architecture diagrams. The first phase of the engagement is reconnaissance and discovery. Authentic but slow, and the bulk of time goes into mapping rather than testing.

Gray box. The tester starts with limited internal information: a typical-user account or two, basic documentation, sometimes a high-level architecture diagram. Mirrors an attacker who has compromised a normal employee or customer account, or an insider with low privileges. Most engagements are gray box because the trade-off between realism and coverage is best.

White box. The tester starts with maximum information: source code, full architecture diagrams, administrative credentials, configuration files. The engagement focuses entirely on finding weaknesses, not discovering the system. Highest coverage in a given time budget; least realistic in attacker simulation.

• Black box finds weaknesses an outside attacker would actually reach. Misses anything that requires authenticated access the tester could not obtain in the engagement window. Slower per finding because of the discovery overhead.
• Gray box finds the broadest realistic mix: outside attacker paths plus the authenticated paths a compromised user would have. The combination most useful for most applications.
• White box finds the most weaknesses overall, including ones that would never be reached by an outside attacker but matter for defence in depth. Code-review and architecture-review findings appear here that would not appear in black box.

Three rules of thumb that hold for most engagements:

• Default to gray box. Best trade-off between realism and coverage. Most engagements should be gray box unless there is a specific reason to choose otherwise.
• Choose white box when you are testing before launch (you want maximum coverage in a short window), when the application is complex with significant business logic, or when source code review is in scope.
• Choose black box when you specifically want to know what an outside attacker would reach (often for board reporting or after a near-miss incident), or when external attack-surface measurement is the goal.

A few engagements combine approaches: an initial black box phase for realism, transitioning to gray box once the tester has reached internal access through legitimate exploitation.

• Black box is not more thorough. It is more realistic but covers less ground in the same time window. The tester spends a large fraction of the engagement on reconnaissance the customer already has documented.
• White box is not 'cheating'. It is the most efficient way to cover the system in a fixed window. The realism trade-off is the cost, not a quality issue.
• Gray box does not need to be perfectly defined. A typical user account plus an admin account is enough for most engagements. The tester does not need every credential up front.
• Authenticated vs unauthenticated is a separate question. Authenticated testing means the tester has a working account in the application. White box means the tester also has source and architecture. They are not the same axis.

Most compliance frameworks (PCI DSS, SOC 2, ISO 27001, HIPAA) do not mandate which approach to use. They require that penetration testing happens against the scope at the required cadence. The choice of approach is left to the customer and the tester to agree.

Procurement and customer-due-diligence questions sometimes ask 'was this a black box test?' as a proxy for 'how realistic'. The honest answer is usually 'gray box' for most engagements, with a clear explanation of what that means. Black box claims that are not actually black box (because the tester got documentation halfway through) damage credibility.