“VAPT” is used for two quite different things, and vendors price them as if they were one. A vulnerability scan is a tool that checks systems against a database of known weaknesses. A penetration test is a person trying to get somewhere they should not, using whatever works.
Both are worth having. Buying the first and believing you have the second is the expensive mistake.
The difference in one table
| Vulnerability scan | Penetration test | |
|---|---|---|
| What it is | An automated tool checks for known issues. | A skilled person attempts to exploit weaknesses and chain them together. |
| What it finds | Missing patches, known misconfigurations, weak TLS, exposed services. | Everything a scan finds that is exploitable, plus flaws that have no signature. |
| What it misses | Business logic flaws, broken access control, and attack paths made of several small issues. | Little within scope, but only what it was scoped to cover. |
| False positives | Common. Each needs triage. | Rare. Findings are confirmed by exploitation. |
| Frequency | Regular and repeatable: weekly, monthly or after each release. | Periodic, and after significant change. |
| Output | A list of issues ranked by a score. | A narrative: how access was gained, what it reached, and how to fix it. |
| Cost | Lower, and much of it is tooling. | Higher, because it is skilled human time. |
Where automation stops
A scanner cannot understand what your application is for. These are the flaws that need a person.
- Broken access control. User A can read user B's invoice by changing a number in the URL. The request is valid, so no signature fires. This is the top category in the OWASP Top 10, and its API form leads the OWASP API Security Top 10.
- Business logic. Applying a discount twice, skipping a payment step, or racing two requests to withdraw the same balance.
- Chained weaknesses. A low-severity information leak plus a weak reset flow becomes an account takeover.
- Authenticated depth. Scanners rarely get far beyond the login page of a real application.
- Judgement about what matters. Whether an issue is serious depends on what it reaches in your environment.
Terms you will meet
- Black box: the tester starts with no knowledge, as an outsider would. White box: with source code and architecture. Grey box: with an ordinary user account or partial knowledge, which is often the best value.
- Scope: exactly which systems, addresses and applications may be tested. Anything not in scope is off limits.
- Rules of engagement: when testing runs, what is forbidden (for example denial of service), and who to call if something breaks.
- Retest: a second pass to confirm that fixes work. Ask whether it is included in the price.
What a good report contains
- An executive summary a non-technical reader can act on.
- For every finding: where it is, how to reproduce it, the evidence, the risk and the reasoning behind the rating.
- Specific remediation, not “apply best practice”.
- A clear statement of what was and was not tested.
- Retest results showing each finding as closed or open.
Questions to put to a vendor
- What share of the work is manual, and who does it? Ask for the tester's experience, not the company's.
- Which methodology do you follow? Credible answers include the OWASP Web Security Testing Guide, OWASP ASVS, PTES and NIST SP 800-115.
- May I see a redacted sample report?
- Is the retest included?
- How will you handle my data, and where will test evidence be stored?
- What happens if testing disrupts a live service?
Which one do you need?
Most organisations need both: scanning on a regular rhythm to catch the known, and a penetration test periodically to find what scanning cannot. Compliance often asks for both. PCI DSS v4.0, for example, requires internal and external vulnerability scans at least every three months and penetration testing at least every twelve months and after significant change. ISO/IEC 27001:2022 expects technical vulnerabilities to be managed (control 8.8) and security testing in development (control 8.29).
Some Indian regulators require testing by auditors empanelled with CERT-In. Check your own regulator's current circular before you choose a vendor.