VAPT Services in India: How to Choose the Right Provider

Most VAPT reports we get asked to peer-review in India are automated scanner exports with a logo on the cover. The provider ran a licensed vulnerability scanner against a handful of URLs, exported the PDF, colour-coded the risk ratings, and invoiced you for a penetration test. You paid for a red team and got a Nessus dump.

That distinction is not academic. It is the difference between an auditor who signs your CERT-In or PCI attestation with confidence and one who quietly rejects the report because there is no evidence a human ever touched your application. This guide is written from the other side of the table. It tells you what VAPT actually covers, what a defensible report looks like, what it should cost in rupees, and how to separate a genuine CERT-In empanelled provider from a reseller with a template.

VAPT stands for Vulnerability Assessment and Penetration Testing. They are two different activities that lazy providers blend into one line item so you cannot tell what you are buying.

Vulnerability Assessment (VA) is breadth. It is largely automated: you point a tool such as Nessus, Qualys or Burp Suite at an asset, it fingerprints services, matches versions against known CVEs, and produces a ranked list of findings. It answers the question, what is potentially wrong here. It does not confirm exploitability. A VA will flag an outdated OpenSSL build; it will not tell you whether that build is actually reachable and weaponisable in your environment.

Penetration Testing (PT) is depth. It is manual, adversarial, and creative. A tester chains findings, abuses business logic, escalates privileges, and proves impact — this is how an attacker moves from a low-severity information leak to a full account takeover. The scanner cannot find a broken authorisation check that lets user A read user B's invoices by incrementing an ID in the URL. A human does, in about ninety seconds, and then documents the exact request that did it.

The cheat is simple. A provider sells you PT pricing, runs only VA, and pads the report with scanner output. The tell is in the evidence. Real penetration testing produces reproduction steps: the raw HTTP request, the parameter tampered, the response that proves the exploit, a screenshot of the data that should not have been visible. If your report has severity ratings but no request-and-response pairs, no human tested your application.

Providers price by asset type, and the effort varies enormously. Know which of these you actually need before you accept a quote, because paying for a network test when your risk lives in a web application is a common and expensive mistake.

You will hand this report to a regulator, a QSA, an enterprise customer's security team, or a CERT-In auditor. It has to stand up to a hostile read. Here is what we look for when we assess whether a report is genuine work or shelfware.

Not a paragraph of boilerplate. It states the scope tested, the dates, the methodology followed, the count of findings by severity, and one honest sentence on the overall security posture. If the summary could be pasted onto any company's report unchanged, it is filler.

Each finding must carry a clear title, an affected endpoint or asset, a severity backed by a CVSS v3.1 vector string (not just the word High), a plain-English description of the impact, step-by-step reproduction, and a specific remediation. The CVSS vector matters because it shows how the score was reached — an auditor who disagrees with your rating needs to see the reasoning, not trust a colour.

This is the single most reliable signal of real work. For every meaningful finding there should be a request-and-response pair or an annotated screenshot showing the actual exploit. A SQL injection finding without the injected payload and the extracted data is an assertion, not a result.

A serious engagement includes one round of retesting after you fix the findings, and a revised report or attestation letter confirming what was closed and what remains. CERT-In empanelled reports for regulatory submission carry the empanelment reference and are signed. If retesting is not in the quote, the finding lifecycle is your problem, and your regulator will notice the open items.

Pricing varies with scope, application complexity, number of roles and the seniority of the tester. The ranges below reflect the Indian market as of 2026 for competent, manual-heavy work. Treat anything dramatically below the floor as a scanner dump in disguise, and anything at the ceiling as either a large scope or a premium brand.

Two things move price more than anything else. The first is roles: an application with an anonymous user, a customer, a merchant and an admin is effectively four applications from an authorisation standpoint, and each pairing has to be tested for horizontal and vertical privilege escalation. The second is retesting: a fixed price with unlimited retests is rare and usually means the retest is superficial. One included retest round is the sensible norm.

Beware the day-rate quote with no defined scope. It transfers all risk to you. A good provider scopes the effort in person-days after seeing the application, then holds that number. If they cannot tell you how many days your app will take, they have not looked at it.

CERT-In is the Indian Computer Emergency Response Team, the national nodal agency for cybersecurity under the Ministry of Electronics and Information Technology. CERT-In empanels a limited list of information security auditing organisations, and for a growing set of obligations the empanelment is a hard requirement, not a marketing badge.

If you are a Regulated Entity under RBI, a stockbroker or depository participant under SEBI, an insurer under IRDAI, or you handle Aadhaar as an AUA/KUA under UIDAI, your security audits are expected to be conducted by a CERT-In empanelled auditor. SEBI's Cyber Security and Cyber Resilience Framework, RBI's cybersecurity guidelines for banks and NBFCs, and UIDAI's audit requirements all lean on this empanelment. A report from a non-empanelled firm may simply not be accepted at submission, and you will pay twice to redo it against a deadline.

Verify empanelment directly. Ask for the organisation's name exactly as it appears on the CERT-In empanelled list, and confirm it against the official list on the CERT-In website rather than a logo on a slide. Empanelment is granted to the organisation, not to a freelancer they subcontract to, so confirm the actual testers are on that firm's rolls.

A fintech we were later brought in to help had commissioned a web application VAPT before a payment-aggregator authorisation. The report came back clean — two informational findings, a tidy green summary. They submitted it. The reviewing team asked one question: was the settlement API tested.

It had not been. The scope named the web dashboard by URL, and the mobile app talked to a separate API host that never appeared in the statement of work. The provider had tested exactly what was written and nothing more, which is technically correct and commercially useless. When a competent tester finally looked at that API, it had broken object-level authorisation: change the merchant ID in the request body and you could read another merchant's transaction history. That is the finding that should have blocked the launch, and it lived entirely outside the scope the client had signed.

The lesson is blunt. The scanner finds what you point it at. The scope is the whole engagement. Draw your data flows first, list every host and API that touches sensitive data, and make the provider justify anything they want to exclude.

Run any shortlisted provider through this before you sign. If they resist the sample report or the tester credentials, that is your answer.

A capable auditor cannot save an engagement you have set up to fail. Three self-inflicted mistakes account for most of the disappointment we see.

A VAPT is only as good as the human behind it and the scope in front of them. A scanner export with a cover page will pass a casual glance and fail the one reader who matters — the auditor, the regulator or the attacker. Pay for the depth, define the scope like your authorisation depends on it, because it does, and demand evidence that a person actually broke into your application before they wrote it up.

If you would rather have senior CERT-In empanelled auditors do this hands-on — scoping your real attack surface, testing it manually, and standing behind the report when your regulator asks the hard question — the team at CyberSigma does exactly that work, and only that work.