VA vs PT: two different exercises, often bundled together
Vulnerability assessment (VA) is a broad, automated scan of your systems against known vulnerability databases — misconfigured servers, outdated dependencies, exposed ports, weak SSL configurations. It's fast, repeatable, and gives you a prioritized list of issues, but it won't tell you whether those issues are actually exploitable in your specific environment.
Penetration testing (PT) is where a human tester actively tries to exploit those vulnerabilities — chaining together weaknesses the way a real attacker would, to see how far they can get and what data or access they can reach. This is what turns "this endpoint has a theoretical vulnerability" into "here's exactly how someone could use it to access customer records."
Together, VAPT gives you both breadth (the automated scan) and depth (the human-driven exploitation) — which is why most compliance frameworks require both, not one or the other.
Why compliance frameworks require it
If you're pursuing SOC 2, ISO 27001, PCI-DSS, or — for financial services and market infrastructure firms in India — SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), regular VAPT isn't optional. Auditors want to see a dated report, a remediation timeline, and evidence that flagged issues were actually fixed and retested — not just a scan that ran once and got filed away.
What a typical VAPT engagement looks like
- Scoping. Defining what's in bounds — specific applications, IP ranges, APIs, mobile apps — and what testing methods are authorized (black-box, grey-box, or white-box).
- Reconnaissance. Mapping the attack surface: subdomains, exposed services, technology stack, publicly available information that could aid an attacker.
- Vulnerability scanning. Automated tools identify known CVEs, misconfigurations, and weaknesses across the scoped systems.
- Manual exploitation. Testers attempt to actively exploit findings — SQL injection, broken authentication, privilege escalation, business-logic flaws that automated scanners can't catch.
- Reporting. A prioritized report ranking findings by severity (usually CVSS-scored), with clear reproduction steps and remediation guidance for each.
- Remediation retest. After your team fixes the flagged issues, a follow-up test confirms they're actually resolved — this step is what auditors specifically look for.
Across engagements, the most frequent findings aren't exotic zero-days — they're OWASP Top 10 basics: broken access control, injection flaws, security misconfiguration, and outdated components with known vulnerabilities. Most breaches don't require a sophisticated attacker; they require an unpatched gap someone eventually notices.
How often should you test?
As a baseline: a full VAPT engagement at least once a year, plus after any major change — a new product launch, a significant infrastructure migration, or a new integration that handles sensitive data. Fast-moving teams shipping weekly often pair this annual deep test with lighter automated scanning in CI/CD, so vulnerabilities in new code get flagged before they ever reach a full pentest.
Choosing a VAPT vendor
Look for testers with recognized certifications (CEH, OSCP), a clear methodology (OWASP Testing Guide or PTES-aligned), and — critically — a sample report you can review before signing. A report that's just a list of scanner output with no manual verification isn't a penetration test, regardless of what it's called. Ask specifically how much of the engagement is manual testing versus automated scanning.
The bottom line
VAPT isn't a checkbox for an audit — it's the closest thing to a fire drill your infrastructure will ever get. The value isn't the report itself; it's the fixed vulnerabilities that never make it into a breach disclosure. Budget for it the same way you budget for backups: not because you expect to need it tomorrow, but because the cost of not having it is unbounded.