In India, "VAPT" is the everyday term for security testing. Customers, partners, auditors, and regulated counterparties often ask for a "VAPT report" before they sign a contract, connect an integration, or approve a launch. The term combines two activities: vulnerability assessment, which looks broadly for known weaknesses, and penetration testing, which examines in depth whether those weaknesses can be used. This guide explains what a VAPT engagement usually covers, how to scope one sensibly, and what to check before you share the result.
What It Is
The vulnerability assessment (VA) part is broad. It combines automated scanning with review to identify missing patches, outdated components, exposed services, weak configuration, and common web issues across agreed assets. The penetration testing (PT) part is deep. A tester works manually on selected targets, typically web applications, APIs, and mobile apps, validating findings and testing authentication, session handling, access control between roles, data exposure, and business logic. Together, VA gives coverage and PT gives confidence in what is genuinely exploitable. A VAPT engagement should end with a written report that records scope, method, severity-rated findings with evidence, remediation guidance, and, where agreed, the outcome of a retest after fixes. Requests sometimes refer to frameworks such as the OWASP Top 10 or the OWASP Mobile Application Security guidance; these are useful reference points for what testers look at.
Who It Is For
VAPT is commonly requested by or for:
- SaaS, fintech, and e-commerce teams whose enterprise customers ask for a recent VAPT report during procurement
- Companies connecting to a partner, bank, or payment provider that requires evidence of security testing before integration
- Product teams preparing a public launch of a web or mobile application
- Organisations that changed hosting, authentication, or payment flows and want an independent check
What It Helps Clarify
A well-scoped VAPT helps clarify:
- Which applications, APIs, and environments the requester actually expects to see tested
- Whether the requirement names a specific type of auditor or accreditation that must be confirmed before choosing a provider
- Which findings are validated risks and which are scanner observations
- What remediation must happen before a report can be shared with confidence
What's Included
- Get the exact requirement in writing from the requester: assets, depth, report format, and any provider criteria
- List targets: domains, application URLs, API base paths, mobile app builds, and environments (staging or production)
- Prepare test accounts for each user role so access-control testing is meaningful
- Confirm written authorisation, test window, named contacts, and stop conditions
- Inform hosting, CDN, or WAF providers if their terms require it
- Agree severity ratings, report format, and how evidence will be shared
- Reserve time to fix findings and request a retest of agreed issues
What's Not Included
- A statement that a VAPT makes an application secure or compliant
- A claim that any provider meets a specific accreditation or empanelment requirement without checking it against that requirement
- Testing of third-party systems without the owner's permission
- Legal or regulatory advice on what a particular rule requires
When to Choose It
Commission a VAPT when a named counterparty asks for one, before a significant launch, or after major changes to how users log in, pay, or access data. If the request comes from a regulated relationship, read the requirement carefully: some specify an accredited or empanelled auditor (in India, some regulators and counterparties refer to CERT-In empanelled auditors), a particular scope, or a fixed testing cycle. Confirm those details with the requester first, because a report that does not match the requirement may need to be redone. This article is general information, not legal or regulatory advice.
Our Approach
Treat the requester's checklist as the starting point, then add the systems that carry the most risk for your business even if nobody asked about them. Test in a staging environment that mirrors production where possible, and agree in advance how production testing will be handled if it is required. Our Application Security Review covers web application and API testing with written, severity-graded findings and remediation guidance; broader multi-environment or network scopes are handled through our Penetration Testing service. In both cases scope, authorisation, and reporting are confirmed in writing before work begins. After delivery, fix the high and critical findings first, record decisions on any accepted risks, and request a retest. Then share an executive summary or remediation status letter rather than the full technical report, unless the requester specifically needs that level of detail and has a secure way to receive it.
Frequently Asked Questions
Related Articles
Get Started
Asked for a VAPT report by a customer or partner?
Share the requirement you received and the systems involved. We will help you define a scope that answers it.
Request a written scope