How to choose a VAPT provider in India

"VAPT" bundles two different activities. A vulnerability assessment is largely automated: tools enumerate hosts and services and match them against known issues, producing breadth. A penetration test is manual work on top of that, where a person chains findings together, abuses application logic and demonstrates what an attacker could actually achieve.

Both are legitimate and they cost very different amounts. A quote that is a tenth of another is often an automated scan with a report generator attached — which is not fraud, but is not what most buyers think they are getting.

So the first question is not price. It is: how many days of manual testing does this include, and against what?

**What exactly is in scope?** Which domains, which applications, which API endpoints, which network ranges, which user roles. Scope creep is where engagements go wrong in both directions.

**Is authenticated testing included?** An unauthenticated test of an application whose value sits behind a login examines the front door and skips the building. Most serious findings — broken access control, object-level authorisation flaws — are only reachable when logged in, and only with more than one account.

**How many days of manual effort, and by whom?** Ask for the tester's experience and certifications, not the company's. The gap in quality between testers is far larger than the gap between firms.

**What methodology?** OWASP Testing Guide and the OWASP API Top 10 for applications, CIS benchmarks for configuration. A provider who cannot name a methodology is improvising.

**Will you demonstrate exploitability?** A finding worth acting on comes with the request that proves it and a statement of business impact, not just a CVSS number.

**Is a re-test included?** You will fix things. Someone has to confirm the fixes work, and that should be part of the engagement rather than a second invoice.

**Who sees the report, and how is it delivered?** A document listing exactly how to compromise your systems needs to be handled like one.

**What happens if you find something critical mid-test?** The right answer is that they stop and telephone you the same day, not that it appears in a report three weeks later.

An executive summary a non-technical director can act on, and a technical section an engineer can reproduce from. If only one of those exists, half your organisation cannot use the document.

Per finding: what it is, where exactly, the steps to reproduce, evidence, the business impact in plain language, a specific remediation, and a severity that has been adjusted for your context rather than copied from a tool. A default-credential finding on an unreachable internal service is not more urgent than a broken access control on your checkout, whatever the scanner says.

It should also state what was **not** tested, and why. A report with no stated limitations is a report that is hiding its gaps, and those gaps become your assumptions.

Unauthorised access to a computer system is an offence under India's Information Technology Act. Written authorisation defining scope, timing and permitted techniques is what makes the engagement lawful, and it is as much your protection as the tester's.

You also need it if you do not own the whole target. Testing on shared hosting, on a SaaS platform, or against a third party's API generally requires that provider's permission too, and their terms will say so.

A provider who offers to start without paperwork is telling you how they treat everyone else's systems. That is the most useful signal you will get in the whole procurement.

If you are testing because a customer's security questionnaire or an auditor demands it, be honest about that. It is a legitimate reason and it changes the shape of the engagement: you need coverage and a certificate, on a predictable schedule.

If you are testing because you want to know what an attacker could do, you want depth on the systems that matter most, and you may want less breadth to pay for it.

Problems arise when a buyer wants the second and purchases the first. Say which one you need, and let the provider tell you if the budget matches it.

"We guarantee we will find everything" — nobody can, and a tester who says so has not done enough of this work.

"We can start today, no paperwork needed."

"We do not need any credentials." For an application with a login, this means the test will miss the findings that matter.

"The report is automated output." Then you are buying a scan, and it should be priced like one.

"We will also fix everything we find" — possible, but notice the incentive: the party paid to find problems should not be the only party who benefits from finding more of them. Separate the two, or scrutinise the findings harder.

A refusal to name the tester, or to say how much of the work is manual.

Triage it against your own context within a week, while the engagement is fresh, and assign an owner and a date to each finding you accept. A report nobody has divided up gets read once.

Decide explicitly which findings you are accepting rather than fixing, and write down why. An accepted risk that is recorded is a decision; an accepted risk that is forgotten is a surprise.

Then use the re-test. The value of the whole exercise is in the fixes being verified, and an engagement that ends at the report has delivered you a document rather than an improvement.