Most penetration testing proposals you receive will be black box by default. The tester gets a URL, no credentials and no source code, and spends the first third of the engagement working out what your application does. That is a reasonable model for simulating an opportunistic external attacker. It is a poor model for finding the flaws that actually get exploited in a targeted breach.
White box penetration testing inverts the arrangement. The tester receives source code, architecture documentation, credentials for every role, and access to your build pipeline. Coverage rises sharply because nobody is spending budget on reconnaissance. The trade off is that the engagement no longer simulates an outsider, and a tester who cannot read your stack properly will drown in code.
This guide covers how to decide whether white box is right for your application, how to compare providers on something firmer than a day rate, and what a defensible scope looks like.
When white box is the right call, and when it is not
The decision is mostly about what you are trying to learn.
Choose white box when you need assurance about a specific, high value component: a payments flow, an authorisation model, a tenancy boundary in a multi tenant SaaS. These are logic problems. An outsider probing blindly may never reach the state where the flaw appears, while a tester reading the authorisation middleware finds it in an afternoon.
Choose black box when you need to answer a different question: what can somebody with no inside knowledge achieve against our perimeter in two weeks. That is a legitimate question, and white box does not answer it.
Grey box sits between the two and is what most mature programmes actually buy. The tester gets credentials for each user role and a data flow diagram, but no source code. It catches authorisation flaws, which are the most commonly missed class, without the cost of a full code review.
A practical rule: if your last two incidents were configuration or dependency problems, white box will find more. If you have never had a test at all, start with grey box and establish a baseline.
There is a sequencing argument too. Running black box first and white box second on the same application produces a useful comparison: anything the white box test found that the black box test missed is, roughly, the value your obscurity is currently buying you. That is worth knowing, because obscurity is not a control and it erodes the moment somebody leaks a repository or a former employee remembers an endpoint.
What the standards actually require
Four documents govern serious penetration testing work, and knowing which one a provider follows tells you more than any certification logo.
PTES, the Penetration Testing Execution Standard, defines seven phases: pre engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. A proposal that jumps straight to exploitation without threat modelling is selling you a vulnerability scan.
OWASP WSTG, the Web Security Testing Guide, is the most detailed web specific methodology available and it is free. Ask which WSTG test categories the provider will cover and which they will skip. A provider who cannot answer at that granularity has not scoped your application, they have priced a template.
NIST SP 800-115 is the technical guide to information security testing and assessment. It is older, published September 2008, but it remains the reference most US federal and regulated buyers expect to see named.
PCI DSS governs anything touching cardholder data. Here is a detail worth checking: in PCI DSS v4.x penetration testing sits under Requirement 11.4, not 11.3. The 11.3 numbering belongs to v3.x. A provider proposal still citing 11.3 in 2026 is working from stale material, and that tells you something about how current the rest of their methodology is.
Certifications are worth less than methodology, with one exception. CREST accreditation assesses the firm's processes rather than an individual's exam results, so it tells you something about how engagements are run. Individual certifications tell you what one person passed, sometimes years ago. Ask about both, weight the methodology answer higher.
How to score providers
Day rates are not comparable across providers because the unit of work is not the same. One firm's day is a senior tester with your source code open. Another's is a junior running an automated scan and reformatting the output. Score on inputs and outputs instead.
Weight the tester credentials row heavily. White box testing is the format where individual skill matters most, because the tester has to read your code faster than your developers wrote it. Ask for the CVs of the people who will actually do the work, not the firm's aggregate certification count.
Two questions separate serious providers quickly. Ask what they will do when they find nothing in a component, because a report that quietly omits negative results is unusable for assurance. Then ask to see a redacted sample report before signing.
Ask also how they handle a finding that turns out to be a false positive. Every engagement produces a few. The good answer is that they verify before reporting and withdraw anything that does not hold up. The bad answer is that everything scanner flagged goes in the report and you can triage it yourself, which transfers the expensive part of the work back to your team.
One more thing worth confirming in procurement: who owns the findings data after the engagement. Some providers retain reports indefinitely on their own infrastructure. If your application handles regulated data, a report describing exactly how to compromise it is itself sensitive, and its retention should be governed by the contract rather than by the provider's habits.
What it costs, and what drives the number
Cost is driven by application complexity and code volume, not by company size. A 40,000 line application with three user roles and one payment integration costs less to test properly than a 15,000 line application with a bespoke authorisation model and four tenancy layers.
Retesting is the line item most often omitted from a proposal and most often needed. Budget for it explicitly. A finding you fixed but never had verified is a finding you are guessing about.
Beware fixed price quotes issued before any scoping call. A provider who can price your engagement without seeing your architecture is pricing a template, and the scope will be adjusted downward later to fit the number.
Red flags in a proposal
The automated scan problem deserves expanding. Every competent provider runs automated tooling as a first pass, and that is fine. The question is what happens next. If the report's findings map one to one onto scanner output, with the same titles and the same generic remediation text, you have bought a scan with a consultancy markup. Real manual work shows up as findings that no scanner produces: broken authorisation between tenants, business logic that allows a negative quantity, a race condition in a checkout flow.
Getting the scope right
Scope defines what you learn, so write it before you request quotes rather than letting each provider define their own.
State which environments are in scope and confirm the test environment matches production in configuration, not just in code. A test against a staging environment with debug mode on and different authentication settings produces findings that do not apply to production and misses ones that do.
List the user roles explicitly and provide credentials for each. Authorisation flaws only appear when a tester can hold two accounts at once and try to cross the boundary between them.
Define the rules of engagement in writing: testing windows, whether denial of service testing is permitted, what happens if the tester achieves remote code execution, and who they call at 2am if something breaks. Agree the escalation path before the test, not during it.
Finally, agree what "done" means. Full WSTG coverage of the in scope application is a defensible definition. A number of days is not, because it says nothing about what was covered.
Put exclusions in writing as clearly as inclusions. If a third party payment provider's infrastructure is out of scope because you have no authority to test it, say so in the document. Unstated exclusions surface as arguments during delivery, usually about whether something was ever going to be tested.
Reading the report you get back
A useful report separates three things that are often merged: the finding, the evidence, and the business impact. Findings without reproduction steps cannot be fixed. Evidence without impact cannot be prioritised.
Check that severity ratings are justified rather than asserted. CVSS scores are common but they measure technical severity in the abstract, not risk to your business. A medium severity finding in your payment flow may matter more than a high severity one in an internal admin tool behind a VPN.
Expect an executive summary that a non technical director can act on, and a technical section a developer can work from. One document serving both audiences badly is the commonest reporting failure.
Check how findings are tracked after delivery. A PDF emailed once is the weakest option. A ticket per finding in your own tracker, with the evidence attached, is what actually gets flaws fixed. Ask during procurement rather than discovering the answer on delivery day.
Preparing your team before the test starts
The engagements that produce the most value are the ones where preparation happened. Three things are worth doing in the fortnight before a white box test.
Get your documentation into a state a stranger can read. That does not mean writing new documentation. It means confirming the architecture diagram matches what is deployed, and noting where it does not. A tester who discovers on day three that the diagram is two releases stale has lost two days.
Decide who owns the findings before they arrive. Security reports frequently land on a team with no capacity to act on them, and sit unaddressed until the next annual test finds the same issues. Name the person who will triage, and give them time in the sprint after delivery.
Brief your own developers that the test is happening. This sounds obvious and is routinely skipped. Developers who do not know about a test either panic at the alerts or, worse, quietly patch things mid engagement, which invalidates the findings.
What a white box test will not tell you
Set expectations honestly, because a report answering a question you did not ask feels like a failure even when the work was good.
It will not tell you whether your organisation would detect an attack. Detection and response capability is measured by a red team exercise or a purple team engagement, which are different products with different costs. A white box test tells you what flaws exist, not whether your monitoring would catch somebody exploiting them.
It will not give you a durable security posture. A penetration test is a point in time assessment against one version of your application. Ship a significant feature and the result is partly stale. This is the argument for continuous security testing in the pipeline alongside periodic deep engagements, rather than instead of them.
It will not cover your dependencies in depth. Most testers will flag known vulnerable packages, but auditing the internals of a third party library is a separate specialism and a separate budget.
It will not replace secure development practice. A test at the end of a release cycle finds what was built wrong; it does not stop the next thing being built wrong. Teams that treat the annual test as their security programme tend to see the same finding categories recur year after year, because nothing upstream changed.
Making the decision
If you are choosing between formats for a first engagement, work backwards from the question you need answered rather than from the budget.
Need to know what an outsider can reach: black box. Need to know whether your user roles hold: grey box, and this is the right default for most teams. Need assurance about one high value component, a payments flow, a tenancy boundary, an authorisation model: white box, scoped tightly to that component rather than spread thinly across the whole application.
The commonest expensive mistake is buying a white box test across an entire large application with a budget sized for a small one. The tester spreads the days thinly, reads nothing deeply, and you get black box coverage at white box prices. A narrow white box test on the component that carries your risk is worth more than a broad one on everything.
Related reading
For the broader testing context around a security engagement, see our guides on penetration testing of web applications and software security testing.
If you are weighing white box against other approaches across your whole programme, our VAPT testing team can help you scope an engagement that matches the risk you are actually carrying.