How to Choose a VAPT Provider in India: 7 Questions to Ask Before You Sign

Here is a truth most vendors will never tell you: a large share of the VAPT reports we see during audits are automated scanner output wearing a suit. Someone pointed a tool at your IP range, exported the findings, changed the logo, and invoiced you two lakh rupees. VAPT stands for Vulnerability Assessment and Penetration Testing, and the difference between those two words is exactly where most Indian buyers get quietly robbed.

You are not buying a PDF. You are buying the judgement of a person who tried to break into your systems the way a real attacker would, and then told you honestly what they found. If your provider cannot demonstrate that judgement in the sales call, no certificate they issue is worth the paper it prints on. This guide is written from the other side of the audit table — what actually separates a real testing firm from a scan-and-ship shop, and the questions that flush the difference out in twenty minutes.

A bad VAPT does not just waste your budget. It gives you a false green light. You show the certificate to your bank, your enterprise customer, your CERT-In filing, or your cyber-insurance underwriter, and everyone downstream assumes someone competent looked at your systems. When a breach happens through a hole the scanner never touched — a broken authentication flow, an IDOR in your API, a business-logic bug in your payment path — that certificate becomes evidence that you were told your system was secure. In an incident post-mortem, and increasingly in DPDP-related regulatory questions, that is a very bad place to stand.

There is also the regulatory reality. Under the CERT-In directions of April 2022, service providers, intermediaries, data centres and body corporates must report cyber incidents within six hours and maintain security practices. RBI, SEBI and IRDAI all now expect periodic VAPT of critical and internet-facing systems, and several of them specifically ask for a CERT-In empanelled auditor. If your report is thin, your regulator will notice on the very first review, and you will pay for the exercise twice.

CERT-In, the Indian Computer Emergency Response Team, maintains a public list of empanelled information security auditing organisations. For a lot of Indian compliance needs — RBI cyber-security framework filings, SEBI CSCRF, IRDAI, government tenders — the auditor must be on that list. So empanelment is your first hard filter. If a provider is not empanelled and your regulator asks for one, the conversation is over regardless of how good they are.

But here is the part the marketing pages omit. Empanelment is issued to the organisation, not to the specific engineer sitting on your engagement. A firm can be genuinely empanelled and still staff your test with a fresher running a licensed scanner. Empanelment tells you the company cleared CERT-In's process at least once. It tells you nothing about who touches your systems next Tuesday. Verify empanelment on the CERT-In site directly using the organisation's exact registered name — never trust a logo on a slide — and then keep asking questions.

A Vulnerability Assessment is breadth. A tool enumerates known weaknesses across your estate and produces a ranked list. It is useful, it is cheap, and it is almost entirely automated. A Penetration Test is depth. A human takes those findings plus everything the scanner cannot see, chains them together, and demonstrates real impact — actual unauthorised access, actual data exfiltration, actual privilege escalation.

The con lives in the ampersand. Selling VAPT lets a vendor charge penetration-test prices for vulnerability-assessment work. You get a Nessus or Acunetix export with a CVSS column, zero exploitation, zero business-logic testing, and a cover page that says penetration test. The tell is the findings themselves: if every issue maps cleanly to a CVE number and a public plugin, and nothing describes a flaw specific to your application's logic, you paid for a scan. Real penetration test findings read like a story — this input reached that function, which trusted this token, which let me become that user.

Scoping is where quality is decided, long before any packet is sent. Watch how the provider behaves here. A weak vendor asks for your IP list and a start date. A serious tester wants to understand what they are protecting and how it can be abused.

Picture the call. You run a lending platform. The competent tester does not ask how many IPs you have. They ask: how many user roles exist, and what can a borrower do that a collections agent cannot? Where does money actually move, and who authorises it? Is there an admin panel reachable from the internet? Do you have an API that mobile apps consume, and is it separately authenticated? What is the one screen that, if breached, ends your business? Then they scope test users at each privilege level, because the interesting bugs live in the gaps between roles — the borrower who can approve his own loan, the agent who can read another customer's KYC. A scanner never finds that. It has no idea your business exists.

If the scoping conversation never leaves the network layer, you are about to buy an infrastructure scan dressed as an application penetration test.

Any credible provider will name a methodology. The honest ones can then walk you through it. For web and API work the reference is the OWASP standards — the OWASP Top 10, the OWASP Application Security Verification Standard (ASVS), and the OWASP Web Security Testing Guide (WSTG). For a broader engagement, the Penetration Testing Execution Standard (PTES) and NIST SP 800-115 describe the phases. Mobile work should reference the OWASP Mobile Application Security Verification Standard (MASVS).

Naming a standard is easy. Ask the follow-up: for the ASVS, which verification level are you testing against — Level 1, 2 or 3? For an API, are you testing the OWASP API Security Top 10 specifically, including broken object-level authorisation and broken function-level authorisation? For each, ask what a real finding under that category looked like on a recent engagement. A firm that tests manually can answer instantly with a war story. A scan shop starts talking about their tool's coverage, because the tool is all they have.

The report is the product, and you can grade a provider by asking for a sample redacted report before you sign. This one document exposes more than any sales deck. Here is what a report worth paying for contains, and what junk reports skip.

One quick test: open the sample report and find a high-severity finding. Can your own developer reproduce it from the report alone, without emailing the tester? If yes, the report is real work. If the finding is one line saying SQL injection possible on login page with a CVSS of 9.8 and no request shown, it came out of a tool and nobody verified it.

Finding vulnerabilities is only half the job. The point is to close them and confirm they are closed. Many buyers discover after the fact that the quote covered a single round of testing and the retest — the round that verifies your fixes actually worked — is a separate invoice. Now you have a report full of open findings, a bank or customer asking for a clean bill, and no budget line to prove you remediated anything.

Settle this in the contract. A fair engagement includes at least one free retest of confirmed findings within a defined window, commonly 30 to 90 days after the report. Get the window, the number of retest cycles, and what counts as in-scope for retest in writing. Ask specifically: if I fix these and you retest, do you issue a revised report and a clean closure certificate at no extra cost? That certificate is often the artefact your customer or regulator actually wants.

Pricing is where the market is wildest. You will see the same scope quoted at a five-fold spread, and the cheapest number is almost always a scan. Real testing is priced on person-days, because it is human labour. As a rough guide for the Indian market — treat these as directional, not fixed — here is where honest work tends to land.

If a quote for your customer-facing web application comes in at fifteen thousand rupees, understand exactly what you are getting: a licensed scanner run and a report. That may be fine for an internal baseline. It is not fine as the penetration test your enterprise customer's vendor-security questionnaire is asking for. Price on person-days and certified testers, not on the lowest line.

You do not need to be technical to expose a weak provider. You need the right questions and the discipline to listen for a real answer versus a deflection. Ask these directly.

The pattern is simple. A real firm answers the person, the manual-versus-automated ratio, and the business-logic question with specifics and stories. A scan shop redirects every one of these back to their tooling and their price.

Before you sign anything, run this list. If you cannot tick most of it, keep looking.

Come back to where we started. You are not buying a PDF and you are not buying a logo. You are buying the honest judgement of someone who tried to break in and told you the truth. The certificate is a by-product. If you choose your provider on price and empanelment alone, you will get a document that satisfies a checkbox and protects nothing. Choose on people, method, evidence and retest, and you get something rarer — a clear picture of how you would actually be attacked, and the confidence to stand behind your certificate when it matters.

At CyberSigma we are CERT-In empanelled and we run these engagements hands-on — the same auditors who sit in the room also write every finding — so if you want a scoping conversation that starts with your business and not your IP list, we are happy to have it.