VAPT

VAPT vs Vulnerability Scanning: What You’re Actually Buying

Manish Garg
Manish Garg Associate CISSP Β· RingSafe
April 19, 2026
6 min read

A vulnerability scan is a blood-pressure reading. A penetration test is a cardiac stress test. Both are useful. Both are called “security testing” in casual conversation. They serve different purposes, cost different amounts, and produce different decisions. Buying one when you needed the other is how organizations end up with a compliance document that does not reflect their actual security posture β€” and how they end up breached with a recent “VAPT” on file.

This guide exists because we get the same question every week: “We already have a vulnerability scan report. Do we still need a pentest?” The honest answer depends on what you are trying to prove, to whom, and what decision follows from the answer. Here is how to tell.

The core distinction

A vulnerability scan is a breadth exercise. An automated tool β€” Nessus, Qualys, OpenVAS, Rapid7 InsightVM β€” enumerates known weaknesses against a target list. Missing patches, insecure configurations, outdated cipher suites, weak SSL/TLS, default credentials on well-known services. The scanner’s strength is coverage: it tests for every CVE in its database against every asset in scope. Its weakness is depth: it cannot reason, cannot chain findings, and cannot assess business logic.

A penetration test is a depth exercise. A human tester scopes an attack surface, hypothesizes where real weaknesses will live, and attempts to compromise a specific target. Findings are chained into attack paths that demonstrate real impact. The tester’s strength is judgment: reading an application, understanding its domain, and constructing exploits that cross the boundaries between individually-harmless weaknesses. Weakness: coverage. A tester examines what they think matters, not every CVE known to exist.

The concrete difference in findings

A vulnerability scanner on a standard web application will produce:

  • Missing HTTP security headers (X-Frame-Options, CSP, HSTS)
  • Outdated jQuery version with known XSS vulnerabilities
  • TLS 1.0/1.1 enabled on the load balancer
  • Cookie missing Secure flag
  • Server banner leaking version information
  • SSH weak ciphers accepted
  • Dozens of CVEs in the underlying OS packages

All real findings. Most are low or medium severity. Fixing them improves posture without preventing a single determined attack.

A penetration test on the same application will produce:

  • Horizontal IDOR in the tenant admin API β€” any customer can read another customer’s data by ID iteration
  • Mass-assignment vulnerability in profile update β€” any authenticated user can promote themselves to admin
  • Race condition in the refund endpoint β€” concurrent requests cause the refund to be processed twice, draining treasury
  • Server-side request forgery via URL preview feature β€” AWS credentials from IMDSv1 can be retrieved
  • Stored XSS in comment field rendered in admin support dashboard β€” admin session compromise on view
  • Business-logic flaw in discount code application β€” stacking coupons beyond the intended cap

Every one of these is a direct path to money loss, data loss, or breach. None are detectable by automated tools.

When a scan is enough

Vulnerability scanning is the right choice when:

  • Your regulator requires “vulnerability management,” not penetration testing. PCI DSS 11.3 requires both; many other regimes (including parts of the DPDP framework) accept documented scanning as evidence of “reasonable security safeguards.”
  • Your attack surface is standardized and well-understood. A fleet of cloud workloads running a supported OS with a managed application layer benefits more from weekly automated scanning than from quarterly manual testing β€” the scanner will catch the new CVE faster than any human.
  • You are building a continuous monitoring program. Scans run weekly. Pentests run annually at best. For ongoing posture visibility, scanning wins on cadence.
  • You are at the stage of startup maturity where posture management is the goal. A three-month-old seed company does not need a penetration test; it needs to stop running vulnerable WordPress plugins.

When a scan is not enough

A vulnerability scan is inadequate when:

  • You have custom application code. Scanners do not understand your application’s authorization logic, multi-tenancy boundaries, or business rules. The findings that matter for your SaaS product are not in the scanner’s database because they are specific to your application.
  • Your enterprise buyer is asking for a penetration test specifically. A scan report is not a pentest report. Buyers with mature security programs can tell the difference in page one of the deliverable, and “penetration testing” is a specific line item in vendor security questionnaires.
  • You are preparing for a compliance framework that requires pentesting. PCI DSS 11.4, ISO 27001 A.8.29, SOC 2 CC4.1, RBI Cybersecurity Framework β€” all require manual penetration testing, not just vulnerability scanning.
  • You are post-incident or in breach-response mode. A scan tells you what is missing a patch; a pentest tells you what the attacker could still do even after you have patched everything visible.
  • Your application has business-critical flows. Payment processing, KYC, document signing, financial calculations, regulated data handling. Business-logic flaws in these flows cost organizations directly when exploited, and are categorically undetectable by scanners.

The commonly-sold hybrid: “VAPT”

Most Indian providers package both under the single label “VAPT” β€” Vulnerability Assessment and Penetration Testing. The honest ones deliver both activities integrated: the assessment builds the terrain map, the pentest walks it. The less-honest ones deliver a Nessus scan with a few human-authored findings, price it as a full pentest, and leave you thinking you bought something you did not.

How to tell which you are getting:

  • Ask for the methodology before signing. A real pentest methodology names phases (reconnaissance, mapping, authentication testing, authorization testing, business-logic testing, etc.) and commits to tester-days in each. A fake one says “OWASP Top 10” and stops.
  • Ask for a redacted prior report. Look at the findings section. If every finding is formatted identically, sourced from a scanner database, and includes CVSS scores but no reproduction walkthrough, you are buying a scan.
  • Ask who will test. Real pentests are done by named individuals with certifications you can verify and often publicly documented work. Scanning engagements are run by pools of junior engineers with Nessus licenses.
  • Ask the price per tester-day. Below β‚Ή10,000/day, you are not getting a senior pentester. Do the arithmetic on any quote.

What you should actually buy

For most Indian SaaS startups in 2026, the honest recommendation is:

  • Continuous automated scanning for posture hygiene. Nuclei running against production weekly. Snyk or Dependabot on dependencies. A cloud-configuration scanner (Prowler, ScoutSuite, or Steampipe) running monthly against AWS/Azure/GCP accounts. This catches the 80% of findings that automation is designed to catch. Cost: near zero for tooling, 2–4 engineering-hours per week to triage.
  • Annual manual penetration testing of the critical applications and the high-value flows. Senior tester, grey-box, 10–15 days. This catches the 20% of findings that actually matter commercially. Cost: β‚Ή85,000–₹2,50,000 per scope per year.
  • Targeted pentest on material changes. New authentication flow, new tenant model, new payment integration, cloud-provider migration. Scope the pentest narrowly to the change. Cost: β‚Ή50,000–₹1,50,000.

This combination gives coverage and depth at a cost roughly equivalent to a mid-tier “VAPT” engagement from a fake-pentest vendor, but with dramatically better signal.

What to ask before you spend

Four questions before buying either:

  • What am I trying to prove, and to whom? (compliance / buyer / board / self)
  • What decision follows from the result? (fix findings / publish report / pass audit)
  • Is the finding I most fear one that a scanner can detect?
  • How fresh does the assessment need to be when the decision is made? (weekly / annual / point-in-time)

Honest answers to those four usually make the scan-vs-pentest choice obvious. When they do not, the answer is often “both” β€” and the right engagement is a VAPT with an honest provider who actually does both.

Related reading

If you are unsure whether scanning, penetration testing, or a combined VAPT is the right fit for your organization, book a scoping call. We will recommend what you should buy β€” including when the answer is “neither, yet.”