Most teams first hear the phrase "VAPT audit" in an awkward moment: an enterprise customer's security questionnaire asks for a recent penetration test report, or an auditor asks for evidence before a SOC 2 or ISO 27001 certification can proceed. The deadline is usually weeks away, and nobody internally is quite sure what is being asked for.

This guide explains what a VAPT audit actually is, what the two halves of it do, how a real engagement runs, how long it takes, and what you should expect to receive at the end. It is written for engineering and compliance leaders who need to scope one properly rather than accept whatever a vendor proposes.

What VAPT Actually Stands For

VAPT means Vulnerability Assessment and Penetration Testing. The acronym is used most commonly in India, the UAE and Singapore; in the US and Europe the same work is usually sold as "penetration testing" or "security testing". The scope is broadly the same.

The important thing is that VAPT is not one activity. It is two, and they answer genuinely different questions.

Hand-drawn comparison of vulnerability assessment versus penetration testing, showing that one is automated broad and shallow while the other is human-led narrow and deep

A vulnerability assessment is largely automated. Scanners sweep your applications and infrastructure for known CVEs, outdated components and weak configuration. It is broad and shallow — it covers a lot of ground quickly and can run weekly or on every deploy, but it produces a list of things that might be exploitable, along with a fair number of false positives.

A penetration test is human-led. A tester chains findings the way a real attacker would, works around defences, and demonstrates impact end to end. It is narrow and deep, it is point-in-time, and it is valid only for the build that was tested. What it produces is proof.

You need both, and this is why they are sold together. The assessment tells you what your attack surface looks like. The test tells you which parts of it actually matter. An organisation that only scans has a long list and no idea which items are genuinely dangerous. An organisation that only pentests has deep proof about a narrow slice and no view of everything else.

What a VAPT Audit Typically Covers

Scope is where engagements go wrong most often, so it is worth being explicit before signing anything. Common scope areas:

  • Web application testing — authentication, session handling, access control, injection, business logic flaws. Usually the largest component.
  • API testing — REST and GraphQL endpoints, authorisation at object and function level, rate limiting, data exposure. Increasingly the biggest real risk, and frequently under-scoped because APIs are less visible than a UI.
  • Network and infrastructure — external perimeter, internal segmentation, exposed services, patch levels.
  • Cloud configuration — IAM policies, over-permissive roles, exposed storage, cross-account trust relationships.
  • Mobile applications — if you ship them, they need separate scoping; testing a mobile client is not the same as testing the API behind it.

Two scoping questions worth asking early. First, is testing authenticated or unauthenticated? Most real risk lives behind a login, and unauthenticated-only testing is substantially cheaper and substantially less useful. Second, is it black box, grey box or white box? Grey box — where the tester gets credentials and some architectural context — usually delivers the most findings per rupee spent, because the tester is not burning days on reconnaissance you could have handed over on day one.

How a VAPT Engagement Runs

A competent engagement moves through six phases. The first four get all the attention in a proposal; the last two are what actually determine whether the exercise was worth doing.

1. Scoping. Targets agreed, rules of engagement signed, testing windows set, emergency contacts exchanged. This is also where you agree what is explicitly off limits — production databases, denial-of-service testing, social engineering.

2. Reconnaissance. Mapping what you actually expose. This step surprises teams more often than any other, because forgotten staging environments, old subdomains and undocumented APIs turn up here regularly.

3. Assessment. Automated scanning against known CVEs and misconfiguration. Fast, broad, and the source of most raw findings.

4. Exploitation. Manual testing that establishes which findings are real. A finding that cannot be exploited in your environment is noise; a finding that can be chained into privilege escalation is a genuine incident waiting to happen.

5. Reporting. Findings with CVSS scores, severity rated in the context of your business, reproduction steps, and remediation guidance your engineers can act on without a follow-up call.

6. Retest. Confirmation that your fixes actually closed the findings. This is the phase auditors care about, and it is the one most often quoted separately or left out entirely.

One process point worth insisting on: critical findings should reach you the same day they are found. If a tester discovers something actively exploitable in week one, you should hear about it in week one — not three weeks later when the report lands. A vendor whose process holds criticals until the deliverable is prioritising their workflow over your risk.

How Long a VAPT Audit Takes

For a typical web application and API, expect two to four weeks of testing, then a reporting cycle, then a remediation and retest window that depends entirely on how fast your engineers can ship fixes.

Hand-drawn timeline of a VAPT engagement from kickoff through testing, reporting, and the fix and retest window

The variable that catches teams out is not the testing window — it is the gap between the report and the retest. If you are booking a VAPT audit to satisfy an audit deadline, work backwards from the date the auditor needs evidence, and leave real time for remediation. A report full of open critical findings is not evidence of a secure platform; it is evidence that you tested one.

Scoping delays are the other common cause of slippage. Testing cannot start until domains are verified, credentials are provisioned and the rules of engagement are signed. Teams routinely lose a week here on internal approvals that could have been started earlier.

What You Actually Receive

This is the least well-documented part of the process, and the part procurement teams care about most.

  • A technical report — every finding with severity, CVSS score, evidence, reproduction steps and remediation guidance. This is what your engineers work from.
  • An executive summary — risk posture in business language, suitable for a board or a customer's security team. Short, and usually the only part a non-technical stakeholder reads.
  • A retest report — confirmation of which findings are closed after remediation.
  • A certificate or attestation letter — a summary document confirming that testing was performed, by whom, against what scope, and on what date. This is what most enterprise customers and auditors are actually asking for when they request "your VAPT certificate".

Be precise about that last item when you scope. A certificate issued before remediation says testing happened. A certificate issued after retest says the findings were closed. Those are very different documents to hand a customer, and only one of them is likely to end a security review cleanly.

VAPT, Cloud Security and DevSecOps Are Not the Same Thing

These three get conflated constantly, and buying the wrong one is a common and expensive mistake.

VAPT is offensive and point-in-time. It finds and proves exploitable weaknesses in a specific build at a specific moment. That is what our VAPT services cover.

Cloud security is defensive and continuous. Posture management, IAM design, monitoring, hardening, misconfiguration detection. It is assessed against the running environment rather than a point-in-time test. See cloud security services, and our guide to AWS security monitoring in 2026.

DevSecOps is preventive and lives inside the pipeline. SAST, DAST, dependency and secret scanning, policy-as-code gates that stop insecure change reaching production in the first place. See DevSecOps consulting and our walkthrough of secure CI/CD workflows.

A VAPT audit tells you what an attacker could do today. It does not stop an engineer from shipping an over-permissive IAM role tomorrow. If you find yourself commissioning a pentest every quarter and finding the same class of issue each time, the problem is not testing coverage — it is that nothing upstream is preventing the issue from recurring.

When You Actually Need One

Most VAPT audits are triggered by one of four things:

  • A compliance requirement. SOC 2, ISO 27001, PCI-DSS and HIPAA all expect security testing as part of the control set, though the specific requirement varies by framework. Our AWS security checklist for HIPAA, SOC 2 and PCI-DSS covers where the requirements overlap.
  • A customer security review. Enterprise procurement increasingly requires a recent test report before a contract closes.
  • A major release or architecture change. New payment flow, new authentication provider, a migration between cloud providers.
  • An incident. After something goes wrong, the natural question is what else is exposed.

Annual testing is the common baseline. If you ship continuously, annual testing on its own leaves a long window — which is the argument for pairing a point-in-time audit with continuous scanning rather than treating the audit as the whole security programme.

How to Choose a VAPT Provider

Five questions that separate a serious vendor from a scan-and-invoice shop:

  • Is the retest included in the price? Ask directly. It is the most commonly excluded item and the one your auditor will ask for.
  • What proportion of the work is manual? If the answer is vague, you are buying a scan report with a cover page. Ask what their testers do that a scanner cannot.
  • What certifications do the actual testers hold? OSCP and similar hands-on offensive credentials are the relevant signal here, not the firm's general security badges.
  • How are critical findings communicated during testing? Same-day escalation should be the default.
  • Can you see a sample report? A redacted sample tells you more than any proposal. Look at whether remediation guidance is specific enough for an engineer to act on, or whether it is generic advice copied from a scanner.

Getting the Most Out of It

A VAPT audit is only as valuable as what you do with the findings. Three things separate teams that get value from teams that repeat the exercise every year with the same results:

Give the testers real access. Grey box testing with credentials and architectural context finds substantially more than black box testing on the same budget, because the tester spends their time on your actual risk rather than on reconnaissance.

Fix root causes, not just findings. Three separate access control findings usually indicate one authorisation model that needs rethinking, not three patches.

Feed the results upstream. If the same class of issue keeps appearing, the fix belongs in the pipeline, not in the next report.

If you need a VAPT audit scoped against a specific compliance deadline — SOC 2, ISO 27001, PCI-DSS or an enterprise customer's security review — review our VAPT services or talk to our team. We will help you scope it against what your auditor or customer is actually asking for, rather than selling you a scope you do not need.