Black box, grey box or white box pentest: which one fits?

TL;DR

• The difference is what the tester knows before the test starts: only the target (black box), limited knowledge such as a test account and documentation (grey box), or everything including architecture and source code (white box).
• Black box gives the most realistic picture of an outside attacker. It also spends the most time on discovery.
• Grey box is the usual choice for web applications and APIs with a login: depth behind the login without handing over everything.
• White box gives the highest assurance and answers architecture questions. It asks the most preparation from your team.
• Pick the form by the question you want answered, not by how impressive it sounds.

Every pentest proposal runs into the same early question: how much do we tell the testers up front? The answer sets the form of the test, and it sets what the report can and cannot tell you. The three forms are named after how much the tester sees. Black box means the tester starts with the target and nothing else. Grey box means limited knowledge, usually a test account and some documentation. White box means full knowledge: architecture diagrams, source code, configuration. In a penetration test by Sectricity, all three forms follow the same route: AI-assisted reconnaissance, manual testing by ethical hackers, validation of every finding and a retest after you fix things. If the test has to serve an audit under NIS2, ISO 27001, DORA or GDPR, the audit-ready pentest adds a compliance mapping and an attestation letter on top. The form of the test does not change any of that. It changes where the testers start and how far they get.

What the tester knows before the test starts

Black box: the tester knows the target. A domain name, an IP range, an app in the store. Everything else comes from reconnaissance: what is reachable, what software runs there, where the inputs are. The tester behaves like an outsider who found you on the internet and has time.

Grey box: the tester gets some help. Usually a test account per user role, a short description of what the application does, sometimes API documentation or a network diagram. The tester still has to find the weaknesses, but does not lose days guessing which part of the app matters.

White box: the tester sees what your own developers see. Source code, architecture, infrastructure configuration, sometimes a staging environment with debug logging switched on. Discovery takes little time. Nearly all the hours go to analysis: how the pieces fit together and where that breaks.

The names come from the colour of the box the tester looks at: opaque, half transparent, fully transparent. What the tester may do once inside follows the scope you agree, whatever the colour.

The three trade-offs

Discovery time versus depth. A tester has a fixed number of days. In a black box test, a good share of them goes to finding out what is there. In a white box test that part is nearly free, so the same days go to depth: business logic, authorisation between roles, the piece of code nobody has looked at since the first release. Neither is wrong. They answer different questions.

Realism versus coverage. Black box is the closest you get to a real external attacker, which is a strong argument when a board or an insurer asks what an attacker would find. The price is coverage: what the tester does not find in the available time stays untested, and a report cannot list what it did not see. White box flips that. Coverage is high, realism is lower, because a real attacker rarely has your source code. Grey box sits in between and is honest about it.

What your team hands over. Black box asks almost nothing of you beyond a signed authorisation and a contact for emergencies. Grey box asks for test accounts, a walkthrough and someone who answers questions during the test. White box asks for code access, architecture documents and developer time. That preparation often decides the choice in practice: a team that cannot free up a developer for a week is better off with a well-prepared grey box test than with a white box test nobody supports.

Which form fits which question

If your question is "what does an outsider see and how far do they get?", choose black box. Typical for the external perimeter of your network, a public website without login, or a first test of an organisation that has never been tested. It also works as a check after a large migration.

If your question is "is our application safe for logged-in users and for the data behind the login?", choose grey box. That covers most web applications and APIs. Authorisation errors between user roles, insecure direct references to objects and logic flaws in flows like checkout or password reset only show up when the tester can log in. A black box test would spend its days outside the door. We described what such a test looks like in practice in our earlier post on web application penetration testing.

If your question is "how sure do we want to be?" or "is this architecture sound?", choose white box. Typical before a product launch, after an incident, for software you sell to other companies, or when an auditor wants evidence that a specific set of controls works. Also the right form when you want the code reviewed alongside the running application.

Our view, for what it is worth: most organisations that come to us for a first test ask for black box because it sounds the most like a real attack, and leave with a grey box proposal because that is what answers their real question. There is nothing wrong with that. The attacker who matters most to a web application usually already has an account.

Combining forms in one engagement

The three do not exclude each other. A common pattern is a short black box phase for the external picture, followed by grey box behind the login. Another is grey box on the application plus white box on one critical component, such as the authentication module. The rest of the scoping conversation is in our pentest checklist and in the post on what a pentest is. What stays the same across forms: every finding is validated by a person, critical and high findings are reported during the test rather than kept for the final report, and the retest after your fixes is part of the engagement.

Frequently asked questions

What is the difference between a black box, grey box and white box pentest?

The amount of knowledge the tester has before the test. Black box: only the target. Grey box: limited knowledge, such as a test account and documentation. White box: full knowledge, including architecture and source code.

Is a black box pentest more realistic?

For an external attacker without inside knowledge, yes. For an attacker who already has an account, or an insider, a grey box test is closer to reality. Realism depends on which attacker you are worried about.

Which pentest type is best for a web application or API?

Usually grey box. A test account per user role lets the tester check authorisation and business logic behind the login, which is where most serious web application findings sit. See our web application pentest.

Does a white box pentest take longer?

Not necessarily. It spends less time on discovery and more on analysis. What it does ask for is preparation on your side: code access, architecture documents and a developer who can answer questions.

Which form do auditors expect for NIS2 or ISO 27001?

The frameworks ask for testing proportionate to the risk, not for a specific form. What auditors want is a signed report with scope, method, findings and evidence of fixes. Our audit-ready pentest maps the findings to the framework whichever form you choose.

What do we need to prepare for a grey box pentest?

Test accounts per user role, a short walkthrough of the application, any API documentation you have, and a contact who can answer questions during the test.

Related services and resources

Start with our penetration testing services for the overall approach, and with the audit-ready pentest if the report has to serve NIS2, ISO 27001, DORA or GDPR. For grey box work on applications, see the web application pentest and the API pentest. For background, read what a pentest is, the pentest checklist, how to read a pentest report and our comparison of AI pentests and human pentests. Teams that test more than once a year can also look at RedSOC.