Penetration Testing Cost in India: A Practical VAPT Pricing Guide
A CTO once forwarded me two quotes for the same web application penetration test. One was for 45,000 rupees, delivered in three days. The other was 4.5 lakh, delivered in three weeks. He wanted to know why the honest one was ten times the price of the cheat, and whether he was being fleeced.
He was not being fleeced. He was looking at the difference between a tool report and a penetration test. That gap is the single most misunderstood thing about pentest pricing in India, and it is where most buyers lose money without realising it. Let me walk you through what you are actually paying for, what the cheap number quietly leaves out, and how to scope a test that survives a PCI QSA, an RBI examiner, and a customer security review without paying enterprise rates for a corner shop.
Why a pentest costs what it costs
A penetration test is not a product with a fixed unit price. It is a fixed number of human days from someone who can actually think like an attacker, plus reporting, plus a retest. Everything on the invoice reduces to one question: how many senior tester-days does this scope really need, and who is doing them?
That is why identical-sounding scopes produce wildly different quotes. A vendor selling you an automated scan (a Nessus or Acunetix run wrapped in a PDF) is selling you a few hours of a junior operator's time. A vendor doing manual exploitation, business-logic abuse, chained attacks and authenticated testing is selling you five to fifteen days of a genuinely skilled human. The tools cost the same. The people do not.
Four drivers move the price more than anything else. Understand these and you can read any quote in thirty seconds.
- Scope size — number of applications, APIs, dynamic pages, roles, and live IP addresses in the target list. A five-page brochure site and a fifteen-role banking portal are not the same test even if both are one URL.
- Depth and methodology — black box (no credentials, outside-in) is cheaper and shallower; grey box (you get user logins) is the sensible default; white box (source code and architecture access) is the most thorough and the most expensive.
- Seniority of the tester — a CERT-In empanelled team with OSCP or CREST-certified people costs more per day than a fresher running a scanner, and the difference shows up entirely in the findings you did not know you had.
- Compliance overhead — a test that has to satisfy PCI DSS, RBI, or SEBI needs specific evidence, a retest, and a signed attestation. That paperwork and the mandatory re-verification add real, defensible cost.
What a scan misses that a real test catches
This is the heart of the 45,000 versus 4.5 lakh question. An automated scanner is very good at one thing: pattern-matching known signatures. Missing security headers, an outdated jQuery version, a self-signed certificate, a directory listing left open. Useful, cheap, and roughly ten percent of your real risk surface.
The other ninety percent is logic, and no scanner has ever understood logic. Here is a concrete scene. On a lending platform test last year, every automated tool returned a clean bill. Then a tester changed the account number in an API response from their own to a sequential neighbour — 100234 to 100235 — and pulled a stranger's PAN, loan amount and repayment schedule. That is an Insecure Direct Object Reference, and it was exploitable across the entire customer base. A scanner will never find it because the request is perfectly well-formed; only the identity is wrong. That single finding was worth more than the entire fee.
The classes of flaw that only a human finds are the ones that actually get companies breached and fined.
- Broken access control — horizontal and vertical privilege escalation, IDOR, and one user reading or editing another user's data. This is the most common serious finding in Indian fintech and consistently tops the OWASP list.
- Business-logic abuse — buying at a manipulated price, skipping a payment step, replaying a one-time token, or coupon and refund fraud that the code technically permits.
- Authentication and session weaknesses — password reset that leaks tokens, OTP bypass, JWT signature confusion, session fixation.
- Chained exploits — three low-severity issues that individually read as amber but combine into full account takeover. Scanners score in isolation; attackers do not.
- Server-side request forgery and injection in real workflows — the kind that reaches an internal metadata service or a database behind the app.
| Dimension | Automated scan | Real penetration test |
|---|---|---|
| Typical India price | 15,000 to 60,000 rupees | 1.5 to 8 lakh depending on scope |
| Who runs it | Junior operator, few hours | Senior tester, 5 to 15 days |
| Finds IDOR / logic flaws | No | Yes |
| Chains multiple weaknesses | No | Yes |
| Accepted for PCI / RBI | No | Yes, with retest and attestation |
| False positive rate | High, needs triage | Low, manually verified |
Real INR ranges by scope in 2026
These are honest market ranges for a competent CERT-In empanelled team doing manual work, not scanner-and-PDF pricing. Treat them as planning numbers; a proper scoping call will tighten them. Everything here assumes grey-box testing with credentials, one round of retest included, and a report suitable for compliance.
| Scope | Typical INR range | Effort (tester-days) |
|---|---|---|
| Single web app, moderate complexity | 1,50,000 to 3,00,000 | 5 to 10 |
| Complex web app (fintech, multi-role, payments) | 3,00,000 to 8,00,000 | 10 to 20 |
| Mobile app (Android or iOS, single platform) | 1,25,000 to 3,00,000 | 5 to 10 |
| REST / GraphQL API set | 1,00,000 to 3,50,000 | 4 to 12 |
| External network (per 8 to 16 live IPs) | 75,000 to 2,00,000 | 3 to 8 |
| Internal network / Active Directory | 2,00,000 to 6,00,000 | 8 to 20 |
| Cloud configuration review (AWS / Azure) | 1,50,000 to 4,00,000 | 6 to 15 |
| Full PCI DSS scoped VAPT (CDE) | 4,00,000 to 12,00,000+ | 15 to 40 |
A few honest caveats on those numbers. A brochure website with no login genuinely can be tested well for under a lakh — do not overpay for a static site. But the moment there is authentication, money movement, or personal data, you are in real-test territory and the low quotes are almost always scanner reports. And VAPT stands for Vulnerability Assessment and Penetration Testing — many cheap vendors deliver only the first half and bill it as both.
What the compliance actually demands
Buyers routinely ask for a pentest without knowing what their regulator requires, then discover after the fact that the report is not accepted. Scope to the standard, not to a vibe. Here is what each framework genuinely asks for in India.
| Framework | Pentest requirement | Frequency |
|---|---|---|
| PCI DSS v4.0 | Requirements 11.4.1 to 11.4.5 — internal and external pentest plus segmentation testing of the cardholder data environment | Annually and after significant change |
| RBI Cyber Security Framework | VAPT of critical and internet-facing systems; findings tracked to closure | At least annually; critical apps more often |
| SEBI CSCRF | VAPT for market infrastructure and regulated intermediaries per prescribed cadence | Annually, with quarterly scans |
| CERT-In directions | Security audit by an empanelled auditor for reporting and post-incident | On incident and as directed |
| DPDP Act readiness | Reasonable security safeguards — VAPT is the accepted evidence of due diligence | Ongoing, risk-based |
Three details separate a compliant test from a decorative one. First, PCI DSS 11.4 explicitly demands segmentation testing — proving the cardholder data environment is genuinely isolated from the rest of your network. A generic app pentest does not cover this, and a QSA will fail you on it. Second, PCI DSS 6.2.4 and 11.4.5 require the tester's methodology to be documented and independent — your own developers cannot test their own code and call it done. Third, almost every framework requires a retest that verifies the fixes actually worked. If the quote has no retest line, it is not a compliance-grade quote.
How cheap tests come back to bite you
The false economy is not hypothetical. Here is how it plays out, in order, more often than any of us would like.
You buy the 50,000 rupee test to satisfy a customer's security questionnaire. The report looks fine — a handful of missing-header findings, all closed in a day. Six months later a real attacker walks in through an IDOR the scanner never saw, and now you are writing a breach notification. Or, more commonly, the customer's own security team reads your report, recognises it instantly as a scanner dump, and rejects it. Now you are paying twice: once for the cheap test, and again for the real one, under deadline pressure, at a premium.
The tell-tale signs of a report that will get rejected are consistent and easy to spot.
- Every finding maps one-to-one to a scanner plugin ID with no manual verification or exploitation narrative.
- No business-logic findings at all, on an application that clearly has business logic.
- No authenticated testing — the tester never logged in, so half the app was never seen.
- Severity ratings that do not use CVSS or that ignore your actual data sensitivity.
- No proof-of-concept steps a developer can reproduce, and no retest to confirm fixes.
- A one-page executive summary and thirty pages of raw tool output with nothing in between.
How to scope a pentest without overpaying
The goal is not the cheapest test or the most expensive one. It is the right depth for your actual risk, evidenced well enough to satisfy whoever is going to read the report. Work through this before you request a single quote.
- Define the target precisely — count the applications, roles, API endpoints and live IPs, and write them down. Vague scope is what lets cheap vendors underbid and good vendors pad.
- Decide the depth deliberately — grey box with credentials is the right default for anything with a login; do not pay for white box unless you have source-code obligations or a critical system.
- Name the standard up front — tell the vendor it must satisfy PCI 11.4, or RBI, or a named customer, so the report and retest are built to pass the first time.
- Insist on a manual methodology in writing — ask what percentage of testing is manual and ask to see a sample report before you sign, not after.
- Confirm the tester's credentials — CERT-In empanelment, OSCP or CREST, and named individuals rather than an anonymous pool.
- Make the retest non-negotiable — one round of re-verification after your team fixes the findings must be in scope and in the price.
- Match spend to data sensitivity — an internal HR tool and a payments platform do not warrant the same budget; put the money where a breach would actually hurt.
- Get the report format agreed — CVSS scoring, reproducible proof-of-concept steps, a remediation-priority table, and an attestation letter for auditors.
The bottom line on price
Come back to that CTO with his two quotes. The 45,000 rupee test would have passed his internal checkbox and failed his first serious customer and his first real attacker. The 4.5 lakh test found the IDOR that would have leaked his entire customer base. He paid ten times more and got a hundred times the protection. That is the whole economics of penetration testing in one sentence: you are not buying a report, you are buying the findings a scanner cannot see, and those findings are the only part that ever mattered.
If you want a scoping call that tells you honestly whether you need a five-day test or a twenty-day one — and a quote with the manual methodology, credentials and retest written into it — CyberSigma's CERT-In empanelled team does this work hands-on, in the audit room, every week. We would rather right-size your test than sell you a bigger one.
FAQs
How much does a basic website penetration test cost in India?
For a genuine manual test of a moderate web application with a login, expect 1,50,000 to 3,00,000 rupees for five to ten senior tester-days, including one retest. A simple brochure site with no authentication can legitimately cost under a lakh. Anything quoted below 60,000 for an application with logins is almost certainly an automated scan, not a penetration test.
What is the difference between VAPT and a penetration test?
VAPT stands for Vulnerability Assessment and Penetration Testing. The vulnerability assessment is the automated, breadth-first scan that catches known signatures. The penetration test is the manual, depth-first work where a human exploits and chains findings and abuses business logic. Many cheap vendors deliver only the assessment half and bill it as full VAPT — always confirm what percentage of the work is manual.
How often does PCI DSS require a penetration test?
PCI DSS v4.0 Requirements 11.4.1 to 11.4.5 require internal and external penetration testing at least annually and after any significant infrastructure or application change. It also mandates separate segmentation testing to prove the cardholder data environment is isolated, plus verification that findings are remediated. A test without segmentation coverage or a retest will not satisfy a QSA.
Can I use an automated scanner report for compliance?
Generally no. PCI DSS, RBI and SEBI all expect a documented penetration testing methodology performed by qualified, independent testers, not a raw scanner output. A vulnerability scan is a required complement but is not a substitute for the penetration test. Auditors and enterprise security teams recognise scanner dumps immediately and reject them.
Why do penetration test quotes vary so much for the same scope?
Because the invoice is really pricing human days and human skill, and those vary enormously. A low quote usually buys a few hours of a junior operator running a tool. A higher quote buys five to fifteen days of a CERT-In empanelled, OSCP or CREST-certified tester doing manual exploitation. The tools are identical; the findings are not. Always compare methodology and tester credentials, not just the number.
What should a good penetration test report contain?
An executive summary in business terms, each finding with a CVSS score tied to your actual data sensitivity, reproducible proof-of-concept steps a developer can follow, a prioritised remediation plan, evidence of manual and authenticated testing, and a retest section confirming fixes. If it is for compliance, it should also carry an attestation letter naming the empanelled auditor.
Liked the post? Share on:
Leave A Comment