Penetration Testing Cost: What Actually Drives the Price of a Pentest

01How much does a penetration test cost?

A penetration test costs as much as the skilled tester time it needs, and no honest vendor can put a figure on that before they understand your scope. Vendors typically estimate the work in tester-days and price that effort, so every question they ask you is really a question about effort. This is why published price ranges are of little use to a buyer. A brochure site and a multi-tenant fintech platform can both be sold as "a web application pentest." One has a login page and a contact form. The other has many user roles, payment flows, admin consoles and a public API. The label is the same. The effort is very different. In India the same service is usually bought as VAPT, short for vulnerability assessment and penetration testing. The term bundles automated assessment with manual testing, and the balance between the two is the biggest hidden variable in any VAPT quote. A quote that is mostly automated will be cheaper and will find less. The practical way to think about cost is to control the inputs. If you define the scope, the test type, the environment and the reporting you need, you control the effort estimate. You also get quotes from different vendors that can be compared on the same basis.

• 01Scope: how many assets, roles, endpoints and hosts must be tested
• 02Test type and depth: black, grey or white box, and how much is manual
• 03Environment: web, API, mobile, network, cloud, on-premises or OT
• 04Obligations: regulatory reporting, retesting, testing windows and on-site work
• 05People: the seniority and experience of the testers assigned

02How does scope change penetration testing cost?

Scope is the largest cost driver because it sets how much there is to test. The right unit is what a tester must exercise by hand, and raw counts of URLs or IP addresses are a poor proxy for that. A web application with few pages can hide complex business logic behind each one. Every user role adds work, because access control has to be tested from each role against the data and functions of every other role. An API is sized by its endpoints, the methods each one accepts and the authentication schemes in use. A network is sized by live hosts and exposed services; a large address range that is mostly empty is quick to sweep. Mobile apps are sized per platform and per build, and the backend API behind the app is often the bigger job. State what is out of scope as clearly as what is in. Third-party SaaS, payment gateways and cloud provider infrastructure generally cannot be tested without the owner's permission, and some hosting agreements require approval before any test starts. A vague boundary produces either padded quotes or gaps in coverage.

• 01Web applications: user roles, key workflows such as signup, payments and approvals, file uploads, integrations
• 02APIs: endpoints and methods, authentication schemes such as OAuth, API keys or mutual TLS, and whether a spec or collection exists
• 03Networks: live external and internal hosts, exposed services, segmentation boundaries to verify, wireless networks
• 04Mobile apps: platforms, builds or flavors, local data storage, and the backend API the app calls
• 05Cloud: accounts or subscriptions, services in use, and whether a configuration review is included
• 06OT and embedded systems: device types, safety constraints, and whether testing must run on a lab replica

03How do black-box, grey-box and white-box testing affect cost?

Test type decides how much paid time goes into discovery and how much goes into testing. In a black-box test the tester starts with no information. In a grey-box test they receive partial information such as credentials, a role matrix and documentation. In a white-box test they receive full detail, often including architecture and source code. Black-box sounds the most realistic, but it spends tester hours rediscovering what your team could have handed over in an email. The PCI Security Standards Council's penetration testing guidance says grey-box and white-box assessments yield more accurate results and a more comprehensive test than pure black-box, and that black-box may require more time, money and resources. White-box adds cost of its own when source code review is in scope, but it reaches flaws that are hard to find from outside. Depth matters as much as type. An automated scan identifies and ranks known vulnerabilities. A penetration test tries to exploit them, chains weaknesses together and tests business logic that no scanner understands. The same PCI guidance describes scanning as automated tools plus manual verification of findings, and penetration testing as a manual process that may use automated tools. That manual work is what you are paying for, and its value depends on who does it. A senior tester costs more per day and is far better placed to find authorization flaws, logic abuse and multi-step attack chains.

• 01Black box: no prior information; closest to an outside attacker's view; paid time goes into discovery and coverage depends on what the tester finds
• 02Grey box: credentials, roles and documentation supplied; time goes into testing; the usual choice for applications, APIs and compliance-driven tests
• 03White box: full design detail and often source code; highest assurance for critical systems; costs more when code review is included
• 04Automated scan: fast and broad, limited to known issues; useful between tests and a different product from a penetration test
• 05Manual exploitation: proves real impact, chains findings and tests business logic; this is where most of the effort and value sits

04How do compliance, retesting and logistics affect pentest pricing?

Compliance adds cost because it adds scope, evidence requirements and rules about who may test. Tell vendors which regulation or audit the report must serve before they quote, because the scope and report format follow from it. For Indian regulated entities the requirements are specific. The RBI Master Direction on IT governance, risk, controls and assurance practices requires VA at least once in every six months and PT at least once in 12 months for critical systems and for DMZ systems with a customer interface, plus VA/PT across the system lifecycle, including after major changes. It requires testing by trained, independent experts and post-implementation testing on the production environment. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) mandates VAPT after every major release, requires revalidation after observations are closed, and states that audits under the framework must be conducted by a CERT-In empanelled IS auditing organization unless otherwise specified. PCI DSS requires segmentation controls to be tested wherever segmentation is used to isolate out-of-scope systems from the cardholder data environment. If the report will support a SOC 2 audit, ask your auditor what they expect to see in it before you finalize scope. Retesting is its own line item. A retest confirms that fixes work and produces the closure evidence regulators look for. Some vendors include a retest window in the price and others charge for it separately, so ask. Logistics account for the rest. Testing only in night or weekend change windows, production-only rules, on-site internal or OT testing, travel, and security clearances for sensitive sites all raise effort without adding test coverage. They are legitimate costs, and they should appear in the quote as named items.

05What are the red flags in a cheap penetration testing quote?

The most common red flag is a vulnerability scan relabeled as a penetration test. The report looks substantial, but it is scanner output with severity ratings and generic remediation text, and nobody tried to exploit anything. Cheap quotes cut the expensive part, which is manual testing time. You can spot the cut before you sign. Ask for a redacted sample report, the methodology the team follows, the names and experience of the testers, and the number of tester-days the quote assumes. A vendor who cannot state the effort cannot defend the price. Certificates are a weak filter on their own. PCI SSC guidance states that appropriate penetration testing experience cannot be met by certifications alone, and suggests asking whether the tester has assessed organizations of similar size and scope. Ask what the proposed tester has tested before that resembles your stack.

• 01A fixed price offered before any scoping questions are asked
• 02No tester-day estimate, or an estimate that cannot cover the roles and endpoints you listed
• 03Sample reports full of scanner plugin names, CVSS scores and generic fixes, with no proof of concept or attack narrative
• 04No authenticated testing, so everything behind the login page goes untested
• 05No rules of engagement, testing windows or emergency contact process
• 06Retesting excluded, or no way to reissue the report after fixes
• 07A tester who also built, runs or supports the system under test, which breaks independence
• 08Where your regulator requires an empanelled auditor, no proof of current empanelment

06What should you send a vendor to get an accurate pentest quote?

Send every vendor the same written scope document. Quotes are only comparable when they price the same work, and a shared scope turns a guessing game into a like-for-like comparison. Ask each vendor to return the quote in the same structure: tester-days per asset, test type, what is manual and what is automated, retest terms and report deliverables. Compare effort and method first and price last. If one quote carries far less effort than the others for the same scope, find out what was left out. A short pre-engagement call is worth the time for both sides. PCI SSC guidance recommends agreeing the types of testing, how testing will be performed and what it will target before work starts, so that a badly defined scope does not force a retest. The checklist below covers what a tester needs to size the work accurately.

• 01Business context: what the system does, what data it holds and what a worst-case compromise would look like
• 02Asset inventory: application URLs and environments, API specifications or collections, live IP ranges, mobile builds, cloud accounts
• 03User roles, with a test account for each role, and the key workflows that must be covered
• 04Preferred test type (black, grey or white box) and whether source code review is in scope
• 05Environment details: production or staging, hosting provider, and any third-party approvals required
• 06Compliance driver: RBI, SEBI CSCRF, PCI DSS, SOC 2 or customer due diligence, and the report format it needs
• 07Constraints: permitted testing windows, fragile or legacy systems, on-site requirements, OT safety rules
• 08Network diagrams and data flow diagrams, where they exist
• 09Retest expectations and the date by which the final report is needed

07How Faltrox can help

For a recurring regulatory requirement or a first security baseline, VAPT and Vulnerability Assessment combines automated vulnerability assessment with human-led penetration testing in one engagement. For specific assets, Faltrox offers Web Application Penetration Testing, API Security Testing, Mobile Application Penetration Testing, Network Penetration Testing and Cloud Penetration Testing. When the question is whether your people, processes and detection would stop a determined attacker, Red Teaming and Adversary Simulation tests them together against an agreed objective. Sharing the checklist above with Faltrox is the quickest way to start scoping any of these engagements.