Web App Pentest Cost Estimator — Scope, Days, and Range in 60 Seconds

Most pentest engagements go wrong at the scoping stage. The number on the SOW is the easy part — the dangerous part is what you didn't put in the SOW. A vendor can quote half the market price and deliver a glorified Nessus scan that fails to find a single business logic flaw. Or they can quote double the price and deliver a 60-page wall of CVSS scores with no actionable remediation guidance. This estimator gives you the math you need to evaluate both ends of the bell curve.

The day rate baked in here is $1,800/day. That's anchored on the publicly available pricing of mid-market US firms holding the right credentials — OSCP, GWAPT, GPEN, GXPN, CREST — for senior testers (not junior testers fronted by senior names on the SOW). Boutique specialty shops can run $2,200-$2,800/day. Offshore vendors run $600-$1,200/day but often deliver scan-only output you could have run yourself with a free Burp license. Use the $1,800 anchor as your sanity check: if a quote is 40% under that, ask hard questions about manual vs automated testing ratios. If it's 50% above, ask for the actual tester resume and credentials.

The single most important number in your SOW

Manual testing percentage. The OWASP testing guide and the SANS pentest methodology both call out that scanners catch the bottom 20% of findings — the OWASP Top 10 classics, the unpatched libraries, the known CVEs. Business logic flaws, broken auth chains, IDOR (insecure direct object reference), SSRF in the wild, race conditions, and chained vulnerabilities are 100% manual. If your SOW doesn't commit to a manual testing percentage of at least 60%, you're buying a scan. The pentest cost estimator above assumes 60-70% manual on every methodology — adjust the recommendation accordingly if you're comparing scan-only vendors. Our penetration testing service commits to manual testing in writing on every engagement.

Endpoint count: how to ballpark it

For an API, count distinct path+method combinations. A REST API with GET, POST, PUT, DELETE on /users, /products, and /orders is 12 endpoints, not 3. If you have a Swagger or OpenAPI definition, the route count there is your scope. For a web application, count distinct page routes plus any AJAX/fetch endpoints invoked from those pages. CRUD operations on the same resource collapse to one endpoint set. For a typical SaaS web app with 4-6 major resources and customer + admin views, expect 60-120 endpoints. For an API-first product, 100-300 is common. For a mature platform with multiple modules, 300+ is normal — at that point you should be scoping a focused engagement on the highest-risk modules rather than a full-coverage sweep.

User roles: why this number quietly drives cost

Each pair of roles creates a privilege-escalation test path. Two roles = 1 escalation pair (user-to-admin). Three roles = 3 pairs. Five roles = 10 pairs. The cost growth is quadratic, not linear. If you have 6+ distinct roles, expect the day count to climb fast. The right move is to either reduce scope (pick the 2-3 most security-sensitive role pairs) or accept the longer engagement — but go in with eyes open. This is the most common surprise in pentest scoping. Walking through your role hierarchy on a scoping call usually surfaces redundant roles that consolidate without changing the security posture.

Compliance scope: what each framework actually requires

SOC 2 requires a customer-shareable summary plus control evidence. Most auditors accept the standard OWASP Top 10 + OWASP API Top 10 coverage with a documented methodology. PCI-DSS requires explicit cardholder-data-flow validation plus an ASV (Approved Scanning Vendor) external scan layered on top of the manual pentest. HIPAA requires PHI-handling control mapping aligned to the Security Rule (164.308, 164.310, 164.312). FedRAMP requires control mapping to NIST SP 800-53 + 3PAO submission rigor. The estimator adds days for each framework based on the documentation overhead, not extra exploitation work. If a vendor quotes you the same day count for “no compliance” and “FedRAMP,” they're either underestimating the framework or planning to skip the documentation. Both are bad.

Methodology and the white-box discount

White-box testing (the tester gets source code access plus docs plus credentials) is 10-15% faster because the tester isn't reverse-engineering your authorization model from black-box behavior. The trade-off is that white-box findings sometimes miss the things a real attacker would have found through brute external probing — that's why grey-box is the most common methodology in the field. Pick white-box when you have strict timelines, when source code review is itself a deliverable, or when your compliance framework demands it (FedRAMP often does). Pick grey-box for most engagements. Pick black-box only when you have a specific reason to model an external attacker who knows nothing about your stack — typical for high-value bug-bounty-style engagements or for organizations that have just acquired a new product and want a cold read.

Don't forget the retest

A pentest without a retest is half a pentest. The auditor or customer reviewing your report wants proof that the findings got fixed, not just a list of what's broken. A 30-60 day retest window is the industry standard — your team gets time to remediate, the tester comes back, and the final report shows what's remaining vs resolved. Always include this in the SOW. Vendors that charge for retest as an add-on are either nickel-and-diming you or planning a token reissue. Both are red flags. Our guide to penetration testing costs walks through the SOW language to look for.