Dit artikel is momenteel in het Engels beschikbaar. Als je het liever samen in het Nederlands bespreekt, nemen we dat graag mee in een gesprek.

"How much does a pentest cost?" sounds like a pricing question. In practice it is usually an assumptions question. A provider can name a number quickly, but that number only becomes useful once you know what has quietly been included, excluded, simplified, or pushed into "best effort".

This is where many buyers get trapped. Two proposals can both say "web application penetration test" and still describe very different work. One may include authenticated testing across several roles, API review, business-logic testing, a debrief, and a retest. The other may cover a short unauthenticated pass and a vulnerability list. The title is the same. The engagement is not.

So the better question is not "what is the normal price in Belgium?" It is: what work would actually answer the risk question you have?

Scope is not just asset count

Asset count matters, but it is a blunt instrument. A single brochure website and a single customer portal are both "one web app" on a quote request. They do not ask the same thing of a tester. The portal may have roles, workflows, file uploads, payment logic, integrations, audit logs, API endpoints, admin functions, and production constraints. The brochure site may have almost none of that.

The same is true for infrastructure and cloud. Ten externally exposed hosts can be straightforward if they are well understood and isolated. A smaller environment can take more effort if identity, VPN access, legacy systems, and third-party dependencies all sit behind it. What changes price is not only how many things exist, but how much judgement is needed to test them safely and usefully.

Access changes the shape of the work

Authenticated testing usually gives better answers than unauthenticated testing, but it takes preparation. The tester needs accounts, roles, test data, reset procedures, and clarity on what each role is allowed to do. If the assessment includes administrators, support users, finance users, API clients, or tenant boundaries, the test becomes more than a scan with credentials.

That preparation is not overhead for its own sake. It is what lets the tester look for the failures that matter: privilege escalation, broken object-level authorisation, workflow abuse, cross-tenant access, unsafe export features, weak approval paths, or access that remains after a role should have lost it.

Depth is a buying decision

Not every pentest needs the same depth. Sometimes the right answer is a focused validation before a release. Sometimes it is a deeper assessment of a critical application that handles sensitive business data. Sometimes the real concern is not the application itself but the path from that application into identity, cloud storage, or internal systems.

A good provider should help you choose the depth deliberately. If everything is priced as the same generic package, someone is probably avoiding the harder conversation. The cheapest version may still be fine for a narrow question. It becomes a problem when the buyer expects a serious attacker-minded review and the provider has only budgeted enough time for shallow coverage.

What usually moves the quote

I would be careful with public price ranges here. They age badly, they hide assumptions, and they make buyers compare the wrong thing. A clearer way to think about budget is to look at what pushes effort down or up before anyone names a number.

Scoping factor Usually keeps effort lower Usually pushes effort higher
Target shape One well-defined app, API, or range with a clear owner. Multiple apps, APIs, cloud paths, legacy systems, or unclear ownership.
Access model One or two test roles, stable accounts, and test data ready before start. Many roles, admin paths, tenant boundaries, SSO, approvals, or fragile test data.
Test depth Focused validation of common technical weaknesses and obvious exposure. Business-logic abuse, privilege escalation, chaining, identity impact, or post-exploitation paths.
Environment constraints Test systems are resilient, documented, and available during normal hours. Production windows, supplier coordination, safety stops, or systems that cannot tolerate noise.
Output needed Short technical report and one remediation discussion. Board-ready summary, audit evidence, detailed replay, retest, and prioritisation support.

This matrix will not tell you the price. It will tell you whether two quotes are even trying to buy the same work. That is the part many budget conversations skip.

Reporting can be a large part of the value

Teams often underestimate reporting until they need to use it. A useful report is not just a list of findings with CVSS scores. It explains what was tested, what was not tested, how far the tester got, which paths matter most, what evidence supports the conclusion, and what should happen next. Engineering teams need enough detail to fix the issue. Leadership needs enough context to understand whether the risk is isolated or structural.

In Belgium and across Europe, that evidence burden can be very real. A report may need to support ISO 27001 work, NIS2 discussions, DORA preparation, customer assurance, procurement review, board reporting, or vendor risk management. That does not always change the exploit work, but it can change the care required around scoping, documentation, debriefing, and retesting.

Cheap can be fine. Ambiguous is the danger.

A low-cost pentest is not automatically bad. A tight assessment of a small, well-defined target can be efficient and valuable. The trouble starts when the proposal is cheap because the hard parts have vanished without anyone saying so. Manual depth becomes "automated plus validation". Retesting becomes extra. Business logic is excluded. Reporting becomes a template. The senior person joins the sales call but not the work.

None of those trade-offs are inherently immoral. They just need to be visible. If the buyer understands the limits, a small engagement can be the right move. If the limits are hidden, the final report creates disappointment on both sides.

What to send before asking for a quote

You do not need a perfect architecture pack to get a useful first quote. A short scoping note is enough if it answers the practical questions:

  • What systems, applications, IP ranges, cloud accounts, or user journeys are in scope?
  • Is testing authenticated, unauthenticated, or both?
  • Which roles should be tested, and are test accounts available?
  • Are there production constraints, maintenance windows, fragile systems, or third parties involved?
  • What do you need the output for: engineering remediation, customer assurance, audit evidence, board reporting, or a go/no-go decision?
  • Do you expect a retest, a debrief, or help prioritising fixes?

Those answers protect your budget. They also protect the work. When the scope is specific, the provider has less reason to pad uncertainty into the quote and less room to under-scope the parts that matter.

The question behind the budget

The most useful pentest conversations start with a business sentence, not a shopping list. "We are launching this customer portal." "We need to know if this exposed estate can become internal access." "We are worried our admin model gives too much away." "A customer is asking for evidence before renewal." Those sentences tell the tester what the work is really meant to decide.

Once that is clear, cost becomes easier to discuss honestly. You can still compare providers. You can still challenge assumptions. But you are no longer comparing labels. You are comparing whether each proposal can answer the question you actually have.

If you want a quote that reflects the environment you actually have, send us the real scope. Even a rough first pass is enough to turn pricing from guesswork into something useful.