By Akash Sengar · · 7 min read
Why quotes vary so much
Two quotes for "a pen test of our web app" can differ widely, and both can be fair. They may describe different amounts of work, different skill levels and very different reports. This guide explains what drives the effort so you can compare quotes properly. It quotes no prices: no public source gives reliable ranges that would fit your scope.
Penetration testing is priced mainly by tester-days. Everything below changes how many days a competent tester needs.
What is being tested
- Web application: effort grows with the number of user roles, features and workflows, and how much business logic there is to abuse (payments, approvals, multi-tenant data).
- API: effort depends on the number of endpoints and methods, authentication schemes and whether documentation (OpenAPI or a Postman collection) is available.
- External network: number of public IP addresses and exposed services.
- Internal network: number of subnets, hosts and whether Active Directory or Entra ID attack paths are in scope.
- Cloud configuration: number of AWS accounts, Azure subscriptions or Google Cloud projects and services in use.
- Mobile app: one or both platforms (Android, iOS), plus the API behind it.
A quote should list each of these with counts. If it does not, the provider has not scoped the work.
Black, grey and white box
In black box testing, the tester gets no information and no credentials, as an outside attacker would. It sounds realistic but spends much of the budget on discovery. Grey box gives the tester accounts for each role and some documentation, so time goes on finding vulnerabilities. White box adds source code or architecture access. For most business applications, grey box gives the best coverage per day.
Authenticated testing and roles
Most serious web and API flaws (broken access control, insecure direct object references, privilege escalation) can only be found when logged in. Testing each role, and testing whether one tenant can reach another tenant's data, multiplies effort. A quote that excludes authenticated testing is cheaper because it tests much less.
Tester skill and method
Automated scanners are fast and cheap; skilled manual testing is neither. Scanners find known issues and misconfigurations but miss business-logic and access-control flaws, and they report false positives. Ask who will do the testing, their experience and certifications, and how much of the time is manual. Ask whether they follow a recognised method such as the OWASP Web Security Testing Guide or NIST SP 800-115.
Coverage: OWASP Top 10:2025 and ASVS 5.0
The OWASP Top 10:2025 is an awareness list of the most critical web application risk categories; a web test should at least cover every category. For a more complete, testable checklist, the OWASP Application Security Verification Standard (ASVS) 5.0 defines requirements at three levels. Ask the provider which ASVS level, if any, their test maps to, and which requirements are out of scope.
Report quality and remediation support
The report is what you pay for. A good one has an executive summary, scope and method, and for each finding: severity with reasoning (often CVSS), evidence, affected asset, impact and a specific fix. Ask for a sample report before you buy. Our guide to what a good VAPT report contains has a checklist.
Remediation support (a walkthrough call, answering developer questions, reviewing fixes) adds value and effort. Whether fixes are re-tested, how and when, is a separate scope item: agree it explicitly in writing rather than assuming it is included.
What a scoping call should cover
A provider who sends a quote without asking questions is guessing. A good scoping conversation covers, at minimum:
- The business purpose: a customer request, a regulator, a release, or a general check. This shapes depth and reporting.
- Exact assets: URLs, API base paths, IP ranges, cloud accounts, app store builds.
- User roles and test accounts, and whether multi-tenant separation must be tested.
- Environment: production or staging, and any fragile systems or times to avoid.
- Third parties whose permission is needed, such as hosting providers or SaaS platforms.
- Constraints: no denial-of-service testing, data that must not be touched, notification contacts.
- Reporting needs: an executive summary for customers, technical detail for developers, or a specific format.
The written scope that comes out of this call is also what makes quotes from different providers comparable.
How often to test
Many organisations test at least once a year and after significant changes such as a new application, a major release or an infrastructure move. Customers, regulators or standards may set their own frequency; PCI DSS, for example, includes specific penetration testing requirements. Budget for the frequency your obligations require rather than a one-off test.
How to compare quotes
- Same scope. Give every provider the same written scope: assets, counts, roles, environments and testing window.
- Days and people. Ask for the tester-days and who the testers are. Compare effort, not only totals.
- Method. Named methodology, manual versus automated share, and coverage of OWASP Top 10:2025 or an ASVS level.
- Sample report. Judge clarity, evidence and how specific the fixes are.
- Authorisation. A written authorisation letter signed by someone entitled to approve testing of each asset, including third-party hosting or SaaS where their terms require notice.
- Rules of engagement. Testing hours, production versus staging, data handling, emergency contacts and what happens if a critical issue is found mid-test.
- Who does the work. In-house testers or subcontracted, and where your data will be stored.
- Regulatory need. Some regulators require testing by CERT-In-empanelled auditors (see RBI and SEBI cyber rules). Check before you buy.
VAPT cost in India and elsewhere
The drivers above apply everywhere. Day rates differ between countries and between firms, and searches for "VAPT cost in India" return many unsourced numbers. Rather than compare headline prices, compare the effort, skill and report you get for them using the checklist above.
Getting more from the budget
- Fix known issues before the test, so the tester finds new ones.
- Provide test accounts for every role and API documentation on day one.
- Use a stable staging environment that mirrors production.
- Test after significant changes, not only on a calendar date.
- Track fixes in a remediation tracker so progress is visible.
Our VAPT service page explains how we scope and run tests.
