A head of engineering receives three quotes for a penetration test of the same application: the first speaks of five working days, the second of twelve, the third gives no price at all and proposes a scoping workshop instead. The board asks for a recommendation and for the reason behind such a spread. “Because these are different firms” will not do — the spread almost never comes from margin.
It comes from the fact that each of the three bidders priced different work. The request said “please quote a penetration test of our application”, and that sentence contains not one quantity you can multiply by time. Each bidder therefore supplied the missing parameters from their own assumptions and priced those assumptions. This article gives no price ranges, because a range without a stated scope organises nothing. What it does instead is break the quote down into variables you can write into your request — the practical part of cybersecurity that gets the least airtime in a budget conversation.
Why do two quotes for testing the same application differ several times over?
Because a penetration test is not a catalogue product with fixed contents but a budget of specialist time that has to be spread across the surface of an application. How large that surface is follows from scope, not from the name of the service.
The constraint has a stronger source than market practice. In SP 800-115. Technical Guide to Information Security Testing and Assessment (section 2.3) NIST records that a test never covers an organisation’s security posture in full, and that its reach stays narrow because resources — above all the hours available — are finite. An attacker carries no such limit. A buyer is therefore not ordering “a check of the application” but deciding how a finite number of hours gets distributed.
Hence the trap of the cheapest quote. A price half the size usually means not the same work more cheaply but a narrower assumption: fewer roles, no API, no business logic, a retest limited to a single path. Until those parameters appear in the request, none of the quotes is inflated or understated — they are simply not comparable.
In brief: what you compare when you compare prices. Without the number of roles, the presence of APIs, the test mode and the retest scope, you are placing four different services with the same name side by side. The first step towards comparable quotes lies on your side, not with the suppliers.
What exactly are you buying when you pay for a web application penetration test?
You are buying a passage through four phases, only one of which resembles “hacking”. NIST SP 800-115 (section 5.2.1) describes a penetration test as a sequence: planning, discovery, attack and reporting, where reporting runs alongside the other phases and a feedback loop operates between attack and discovery — every successful step opens a new surface to examine.
In the planning phase the rules are set, documented management approval is obtained and the goals of the test are established; according to NIST no testing activity takes place in it. Buyers most often treat this phase as paperwork, and it is the phase that decides how much time is left for everything else.
The largest cost item is manual work. NIST notes that working by hand turns up weaknesses too novel or too obscure for a scanner to flag, at the price of being far slower. The ratio of automated to manual testing therefore says more about price than the number of tools used; we break the difference between the two methods down in the article on penetration testing versus vulnerability scanning.
The final item is the report and its audiences. A technical report, an executive summary, evidence reproducing each finding and a meeting to walk through the results are separate work products — and separate hours.
Which scope parameters actually multiply the effort?
The table below collects the variables that act as multipliers in a web application quote rather than as minor adjustments. The last column matters most: it shows what happens to the quote when an item is missing from the request.
| Scope variable | What it means in a web application | How it changes the effort | Consequence of leaving it out |
|---|---|---|---|
| Roles and privilege levels | How many distinct user contexts exist | Authorisation tests run as role-resource pairs, so a role adds a matrix row | The bidder assumes a single role |
| Authentication paths | Login, SSO, MFA, invitations, password reset | Each path carries its own set of bypass attempts | Only the default path gets tested |
| Knowledge mode: black, grey, white box | How much knowledge the team receives | Shifts the class of defects found and the share of reconnaissance | The narrowest variant is assumed |
| APIs and integrations | Endpoints outside the user interface | A separate surface with its own permission model | The API drops out of scope unmentioned |
| Business logic | Flows with financial or legal consequences | Requires manual modelling of abuse cases | Only technical vulnerabilities remain |
| Methodology or regulation | A required standard and form of evidence | Documentation overhead, a closed list of scenarios | The methodology becomes a claim without content |
| Retest scope | Whether and how fixes are verified | A second iteration: equal to the original or narrower | ”Retest included” means something different in every quote |
| Environment and time windows | Production or a copy, permitted hours and techniques | Constraints stretch the calendar and cut coverage | The schedule diverges after the contract is signed |
Are black, grey and white box a lever on price or a lever on detection?
They are a lever on detection, and the buyer’s intuition here tends to run against the facts. Appendix C to NIST SP 800-115 divides application security assessment techniques into white box, which works directly on the application’s source, and black box, which is run against the compiled executable with no sight of the code; the combination of the two NIST calls grey box testing.
The most interesting sentence in that appendix contradicts the common “less knowledge, therefore more expensive”. NIST states that in custom-built applications white box techniques usually locate defects at lower effort and lower cost per finding than black box ones — but that they will not surface faults sitting on the seams between components, nor problems introduced while the application is compiled, linked or configured at install time. In a footnote the document adds something that matters specifically for web applications: many of them ship without a compiled executable at all, which leaves black box code analysis with nothing to work on.
The conclusion for a request for proposal is straightforward: describe the test mode through what you hand over to the team — repository access, architecture documentation, accounts for each role, a description of business flows — rather than through the label alone. What gets priced is what stands behind it.
How does the number of roles and authentication paths translate into working time?
Directly and non-linearly. An authorisation test checks whether a resource available to one role stays unavailable to the others, so every new role has to be tried against the whole list of protected resources. A second role does not add a test case; it adds another row to the matrix.
NIST describes an analogous mechanism on the internal testing side (section 2.4.1): the team is normally granted the privileges of a general user together with the information such a user would hold, and then checks whether it can raise them. How far that access reaches follows from what the test is meant to establish, and it can extend to administrator privileges — the more such starting points, the more passes.
Then come the entry paths. Password login, login through an identity provider, a second factor, user invitation and password reset are five separate mechanisms, each with its own catalogue of bypass attempts. Listing them in the request is the cheapest thing you can do for the comparability of quotes.
Why are APIs and integrations priced as a separate surface?
Because a tester moving through the user interface touches only the subset of endpoints that the interface calls. The rest — endpoints serving a mobile app, batch jobs, an internal panel or a partner — stays invisible until someone points to it. That is not a technical detail; it is a second application at the same address.
Integrations are priced separately too, and for a formal reason. NIST SP 800-115 (section 6.5) points out that where an organisation does not control part of its estate — say, systems hosted inside another company’s network — that network’s owner normally has to sign off on the assessment plan too. Securing that consent can take longer than the test itself.
This item can, however, genuinely be made cheaper. A current interface specification shortens the discovery phase, because the team does not have to guess at the existence and shape of endpoints. Complete documentation is the only way we know of for a buyer to lower the price of a test without lowering its value.
What does an imposed methodology or regulatory requirement do to the quote?
It turns scope from discretionary into closed — and that is its main effect on price. As long as a quote says “we test in line with good practice”, the list of scenarios stays on the supplier’s side. Once the request names a specific methodology and version, the list becomes countable on both sides.
The OWASP Web Security Testing Guide illustrates this well. The project page (owasp.org/wstg, accessed 10 September 2026) explains that every scenario carries an identifier in the form WSTG-category-number, for example WSTG-INFO-02, and recommends the form that includes the version — WSTG-v42-INFO-02 — because identifiers may change between releases. OWASP also states that version 4.2 is an available release while 5.0 remains in development. A scope written in versioned identifiers is therefore comparable across quotes; a scope written as “in line with OWASP” is not.
The second example is control frameworks. CIS Controls v8.1 (cisecurity.org, accessed 10 September 2026) define Control 18 “Penetration Testing” as testing how well defences hold up: by finding and exploiting weaknesses in controls that span people, processes and technology, and by reproducing an attacker’s goals and moves. Application software security is the subject of a separate Control 16, “Application Software Security”. If your request says only “pentest”, one bidder will price the application and another will add social engineering.
In the payments sector there is a further condition of who may perform the assessment: the PCI Security Standards Council runs separate qualification programmes for different roles, among them Approved Scanning Vendors and Qualified Security Assessors (pcisecuritystandards.org, accessed 10 September 2026). Requiring a supplier with a specific qualification narrows the pool of vendors, and that too is a pricing variable.
Why is “retest included” often an entirely different product?
Because the same phrase covers two different services, and scope rather than the claim decides which one you get. NIST SP 800-115 (section 8.3) puts it without hedging: only a like-for-like repetition of the initial test lets the team confirm that a remediation was implemented correctly.
A full-scope retest is a repetition of the original path — with the difference that discovery is already done, so the second iteration tends to be shorter. A retest limited to re-checking patched addresses confirms that the patch works and nothing more: it will not tell you whether the fix broke something adjacent, or whether changes in the meantime opened a new path.
Three questions settle which product a quote describes: what the retest covers relative to the original scope, within what time window it can be used, and how many iterations the price includes.
In brief: a report with no critical findings is not proof of remediation. The proof is a repeated test of the same scope. If the retest result is to carry weight with an auditor or a customer, write into the request that it must repeat the original scope one to one.
How do the environment and time windows shift the schedule and the cost?
Operational constraints act on price through the calendar, not through the rate card. NIST SP 800-115 (section 5.2.2) points out that an organisation’s own policy may bar the team from specific tools or techniques altogether, or confine their work to defined hours or days of the week. A test spread across evenings and weekends runs longer in calendar terms for the same number of hours.
The second axis is intrusiveness. NIST (section 2.3) reminds readers that every time a tester interacts directly with the environment there is a risk of an unexpected halt in service. An organisation should determine its acceptable level of intrusiveness, and excluding techniques known to cause outages limits the negative impact — while limiting coverage at the same time. That is a deliberate trade to be written down, not discovered in flight.
The choice between production and a copy of the environment has a similar character. A copy removes the risk of downtime but costs you where it diverges from production — different data and configuration produce findings that cannot be reproduced in production, and verifying them is extra work on both sides.
When is a question about price really a question about return?
When the decision is not “which supplier” but “whether this year at all”. That is a different calculation: it sets the cost of the test against the cost of an incident, of downtime and of your own team’s time. We work through it separately, in the analysis of penetration testing costs and benefits, together with the hidden costs that are easy to forget when budgeting.
This article answers a narrower and later question: you have the decision, you have the quotes, and you want to know why they differ several times over. That is why there are deliberately no amounts here — a number without a stated scope does not let you compare quotes, and comparison is the problem we are solving. If you are still establishing what a web application test involves in the first place, start with the description of how it runs and the penetration testing glossary entry. Different questions, different answers — and no contradiction between them.
How do you build a request for proposal that makes quotes comparable?
The simplest approach is to treat the request as an earlier draft of the assessment plan. NIST SP 800-115 (section 6.5) lists the questions an assessment plan has to answer: what the scope is, who is authorised to conduct it, what the logistics are, how sensitive data should be handled and what happens if an incident occurs. Appendix B expands them into a rules-of-engagement template — test boundaries, assumptions and limitations, risks, personnel on both sides, a schedule with working hours, and the location and level of access.
The card below carries those items over into the language of a request for proposal. It is a list the buyer fills in before sending the request out.
| Scope card item | What to state specifically | What a spread across quotes tells you |
|---|---|---|
| Test subject | Application addresses, version, exclusion list | Whether the bidder counts one application or an environment |
| Roles and accounts | Role names, number of test accounts per role | Whether authorisation testing is in scope |
| Authentication paths | Entry and account recovery mechanisms | Who accounted for SSO and a second factor |
| API | Number of endpoints, available specification | Whether the API was priced separately or skipped |
| Business logic | Flows with financial or legal consequences | Whether manual testing beyond the technical list is included |
| Methodology and evidence | Standard with version number, required evidence | Whether “standard compliance” is backed by scenarios |
| Retest | Scope against the original, window, iterations | Whether “retest included” means the same everywhere |
| Environment and windows | Production or a copy, hours, excluded techniques | Where the differences in schedule come from |
| Reporting | Audiences, languages, results walkthrough | Whether a board-level report is included or an extra |
A completed card turns three incomparable quotes into three prices for the same subject — and the differences that remain are differences of craft and rate, which is what you actually wanted to compare. What that scope looks like from the supplier’s side we describe under comprehensive web application penetration testing, together with the current split into packages.
In brief: the one change that buys you the most. If you do only one thing from this list, name the roles and the authentication paths. That item multiplies the work hardest, disappears from requests most often, and accounts for the largest part of the spread across quotes.
Sources
All sources checked with their publishers on 10 September 2026.
- NIST, SP 800-115. Technical Guide to Information Security Testing and Assessment — sections 2.3, 2.4.1, 5.2.1, 5.2.2, 6.5, 8.3 and appendices B and C (csrc.nist.gov/pubs/sp/800/115/final).
- OWASP, Web Security Testing Guide — project page: the scenario identifier scheme and the recommendation to state the version (owasp.org/wstg).
- Center for Internet Security, CIS Critical Security Controls v8.1 — Control 16 and Control 18 (cisecurity.org/controls/cis-controls-list).
- PCI Security Standards Council, Document Library — list of qualification programmes (pcisecuritystandards.org/document_library).
