You asked for a penetration test, and somewhere in the quote or the first sales call you were asked whether you want a black box, gray box, or white box test. It sounds like a technical choice, but it comes down to one thing: how much you tell the tester before they start. That single decision changes what the test costs, how long it takes, and which problems it finds. This article explains the three in plain terms and shows which one most companies need, so you do not end up paying for a harder-sounding test that misses what matters most. It is written for the person approving the test, not the person running it.
Quick Answers
Which type of penetration test does my company need?
For most apps with a user login, gray box is the best value: the tester works from a normal account and covers the most ground per dollar. Pick black box (tester starts with nothing) for a pure outside-attacker check, or white box (full access and source code) for critical systems and the strongest audit evidence.
Is black box testing the most realistic option?
Not usually. Black box copies a stranger with no access, but real attacks tend to start with a working login, whether phished, reused from a data breach, or belonging to an insider. Gray box copies that attacker, so it reflects how most breaches begin.
Does SOC 2, ISO 27001, or PCI DSS require a specific type?
No. None of them names or requires a specific box. PCI DSS asks for a documented testing methodology, and its tests are normally gray or white box, since starting a tester from zero wastes budget rediscovering what you could simply hand over.
What Each Box Means
The three names describe one thing: how much the tester knows about your system before the engagement starts. Everything else, the tools, the skill, the final report, can be identical. Only the starting knowledge changes, and that is what gives each approach its character.
Black box is the empty-handed start. The tester gets nothing: no login details (credentials), no internal diagrams, no copy of the code that runs the app (its source code). They begin the way an outsider would, through reconnaissance, the slow work of gathering whatever public information they can find before an attack is even possible. Picture a stranger at a locked building, working out which doors exist before trying any of them.
White box is the opposite. The tester is handed everything: logins for every type of user, architecture diagrams, and the source code itself. Nothing is hidden, so the hours go straight into finding real flaws instead of hunting for a way in. The image here is an auditor walking the building with the full set of blueprints.
Gray box sits between the two, and for most companies it is the one that fits. The tester gets a normal user account, sometimes a few accounts for different roles, and a little context about how the system is built, but not the source code. That mirrors the most common real attacker: someone already past the front door with a working account, whether a customer reaching features they should not, an insider, or an intruder logged in with an account that was never theirs. It is also where the expensive flaws tend to hide, which is why gray box usually earns its place as the default.
These Aren’t Three Levels of Quality
The three boxes are not good, better, and best. They are different starting points, and the right one depends on what you are trying to find out, not on which one sounds toughest. Black box has its uses, and so does white box.
For most companies, though, gray box is the one to default to. It covers the most ground for the money, because the tester skips the slow outside reconnaissance and goes straight to testing. It also matches how real attacks usually begin, with someone already holding a working login. The rest of this article helps you confirm which one fits your case.
The Three Boxes Side by Side
The table below lays the three approaches next to each other, across what the tester is handed, how much ground each one covers, and what it costs you in time and money.
| Black box | Gray box | White box | |
| What the tester gets | Nothing but public information | A user login and some context | Full access and the source code |
| Attacker it mimics | A stranger with no access | Someone already past the login | A fully informed insider or reviewer |
| Coverage | Narrow, mostly the outer surface | Broad | Deepest |
| Realism | High, but only for the rare no-access attacker | High, and the most common real case | Low |
| Speed | Slowest, reconnaissance comes first | Fast | Fast, nothing is hidden |
| Value for money | Lowest | Highest | High |
| Best for | A pure outside-in check on your perimeter | Most web apps, SaaS, and APIs; the default for the majority | Critical systems, code review, and the strongest audit evidence |
Why a Login Changes Everything
The clearest way to see why gray and white box find more is to look at the single most common serious flaw in web applications.
OWASP, the Open Worldwide Application Security Project, is a nonprofit whose rankings the industry treats as the benchmark for web security. At the top of its list of web-application risks sits broken access control: a logged-in user reaching data or actions that should be off-limits to them.
Picture a read-only account, the kind you might give a client to view their own invoices. By changing a single number in a web address, say from invoice 123 to invoice 124, that account pulls up a different customer’s invoice. The login works as intended, yet the app still exposes data that should be off-limits, because the flaw sits in the logic of who is allowed to see what.
Notice where that flaw lives: behind the login. A black box tester who starts with no account can spend the whole engagement just trying to get in and never reach it. A gray box tester starts with a login, so the test begins exactly where the costly problems are. Handing over a credential is not making the test easier, it is aiming it at the part of your app that holds the real risk.
How to Choose: Match the Box to Your Goal
The right box falls out of a single question: what are you trying to learn? Three goals cover almost every case.
You want to know whether an outsider can break in. If the worry is “can a stranger on the internet get through the front door,” black box is the honest test for it, and it is also the choice when leadership wants a true-to-life simulation with no help given. One caveat: if you also want to know whether your team would notice the intrusion, that is a red team engagement, a stealthier, goal-driven exercise that tests your defenders as much as your software, and it is worth asking for by name.
You have an app with logins and want real coverage for the money. This describes most companies, and the answer is gray box. A web app, SaaS product, or API with user accounts keeps its real risk behind the login, and a gray box test focuses the effort there instead of on breaking down the door. For the majority of buyers, start here, and move to another box only if a specific goal calls for it.
You run a critical system or need the deepest assurance. When the software handles money, health records, or anything you cannot afford to get wrong, or when an auditor or a major customer wants the most thorough evidence you can produce, white box earns its cost. Full access and the source code let the tester examine everything rather than sampling parts of it.
A quick word on budget, since it often pushes buyers the wrong way. A tight budget is a reason to lean toward gray box rather than away from it: the blind start of a black box test spends money on groundwork before it finds anything, so the same amount returns more real findings that way.
What Compliance Actually Wants
Many buyers assume their auditor expects a specific type of test. None of the major frameworks works that way. SOC 2, ISO 27001, and PCI DSS all care that testing happened, that the scope was credible, and that you can show evidence of what was found and fixed. The box is the tester’s method, not an audit requirement.
PCI DSS is worth a closer look, because it points the same way this article does. Its testing requirement calls for a documented methodology based on a recognized standard, and in practice PCI penetration tests are run as gray or white box; pure black box is the exception. Starting a tester from nothing would spend the engagement rediscovering details the company could hand over on day one, which no assessor counts as money well spent. So if compliance is the reason you are testing, the better-informed approach is already the expected one. CYBRI’s PCI penetration testing page covers how it is scoped.
SOC 2 and ISO 27001 follow the same logic. A SOC 2 Type 2 report and an ISO audit both look for evidence that testing was thorough and that findings were fixed and re-checked, and a gray or white box test, which exercises the whole system, leaves a richer record than a blind run that may stall at the perimeter. CYBRI’s SOC 2 penetration testing page maps the controls involved.
The same holds outside formal audits. When an enterprise customer or an insurer asks for a pentest, they want a credible report with real findings, not a box label. A thin report that found little because the tester never got in can look like weaker evidence than a gray box test with a few issues found and resolved.
What Comes in the Box
Whichever type you choose, the method behind the test stays the same. All three follow one recognized playbook built on public standards, not a private checklist. The engagement is shaped by NIST SP 800-115, the US government’s guide to security testing. The test cases draw on OWASP’s open catalogs for web apps and APIs, and every finding is rated on the CVSS 4.0 scale, the standard 0-to-10 severity score, so a “high” means the same thing from one test to the next. The box sets how much the tester knows on day one, not how carefully the work is done.
A CYBRI engagement is built on top of that. Every test includes:
- Senior, OSCP-certified testers, two to three per project, working manual-first and authenticated by default: gray or white box unless you ask for a pure outside-in test.
- A report for two audiences, a plain-language summary for leadership and auditors alongside a technical section for the people doing the fixes.
- Findings mapped to your framework, whether SOC 2, ISO 27001, PCI DSS, or HIPAA.
- Same-day alerts on anything critical, instead of waiting for the final report.
- About three months of remediation support and retesting, with testers on hand to answer questions and verify that each fix holds.
- One live dashboard, Blue Box, tracking findings, retests, and progress on CYBRI’s ongoing programs.
To find the box that fits your systems, tell CYBRI about your setup through the contact form.
Frequently Asked Questions
How much does a penetration test cost, and does the box type change the price?
The price is set by scope, not by the box. What drives it is how many apps, APIs, and user roles are in scope and how often you test, not whether the tester starts with a login. If anything, black box can cost more for less, since the tester spends paid hours on reconnaissance before reaching anything worth testing. See CYBRI’s pricing page for current ranges.
How long does a penetration test take?
Active testing usually runs one to three weeks, depending on how much is in scope. After that, CYBRI keeps a window of about three months open to support fixes and retest them, so the full engagement spans a few months from start to signed-off report.
Are black, gray, and white box the same as “closed box,” “clear box,” or “open box” testing?
Yes. The three approaches go by several names. White box is also called clear box, glass box, or open box testing; black box is sometimes called closed box; gray box, often spelled grey box, sits in between. The amount the tester is told is what matters, not the label.
Do we have to hand over our source code or production access?
It depends on the box. A gray box test needs only a user account or two. A white box test needs more, including the source code and architecture details. A black box test needs nothing at all. The work is normally done against a staging or controlled environment, with how your data is handled agreed before anything begins. CYBRI stays flexible here too, testing staging and production together, or production alone when that is the only environment you have, with safeguards in place from the start.
Pick the Box That Fits, Not the One That Sounds Toughest
You do not have to settle the black, gray, or white box question on your own. A short scoping call sorts out what you are trying to protect, what your auditor or customers expect, and which test gives you the most for your budget. Contact CYBRI to get started.
