A customer asks for a "VAPT report" and two suppliers quote different amounts. One proposes a public-site scan. The other includes signed-in workflows, several roles, and two controlled tenants. The labels sound similar; the work answers different questions.
Use the written scope to compare them. NIST SP 800-115 distinguishes vulnerability scanning from penetration testing and discusses each technique's benefits and limitations. Its planning guidance also makes objectives, access, constraints, and reporting part of the assessment.
Vulnerability scanning, assessment, penetration testing and retesting
This is a buyer's comparison. Providers may combine techniques, so ask them to describe the work behind each term.
| Assessment | Main question | Useful deliverable | Boundary to confirm |
|---|---|---|---|
| Vulnerability scan | Which configured checks flag potential weaknesses? | Results with assets, scanner settings, access level, and validation status. | What the scanner could reach and whether a person reviewed the results. |
| Vulnerability assessment | Which weaknesses should we investigate or remediate first? | Reviewed findings, risk context, priorities, and coverage limitations. | How much validation and application-specific review are included. |
| Penetration test | Can an agreed security boundary fail, and with what demonstrated effect? | Confirmed findings, evidence, impact, practical fixes, and exclusions. | Roles, workflows, environments, safe validation methods, and test window. |
| Retest | Do the named changes address the original findings? | Dated results for the agreed fixes and related regression checks. | Eligible findings, changed version, expiry, and checks outside the follow-up. |
A scan can support repeatable checks for known issues. A vulnerability assessment adds interpretation and prioritization; it may include manual review. A penetration test can also use scanners, alongside application-specific investigation and controlled validation. Tools alone do not define the service.
For a signed-in application, ask how the provider will examine permissions, sessions, and business workflows. The OWASP Web Security Testing Guide offers an application-testing reference. Ask which relevant areas are included and how unavailable features will be recorded.
What does VAPT include in a proposal?
VAPT expands to vulnerability assessment and penetration testing. The acronym does not specify the systems, depth, authenticated access, report format, or retest allowance. Ask for those details in writing.
For VAPT services for teams in India, include the testing window in IST, technical contacts, evidence-handling requirements, and the report recipient's expectations. If procurement names a particular assessor qualification or report format, confirm it before booking. The same principle applies to a US customer review: the recipient's actual requirements matter.
A fictional scope example: one SaaS product, three different assessments
Synthetic planning example: a fictional expense-management product has a browser application, an API, employee and finance-admin roles, and separate customer workspaces. This illustrates scope choices, not completed client work.
- Public-site scan: checks the reachable public interface using agreed settings. Signed-in expense approvals and workspace separation remain outside coverage.
- Application pentest: includes the browser and API, both roles, two controlled workspaces, synthetic expense records, and approval and export workflows. The proposal names the expected access boundaries and testing limits.
- Bounded retest: checks named fixes on the agreed build and related workflows. A newly added payroll integration needs a scope decision before it is assessed.
If the buyer's question is whether employees can access another customer's records, the public scan leaves that question unanswered. A scoped SaaS penetration test can include the relevant roles and workspaces. That does not establish coverage of the whole cloud account or every integration.
Seven procurement questions to ask before signing
- What exact assets are included? Request named applications, APIs, environments, integrations, and exclusions.
- What access will you use? Confirm authenticated roles, controlled tenants, documentation, and dependencies.
- Which workflows receive manual review? Ask about permissions, business rules, and the depth of validation.
- How are findings confirmed? Ask how potential issues are separated from demonstrated security consequences.
- What constrains testing? Agree authorization, safe data, request limits, escalation contacts, and stop conditions.
- What will we receive and when? Confirm reporting, urgent notifications, walkthroughs, and material limitations.
- What follow-up is included? Record retest eligibility, timing, allowance, and the process for changed scope.
Compare effort only after those assumptions match. Use the pentest cost and scope guide to identify differences behind each quote.
What evidence should the report contain?
Look for the assessed version, dates, access, scope, and coverage gaps. A finding should distinguish expected behavior from the observed result, explain prerequisites and demonstrated impact, and give engineering a practical remediation direction.
Inspect the fictional sample penetration testing report and the pentest report checklist. A finding count or tool export alone does not show whether the question in your brief was answered.
How should retest scope and status be recorded?
A retest should preserve the original finding and add the checked version, date, evidence, and result. Record each agreed item as fixed, partially fixed, not fixed, or not retested. An unavailable account or unfinished deployment should leave the result unverified.
For the fictional expense product, checking one repaired approval workflow would not cover a new payroll integration. Keep that limit visible. A closure summary can describe verified remediation within scope; it cannot certify that the entire product is vulnerability-free.
Choose the assessment from your next decision
Write the question first: identify known weaknesses, assess a permission boundary, support a review, or verify specific repairs. Then agree the systems, access, methods, and evidence needed to answer it.
Start with a web and API scope brief, compare web application testing with API penetration testing, or request a scoped proposal. Share project context and the deadline; arrange sensitive access details through the agreed channel later.
All penetration testing guides | Remote testing for US teams