Choosing a VAPT company in India is harder than it should be, even though there is no shortage of options. Search for VAPT services in India and you will find a long list of firms, most using the same vocabulary ("comprehensive", "manual and automated", "OWASP-aligned", "CERT-In") and quoting prices that vary by an order of magnitude for what appears to be the same work. The acronym does not constrain what you receive, so two proposals with identical headings can describe completely different engagements.
This article is about telling them apart. It deliberately does not rank or name anyone, because a list of "top VAPT companies" mostly tells you who is good at marketing. Instead it sets out the questions that expose the difference between vendors, and the red flags that should end a conversation early.
If you are still working out what VAPT involves in the first place, start with what VAPT is and how an engagement runs.
Start with what you actually need
Before evaluating anyone, be clear about three things. Each one changes which vendors are suitable at all.
What is in scope. List the web applications, APIs, mobile apps, external network ranges, and cloud accounts that matter. Note how many distinct user roles each application has and which flows sit behind login. A vendor can only scope honestly against information you provide.
Who is asking, and what they will accept. An enterprise customer's security team, a regulator, a government tender, an ISO 27001 auditor, and a cyber insurer may all ask for "a VAPT" but accept different evidence. Find out whether the requirement specifies a recency window, a retest, a particular report format, or a CERT-In empanelled auditor.
Your deadline. If a contract is waiting on the report, the testing window, reporting time, your remediation time, and a retest all have to fit before it.
The questions to ask any penetration testing company in India
How much of the testing is manual?
Start here, because this question matters most. Automated scanning is useful and belongs in a VAPT, but it cannot find broken authorisation, business-logic flaws, or chained attacks, and those are usually the issues that matter in a modern application. We have written about exactly why scanners miss these.
Ask how many tester-days of manual work the quote includes, and what those days will be spent on. A good answer is specific: authentication and session handling, access control across each role, the named business workflows, API authorisation. A vague answer ("our expert team uses industry-leading tools") usually means the manual part is thin.
Who will actually do the testing?
Ask who will be on your engagement and what their experience is with your type of target. Web, API, mobile, network, and cloud testing are different skills. Ask whether the work is done in-house or subcontracted, and if subcontracted, to whom. You are entitled to know who is touching your systems and data. Professional certifications held by testers can be a useful signal, but they do not replace relevant hands-on experience, so ask about both.
What methodology do you follow?
Credible testers can name the frameworks they work against and explain how those shape coverage: the OWASP Web Security Testing Guide and OWASP Top 10 for web applications, the OWASP API Security Top 10 for APIs, OWASP MASVS and MASTG for mobile, and frameworks such as NIST SP 800-115 or PTES for infrastructure. Ask how severity is rated. CVSS is the common reference, but a good tester adjusts for context and explains why.
Naming a methodology does not prove quality. If a vendor has none, or cannot explain theirs beyond the name, treat that as a strong negative signal.
Can we see a sample report?
Any established VAPT company should be able to show you a redacted or synthetic sample report. Read it carefully. Look for:
- a clear scope and methodology section that states what was not tested;
- findings with step-by-step reproduction instructions and evidence;
- severity that reflects real-world impact rather than pasted scanner scores;
- remediation guidance specific enough for a developer to act on;
- an executive summary a non-technical stakeholder could understand.
If the sample is mostly scanner output in a branded template, expect your own report to look the same.
Is a retest included, and on what terms?
Ask whether a retest of the original findings is included, within what time window after the report, and whether the retest results are documented in an updated report or letter. Many customers and auditors care less that issues were found than that they were demonstrably fixed.
How do you scope, and how do you price?
A serious vendor asks questions before quoting: how many applications and roles, black-box or credentialed, production or staging, how many hosts or endpoints, whether mobile builds are involved. Price should follow from those answers. The main cost drivers are the number of targets, the number of user roles and authenticated flows, the depth of manual testing, credentialed versus black-box access, the reporting format required, and whether a retest or an empanelled auditor's report is needed.
Ask for the scope to be written into the proposal in enough detail that you could hand it to a second vendor for a comparable quote. Without that level of detail, you have no reliable way to compare two proposals line by line.
What are the rules of engagement?
Ask how testing will be authorised and controlled: a written agreement on in-scope targets, excluded techniques, testing windows, source IP addresses, and escalation contacts on both sides. Also ask what happens if a critical vulnerability is found mid-test. You should be told immediately rather than reading about it in the final report.
How will you handle our data?
Testers may see customer records, credentials, source code, or internal documents. Ask whether they will sign an NDA, where evidence and reports are stored, how long they are retained, how credentials you provide are handled, and how data is disposed of after the engagement. The report itself is a sensitive document, since it lists ways into your systems, so ask how it will be delivered.
Are you CERT-In empanelled, and does it matter for us?
CERT-In empanels information security auditing organisations and publishes the current list on its website, so empanelment claims can and should be checked against that list rather than taken from a vendor's slide.
Whether you need an empanelled auditor depends on who is asking for the report. Government departments, public sector bodies, and public tenders frequently require it, and some regulators require it of the entities they regulate. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), for example, points its regulated entities to CERT-In empanelled auditing organisations. Some bank and government-linked customers write it into vendor contracts. If your requirement comes from a private enterprise customer that simply wants recent independent testing, empanelment is usually not required, and testing quality is what you should be optimising for.
So ask two questions. Does this requirement need an empanelled auditor's report? And if so, who exactly will issue it? Some firms that are not themselves empanelled deliver such reports through empanelled partner auditors. That is legitimate, provided it is stated plainly and the issuing organisation is named.
Red flags
A free VAPT. Genuine penetration testing is days of skilled manual work. A "free VAPT" is almost always an automated scan with the output reformatted. Free scans can be useful; just do not mistake one for a penetration test, and do not submit one to a customer who asked for a pentest report.
A price before any scoping questions. A fixed price for "VAPT" quoted before the vendor knows how many applications, roles, or endpoints you have cannot reflect the work. Either the testing will be cut to fit the price or the price is padded.
No sample report. If a vendor cannot show you what you will receive, you have no basis for judging it.
Guarantees of "100% secure". No honest tester will certify a system as completely secure. Testing shows what was found within a scope and a time window; it cannot prove the absence of every flaw. A vendor that promises otherwise either misunderstands the work or is misrepresenting it.
Vague or unverifiable empanelment claims. "CERT-In approved" with no name to check on CERT-In's published list, or no clarity on which organisation will sign the report, should be resolved before you sign.
Unrealistic timelines. A full manual test of a multi-role application, written up properly, does not happen overnight. Ask how the timeline breaks down between testing and reporting.
Reports that are mostly scanner output. Hundreds of findings, none validated, all with generic remediation text, suggest that the manual half of the VAPT did not happen.
How we approach it
Since you are reading this on our site, here is a brief, factual note on how our VAPT service works. We scope every engagement up front and quote a fixed price against that scope, with rules of engagement agreed in writing before testing begins. Testing combines automated scanning with manual exploitation, and findings are reported with CVSS-aligned severity, reproduction steps, and developer-facing remediation guidance, alongside an executive summary. A retest is available to confirm fixes. Safe Tech AI is based in Nagpur and delivers remotely across India and internationally. We are not ourselves CERT-In empanelled; where a regulator, tender, or customer requires a CERT-In empanelled report, we deliver the engagement with an empanelled partner auditor and say so at scoping. You can see how we think about scope and cost on our pricing page.
Whoever you choose, the same questions apply. A good VAPT company in India, or anywhere, will welcome them.
A starting point
If you are about to compare proposals and want an independent view of what your scope should be first, our free 30-minute manual assessment may help. A practitioner reviews what is reachable from outside and tells you plainly whether a full VAPT, a narrower test, or nothing yet is the right next step. That gives you a clearer brief to take to any vendor, including us.