VAPT Explained: What You Get and How to Choose a Vendor

A client has asked for a "VAPT certificate". An auditor wants one before the ISO visit. Or an insurer's form has a box for it. Whatever brought you here, the next step is usually three quotes that describe three different jobs at three very different prices, and no easy way to tell which one you need.

This explainer is about what VAPT actually involves, what a proper report contains, and how to choose a vendor without being an expert yourself. It is written for the person who has to sign the purchase order, not the person who will run the tools.

What VAPT is, and what the two halves mean

VAPT stands for vulnerability assessment and penetration testing. The two halves are different activities that happen to be sold together.

A vulnerability assessment is a structured search for known weaknesses: outdated software, missing patches, weak configurations, exposed services, default passwords. Most of it is done with scanning tools, and a competent assessor then reviews the output to remove false positives and add context. It answers the question "what is wrong here?"

Penetration testing is a person trying to break in, within agreed rules. The tester uses what the scan found, plus manual work the scanner cannot do: logic flaws in a checkout flow, an API that returns another customer's records when you change one digit, a password reset that can be hijacked. The tester chains small weaknesses into a path to something that matters. It answers "what could an attacker actually do?"

A cheap "VAPT" is often only the first half. That is not fraud; a scan has value. But if your customer's security questionnaire asks whether a penetration test was performed, a scan report will not satisfy a careful reviewer.

What you should receive at the end

The deliverable is the VAPT report, and its quality is the clearest signal of the work behind it. A report worth paying for has these parts.

If a sample report the vendor shows you is a scanner export with a logo on top, you have learned what you need to know.

How to choose a VAPT vendor

You are buying people's time and judgement. The brochure cannot tell you much; the conversation can.

Ask who will do the testing

Larger firms sell with senior staff and deliver with juniors. That is normal, but you are entitled to know the experience of the actual testers, and to ask for a lead tester with a track record on your type of system. Certifications such as OSCP, CEH and CREST-style credentials are useful signals, not guarantees.

Ask about CERT-In empanelment, and understand what it tells you

CERT-In empanels information security auditing organisations, and the list is published on cert-in.org.in. If you are a regulated entity, or bidding for government work, you will likely need a CERT-In empanelled auditor. For everyone else it is a reasonable minimum bar. It confirms the organisation passed a process; it does not grade the depth of any particular engagement. See our note on what CERT-In does for the wider picture.

Insist on a scoping call before the quote

A vendor who quotes without asking how many applications, how many user roles, whether there is an API, whether testing can happen in production or staging, and whether source code will be shared, is quoting for a scan. Scope of testing drives effort, and effort drives price. Expect to be asked for credentials for each user role; unauthenticated-only testing misses most of what matters.

Check how findings are rated

Ask the vendor to explain how they decide severity. A good answer combines a standard scoring system with your business context: a medium-rated flaw in the payment flow may matter more than a high-rated one on an unused marketing page. A bad answer is "the tool rates it".

Confirm the retest is included

Every engagement should include a retest window, usually within 30 to 90 days, in which your team fixes findings and the tester verifies the fixes. Without a retest, you have a list, not a result. Ask whether the retest is included in the quoted price or billed separately.

What a VAPT does not do

A test is a snapshot. It describes your systems on the days it ran, with the access it was given. A new release next month can reintroduce a flaw fixed this month. That is why regulated sectors require periodic testing and why serious teams add continuous scanning between tests.

A test also does not check your people. Business email compromise, which fools accounts teams into paying fake invoices, does not need a single technical vulnerability. We cover that separately in how CFOs and accounts teams get fooled, and it is where employee awareness work earns its keep.

And a clean report is not a compliance programme. The DPDP Act 2023 asks for reasonable security safeguards and breach notification; CERT-In's April 2022 directions ask for incident reporting within six hours and 180 days of logs. A VAPT supports both but satisfies neither on its own. Our CERT-In reporting guide and DPDP compliance checklist cover the rest.

Preparing your side of the engagement

Vendors deliver better work when the client is ready. Before testing starts, have a written authorisation signed by someone with the authority to permit testing, a named technical contact who can be reached during the test window, test accounts for every user role, and a staging environment that mirrors production if production testing is too risky. Tell your hosting provider or cloud team the dates, so that the activity is not mistaken for an attack.

Decide in advance what happens if the tester finds something critical on day one. The right answer is a phone call and an immediate fix, not waiting for the final report.

Reading the report when it arrives

Start with the executive summary, then the critical and high findings. For each, ask three questions: can our developers reproduce it, what is the fix, and who owns it by when. Put the answers in a tracker that survives after the vendor leaves. Low findings are not noise; several lows chained together is how many real breaches begin, and the tester may say so in the narrative section.

If a finding touches customer data, consider whether it is also an incident. If an attacker could already have used it, the question of notification under the DPDP Act and reporting to CERT-In is live, and the answer should come from your incident response process rather than from the vendor.

Rule of thumb: if nobody on your side can reproduce a finding from the report alone, the report has failed, however thick it is. (Source: editorial guidance drawn from OWASP testing methodology and CERT-In empanelment criteria)

Where VAPT fits in a small company's plan

For most Indian SMEs, the order that works is: basic hygiene first (patching, backups, multi-factor login, a password manager), then a first VAPT on the internet-facing systems that hold money or personal data, then fixes, then a retest, then an annual cycle. Our small business starter guide lays out that sequence, and the ethical hacking foundations programme is a reasonable way for an in-house IT person to understand what testers do.