What is VAPT? Vulnerability assessment and penetration testing, explained

VAPT is vulnerability assessment and penetration testing: two jobs done together. First you find weaknesses in a system, then you test which of them can really be exploited. The result is a report that says what is wrong, how bad it is and what to fix first. Most teams should run one at least yearly and after major changes.

It is written for founders, engineering leads and security owners who have to buy or schedule one, so it also covers how often to run it and what the Indian context adds in 2026.

Why does VAPT matter in 2026?

Because weaknesses in software are now the leading way in. The Verizon DBIR 2026 reports that 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way in. If you ship software, testing it is part of the job.

Four published numbers worth knowing

What the numbers mean for a test plan

Access control sits at number one in the OWASP Top 10:2025, so a VAPT that never checks what one signed-in account can reach in another's data is missing the biggest class. The CISA KEV catalogue tells you which known flaws attackers already use, which helps you order fixes. The IBM report is the figure finance teams quote when they ask what a test is for.

What is VAPT, in plain words?

VAPT is a common label in India, the Gulf and parts of Asia. In the US and UK you will more often hear "security testing" or "penetration testing", and the two halves are sold separately. The label matters less than what is actually done, so always ask what the work includes.

A vulnerability is a weakness that could be used to harm your system or your data. A vulnerability assessment looks for them across a defined set of targets. A penetration test takes the weaknesses that look serious and tries to use them, the way a real attacker would, to see how far they go.

NIST's technical guide on security testing, SP 800-115, treats testing as a planned activity: you plan it, you look for weaknesses, you analyse what you found and you decide how to reduce the risk. That sequence is the backbone of every sound VAPT, whatever name the vendor gives it.

VAPT is not a certificate that says your app is secure, and not a one-off compliance document. It is a snapshot of what could be found, by a particular method, in a particular scope, on a particular date. Everything below follows from that.

What is the difference between vulnerability assessment and penetration testing?

The two halves answer different questions. A vulnerability assessment asks, "What weaknesses might we have?" A penetration test asks, "Which of these can actually be used, and what would that let someone do?"

Neither half replaces the other. An assessment without testing gives you a long list in which you cannot tell the dangerous items from the harmless ones. Testing without a broad assessment can miss the dull, widespread problems such as outdated components. A false positive in a scanner list costs your developers time; a false negative costs you more.

Where "automated scan" fits

Some cheap "VAPT" offers are one automated scan exported to PDF. That is a legitimate vulnerability assessment, and a useful one, but it is only the first half. If the quote has no manual testing and no proof of exploitation, you are buying a vulnerability scan. Ask the question early; our guide to choosing a penetration testing company has more on it.

How does a VAPT engagement work, step by step?

Methods differ, but a sound engagement follows the same arc. The web-specific detail comes from the OWASP Web Security Testing Guide (stable version 4.2 at the time of writing), the reference most testers use for web apps and APIs.

1. Scoping and agreement. You and the tester agree what is in scope (domains, apps, APIs, environments), what is out, which dates, what the tester may and may not do, and who to call if something breaks. This is your pentest scope and your rules of engagement. Get it in writing.
2. Information gathering. The tester maps the attack surface: pages, endpoints, parameters, technologies, user types. With code access, this step is much faster and more complete.
3. Vulnerability assessment. Scanners and manual checks look for known classes of weakness, such as those in the OWASP Top 10, outdated components and misconfiguration.
4. Exploitation. The tester tries to use the promising weaknesses, within the agreed limits. A weakness that cannot be used is recorded as such. A weakness that can is proved with a request, a response and a clear statement of what it exposed.
5. Post-exploitation and impact. The tester asks what the foothold leads to: other accounts' data, admin functions, other systems. This is where a "medium" issue sometimes becomes the most serious one.
6. Reporting. Findings are written up with evidence, severity and fix guidance, plus a summary a non-technical reader can act on.
7. Fixing. Your team remediates. This step is yours, and a report that is never acted on is worth nothing.
8. Retest. The tester checks that each fix works. See retest and the retest report.

If you want this as a working checklist with owners and dates, our VAPT checklist turns the steps above into tasks.

What types of VAPT are there?

"VAPT" covers several targets. Choose by what you run, not by what is cheapest to test.

• Web application VAPT: your product's web interface and its logic. See web app pentesting.
• API VAPT: the endpoints behind your web and mobile apps, which often hold the most direct path to data. See API pentesting.
• Mobile app VAPT: the app on the device plus its server calls. See mobile pentesting.
• Network and infrastructure VAPT: servers, firewalls, exposed services. See network pentesting.
• Cloud VAPT: accounts, storage and identity settings. See cloud pentesting.

A software company usually gets the most from web and API testing first, because that is where customer data is reached. Infrastructure and cloud work matters too, but it answers a different set of questions.

Black, grey and white box

Testing is also described by how much the tester knows. More knowledge generally means deeper coverage in the same time.

Black-box testing

The tester starts like an outsider with no inside information. See black-box testing.

Grey-box testing

The tester has signed-in accounts and some documentation. See grey-box testing.

White-box testing

The tester also reads the source code, so a finding can point to a file and line. See white-box testing, or our guide to choosing between the three.

What should a VAPT report contain?

You pay for the report, because the test only helps if your team can act on it. A report worth paying for has these parts:

• Executive summary. Plain language, one or two pages: what was tested, the overall picture, the few things that matter most. See executive summary.
• Scope and method. What was tested, when, from which position (black, grey or white box), with which accounts, and what was left out.
• Findings, one by one. Each with a title, the affected URL or endpoint, a description, reproduction steps, evidence, impact and fix guidance. See security finding.
• Severity and references. A rating, usually based on CVSS, plus the matching CWE and OWASP category so your developers can look up the class of bug.
• Remediation guidance. Specific to your stack, not a pasted paragraph from a textbook. See remediation guidance.
• Retest results. After fixes, a clear status for each finding: closed, partly fixed or still open.
• Attestation letter, if needed. A short statement for customers or auditors. See attestation letter.

Two details separate a good report from a padded one. First, evidence: a request and response, a screenshot where a person can see the result, and the exact steps. A finding with no proof is an opinion. Second, the difference between how severe a flaw is and how sure the tester is that it is real. FIRST's CVSS gives each flaw a numerical severity score. It is a starting point for priority, not a verdict on your business risk. Read more in severity vs confidence.

For a worked example of reading one finding closely, see how to read a finding. For the buyer's view of a whole document, see how to read a penetration test report.

What deliverables should you expect?

Besides the report itself, agree these in the contract so there are no surprises:

Ask for findings in a format your tracker can take, such as a spreadsheet or an export, so tickets can be created without retyping. That is the point of the findings export.

How often should you do VAPT?

There is no single correct answer. The honest rule is: test when the risk changes, and at least once a year if you hold customer data. Several things count as a change.

• A new product or a major release. New code is where new flaws appear.
• A change in login, roles, payments or data sharing. These are the areas where broken access control and logic flaws appear.
• A new compliance need. A customer questionnaire, a certification or a regulator asking for evidence.
• After an incident or a near-miss.
• A fix to a serious finding. Retest, not a new full test.

For frameworks the requirement is stated by the framework. For example, PCI DSS has specific penetration testing requirements for organisations that handle card data; read the current standard (v4.0.1 is listed as the current version in the PCI SSC document library) rather than a summary, and see PCI DSS 11.4. For SOC 2 and ISO 27001, what auditors expect depends on your control descriptions; see SOC 2 and ISO 27001.

A yearly test alone leaves long gaps. If your team ships weekly, an annual test describes a product that no longer exists by March. Many teams therefore pair a deeper test once or twice a year with lighter checks on every release. We cover that mix in continuous penetration testing and the continuous pentesting term.

Is VAPT mandatory in India?

No single Indian law says "run a VAPT" for every business. Whether you need one depends on your sector, your customers and your contracts.

In India "VAPT" is the usual word on RFPs, vendor questionnaires and audit requests. Each point below is stated carefully, because rules change and some apply only to particular sectors.

CERT-In and the 2022 directions

CERT-In, the Indian Computer Emergency Response Team, issued directions under section 70B(6) of the IT Act on 28 April 2022. The directions require reporting listed cyber incidents to CERT-In within six hours of noticing them and keeping ICT logs for a minimum of 180 days within Indian jurisdiction. They say nothing about how often you must run a pentest. See CERT-In directions and incident response. Read the original document for the exact wording and who it applies to.

CERT-In empanelled auditors

CERT-In keeps a list of information security auditing organisations it has empanelled. Some buyers, especially government bodies and certain regulated sectors, ask for an empanelled auditor. Others do not. Empanelment is a check on the firm, not on any report it writes. Check whether your contract, customer or regulator actually requires it before paying extra for it. We explain this in CERT-In empanelled VAPT.

DPDP Act and customer data

India's Digital Personal Data Protection Act expects organisations that process personal data to protect it with reasonable security safeguards. The Act does not tell you to buy a VAPT by name, but a recent test with fixed findings is practical evidence that you are looking for and closing weaknesses. See DPDP Act.

Many Indian software companies also sell to buyers in the Gulf or the US. Those buyers tend to ask the same question in different words: "Show us a recent pentest report and proof that the findings were fixed." A report plus a retest answers it in any country.

What does VAPT find, and what does it miss?

Know the limits before you rely on the result. Even a good VAPT is strong at some things and weak at others.

• Good at: injection and cross-site scripting, weak authentication and session handling, exposed admin panels, outdated components, misconfiguration, and mistakes in authorization that a tester can reach in the time available.
• Harder: flaws that only appear with a particular sequence of actions, rare race conditions, and business-logic flaws in features the tester never saw.
• Out of scope by design: anything outside the agreed scope, and anything that appears after the test date.

The cross-account class deserves a note of its own. One signed-in account reading another account's invoices is one of the most common serious findings in business software, and one a plain scanner usually misses because it holds a single session. Ask any vendor how they test cross-account access, and whether the accounts and data to do so are part of the plan. We wrote about the scanner side of this in why your scanner has one login.

How do you prepare for a VAPT?

A little preparation makes the test faster and the findings better.

1. Pick a staging copy that matches production, or agree safe hours on production. See test environment.
2. Prepare test accounts for each type of account you have: customer, staff, admin, partner. Give each realistic data of its own.
3. Share what exists: API specifications, architecture sketches, a list of integrations. An OpenAPI specification alone can save days.
4. Name a contact who can answer questions and who can stop the test if something breaks.
5. Allow-list the tester's addresses in your WAF or rate limits, or agree that they will be blocked and how that is handled.
6. Decide how findings will be handled in advance: who triages, who fixes, who signs off. See the vulnerability remediation process.

Cost depends mostly on scope and depth; the main drivers are explained in our guide to penetration testing cost, without quoting numbers that go stale.

What should you do after the report?

What happens in the days after delivery decides whether the VAPT was worth it.

Start with a triage meeting within a few days. Read the high-severity items together, confirm the tester's reproduction steps, and assign each finding an owner and a date. Use the severity as a guide, then adjust for what you know: a medium issue on your payments flow may outrank a high one on a test page. Tools like CISA's Known Exploited Vulnerabilities catalogue, which lists vulnerabilities exploited in the wild, help for third-party components. See KEV catalogue and risk-based prioritisation.

Fix the root cause, not only the instance. If one endpoint skipped an ownership check, ask whether others did too, and add a shared check or a security regression test so it cannot return silently. Record anything you choose not to fix as a risk acceptance, with an owner and a review date.

Finally, retest. A fix is only proven when the original exploit no longer works against the new code. Re-running a general scan does not do that. Ask for a fix verification step in the contract, and keep the retest report: it is the document customers and auditors most often want to see.

How are automation and AI changing VAPT in 2026?

They speed up the broad half: mapping an application, generating test cases and drafting reports. They do not remove the need for proof. Whatever drives the test, a finding should come with the request, the response and the steps to repeat it.

Questions to ask any provider

• Is every reported finding exploited, or only suspected?
• How are false positives removed before the report reaches you?
• Does the tool test cross-account access, or only one signed-in session?
• How is a fix verified: by a fresh scan, or by replaying the original exploit?

We set out the limits plainly on our honest page.

What are the most common VAPT mistakes?

• Buying a scan and calling it a pentest. Check for manual work and exploitation proof.
• Scoping too narrow to be useful. Testing only the marketing site while customer data sits behind a login.
• Testing once and filing the report. Unfixed findings are still vulnerabilities.
• Skipping the retest. You then have a list of claimed fixes with no proof.
• Treating the severity score as the whole story. Context decides priority.
• Not telling your team. Surprise alerts waste incident-response time.

Where Cyberlop fits

Cyberlop finds vulnerabilities in web apps and their APIs using black-box, grey-box and white-box testing. It reports only what it exploited, with the request, the response and, in white-box mode, the line of code. It then proves a fix by re-running the exact exploit against the new code. See how it works and what the evidence looks like. Where it runs matters too: private scanning keeps your code inside your own network. Be clear about what it is: a tool that produces proof-backed findings, not an empanelment or a certificate.