VAPT vs vulnerability scanning: which one do you need?

If you run engineering or security at a startup, someone has probably asked you for a VAPT report, a pentest report or proof of vulnerability scanning. This guide is for founders and engineering leads who need to know what each one is, which one a customer, auditor or regulator expects, and how to run both without losing a quarter. By the end you will know what to scan, how to scope a test, how often to do each, and what good evidence looks like.

On this page

• What a vulnerability scan actually does

• What a penetration test adds

• VAPT: how the two fit together

• What customers, auditors and regulators ask for

• How to scope and run a useful test

• A cadence that works for a startup

• How NexusVoid helps

What a vulnerability scan actually does

A vulnerability scanner compares what it can see against a database of known issues and risky patterns. There are several kinds, and each looks at a different layer of your stack:

• Network and infrastructure scanners: open ports, exposed services, old TLS versions and missing operating system patches.

• Dynamic application scanners (DAST): crawl a running web app or API and send test payloads for common flaws such as cross-site scripting or SQL injection.

• Static analysis (SAST): reads your source code for risky patterns before it ships.

• Software composition analysis (SCA): checks your open source dependencies against published CVEs.

• Secrets scanning: finds API keys, tokens and passwords committed to repositories.

• Cloud configuration scanners: public storage buckets, overly broad IAM roles, logging switched off.

What scanners are good at

Speed, coverage and repetition. A scan runs in minutes, costs little and never gets bored, which makes scanners ideal for CI on every pull request and for a schedule against production. They catch regressions: a dependency with a new CVE, a security header lost in a refactor, a port opened by an infrastructure change.

Where scanners fall short

Context. A scanner does not know which user should see which record, so it cannot tell that user A can read user B’s invoices by changing an ID in the URL. It cannot reason about business logic: a coupon applied twice, an approval step skipped, a refund larger than the original payment. The result is a long list with plenty of noise, and the most damaging flaws often missing.

What a penetration test adds

A penetration test is a time-boxed attempt to break in, against an agreed scope, using the techniques a real attacker would. Testers run scanners too, but the scan is where they start. They confirm which findings are real, chain small weaknesses into bigger ones and prove each step with an actual request.

Black box, grey box and white box

In a black box test the tester starts with only a URL, like an outside attacker. In a grey box test they also get accounts at different roles, which is where most access control bugs are found. In a white box test they also see source code or architecture documents. For multi-tenant SaaS, grey box with two tenants and two roles per tenant usually finds the most per day of effort.

What a good test covers

Most web and API tests follow public methodology: the OWASP Web Security Testing Guide (stable version 4.2) for test cases, the OWASP Top 10 and OWASP API Security Top 10 for common risk categories, and the OWASP Application Security Verification Standard (ASVS) if you want a defined requirements bar. Expect coverage of authentication, sessions, authorization across roles and tenants, input handling, file uploads, business logic and rate limiting.

What the report should contain

• An executive summary a non-technical buyer can read quickly.

• Scope, dates, method and exclusions.

• Each finding with a severity (usually a CVSS score), the affected endpoint, steps to reproduce, evidence and a specific fix.

• A retest section showing which findings were confirmed fixed.

VAPT: how the two fit together

VAPT is the term you will hear most in India, the Middle East and parts of Asia, and in tenders and regulator circulars. It is not a third kind of test: it means a vulnerability assessment to find candidates, mostly with tools, followed by penetration testing to confirm and exploit them by hand. US buyers usually just say pentest, but expect the same package.

What customers, auditors and regulators ask for

Enterprise buyers

Security questionnaires almost always ask whether you run penetration tests, how often, who performs them and whether critical and high findings were fixed. Many buyers accept an executive summary or attestation letter instead of the full report. Have both ready.

SOC 2

The SOC 2 Trust Services Criteria do not name penetration testing as a mandatory control. They do expect you to identify and monitor vulnerabilities, and most auditors look for regular vulnerability scanning and a recent penetration test as evidence that you do. In practice, treat both as expected.

ISO 27001

ISO 27001:2022 Annex A includes controls for management of technical vulnerabilities (8.8) and security testing in development and acceptance (8.29). Neither names a pentest, but scanning plus periodic testing is the usual way to show they operate.

PCI DSS

PCI DSS is more prescriptive. Version 4 calls for quarterly external scans by an Approved Scanning Vendor, quarterly internal scans, and internal and external penetration testing at least annually and after significant changes. What applies depends on how you handle card data, so confirm your scope with your assessor.

India: CERT-In empanelled auditors

In India, some regulators, government departments and financial services customers will only accept a security audit report signed by a CERT-In empanelled organization. Empanelment is granted to the auditing firm for specific categories, such as web application or network testing. If a contract asks for this, check the current list on the CERT-In website and confirm the firm covers the category you need.

How to scope and run a useful test

Most of the value of a penetration test is decided before testing starts. Work through these steps:

1. Write down what is in scope: domains, APIs, mobile apps, cloud accounts and environments. List what is out, such as third-party services you do not own.

2. Pick the environment. A staging environment that mirrors production is safer, but some issues only exist in production configuration. If you test production, agree time windows and request rates.

3. Provide test accounts: at least two tenants, each with an admin and a regular user.

4. Share context: API documentation or an OpenAPI spec, an architecture diagram and a list of sensitive actions such as payments, exports and admin functions.

5. Get written authorization from someone who can give it, and check your cloud provider’s penetration testing policy.

6. Agree how critical findings are reported during the test, not just in the final report.

7. Fix, then retest. A finding is not closed until a retest confirms it.

Common mistakes

• Scoping only the marketing site or login page and leaving out the API.

• Handing over a single account, so nobody tests cross-tenant access.

• Filing the PDF and never assigning findings to owners.

• Skipping the retest, so the report still shows open critical findings at audit time.

A cadence that works for a startup

You do not need an enterprise security team to get this right. A sensible rhythm:

The trend is toward smaller, more frequent tests. A focused test of a new payments flow in the week it ships is worth more than a broad test of the whole app nine months later.

Set fix timelines by severity, write them into your vulnerability management policy and track them, for example critical within days, high within weeks and medium within a quarter. Auditors compare your actual fix times against the policy, so pick targets you can meet.

How NexusVoid helps

NexusVoid runs your security program for you, like an autonomous CISO. Scanning and testing are part of that program, and your SOC 2 or ISO 27001 evidence comes out of the same work.

Argus covers the continuous side. It starts from the outside like a real attacker, with no credentials or installs to begin, then works inward through code, dependencies, cloud and secrets with SAST, SCA and secrets scanning. Findings are mapped to MITRE ATT&CK with attack paths, risk is priced in dollars using FAIR, and every finding has an owner. Fixes arrive as pull requests, and when one merges Argus retests and files the evidence against the controls it satisfies.

Striker covers the testing side: vulnerability assessment and penetration testing across web, API, cloud and mobile, using 20+ tools, paid per scan, with a report in under 60 minutes. You can test a feature in the week it ships instead of waiting for the annual engagement, and Aegis keeps the results as evidence in your compliance program. Together they run one loop: detect, prove, resolve, test, verify. If a contract requires a report from a CERT-In empanelled firm or another named third party, you still need that firm; NexusVoid helps you arrive with the findings already fixed.

Frequently asked questions

Is vulnerability scanning enough for SOC 2?

Usually not on its own. SOC 2 does not list penetration testing as a required control, but auditors expect evidence that you find and fix vulnerabilities, and most look for both regular scans and a recent pentest. Buyers reading your SOC 2 report often ask for the pentest summary too.

How often should a startup run a penetration test?

At least once a year, and again after major changes such as a new product, a new authentication system or new infrastructure. Many teams now run smaller, focused tests tied to releases, which keeps evidence current and catches issues while the code is fresh.

How long does a penetration test take?

A manual test of a typical web app and API takes several days to a few weeks of testing, plus scoping, reporting and retesting. Automated, tool-led tests can return results in hours. Choose based on need: fast, frequent coverage of what ships, or a deep manual review of a complex area. Many teams use both.

Do we need a CERT-In empanelled auditor?

Only if a regulator, government contract or customer requires it, which is common in Indian financial services and public sector work. Then the report must come from a firm on CERT-In’s current empanelled list, for the right category. For most private SaaS deals, buyers accept a credible third-party or tool-led test with clear evidence.

If you want to see what an outside-in test finds on your product, or the right scanning and testing rhythm for your stage, talk to a founder. Book a call at /contact.