What is VAPT and When Does Your SaaS Actually Need It?
What is VAPT, when your SaaS actually needs one, and how founders in India and the GCC should scope their first engagement without over-buying or under-buying.
SECURITY
TL;DR
VAPT stands for Vulnerability Assessment and Penetration Testing. It combines automated scanning for known vulnerabilities with manual testing that mimics how an actual attacker would try to break your product.
For most SaaS founders, the first VAPT is scoped to your web application and its APIs. Infrastructure, cloud configuration, source code, and thick client testing are separate scopes you add later based on your stack.
Founders usually think they need a VAPT because a customer asked. That is a valid trigger but not the only one. SOC 2 and ISO 27001 both require penetration testing, and a Series A investor may ask for a recent report during diligence.
A VAPT is a point-in-time exercise, not a subscription. A single engagement gives you a report you can share with enterprise buyers, and results are typically valid for twelve months unless you ship material changes to your product.
The three questions founders get wrong most often are what to scope, when to run it, and what the deliverable should look like. Getting these right the first time saves you from running a second engagement six months later because the first one did not carry weight with a buyer.
VAPT is one of those terms that founders hear in enterprise sales calls and audit checklists without ever getting a clean explanation of what it actually is. Most Google results either explain it in language written for security teams, or bury the practical decision under a service brochure. This post is meant for the founder who has just been asked for a pentest report by their first enterprise customer and needs to understand what they are being asked to buy.
What VAPT actually means
VAPT is shorthand for Vulnerability Assessment and Penetration Testing. In practice it refers to a security engagement that combines two things.
The vulnerability assessment side uses automated scanners to check your product against known vulnerabilities. Think of this as a security equivalent of running a spellcheck. It catches the obvious things quickly but does not understand your product's logic.
The penetration testing side is a human tester actively trying to break into your product the way a real attacker would. This is where the value sits for a SaaS product. A tester will chain smaller weaknesses together, look for business logic flaws that no scanner can find, and simulate what happens if a normal user tries to escalate their access.
Most engagements use one of three approaches, and the difference matters when you scope your first VAPT.
Blackbox testing gives the tester nothing beyond a public URL. It simulates an external attacker with no prior knowledge. This is the least useful for a SaaS product because a real attacker who has signed up as a user already knows more than a blackbox tester does.
Greybox testing gives the tester test user credentials and some documentation. This is the default scope for a SaaS application because it mirrors the actual threat model. Your real risk is a paying customer, a former employee, or an attacker who has phished a real user, not an anonymous internet visitor.
Whitebox testing gives the tester full documentation, architecture diagrams, and sometimes source code. This is the deepest form of testing and is typically reserved for products where the security posture itself is the product (payment processors, identity providers, security tools) or where a specific regulator requires it.
For a first-time engagement on a SaaS product, greybox is the default answer.
What actually gets tested
This is where the scoping decisions matter most, because the scope determines both the cost and how useful the report will be when a buyer or auditor reads it.
The default scope for a SaaS founder's first VAPT is the web application and its APIs. This covers the login and session management, the user permission model, the input handling on every form and endpoint, the way your product moves data between services, and the way your APIs authenticate and authorise requests. If you have a mobile app, that gets tested alongside the web application because it uses the same APIs.
Infrastructure testing looks at the servers, network, and cloud services your product runs on. Cloud configuration review checks whether your AWS, Azure, or GCP setup is following the security baselines those platforms publish. These are separate scopes and you add them when either your product genuinely runs infrastructure that a customer would interrogate, or when your enterprise buyer's questionnaire specifically asks about it.
Source code review and thick client testing exist for products where they apply. Source code review is worth doing when you have security-sensitive logic that would be hard to test from the outside, and thick client testing is only relevant if you ship a desktop application.
For most founders reading this, application and API testing is the entire first engagement. You do not need to buy the full menu on day one.
When you actually need a VAPT
Founders usually run their first VAPT for one of four reasons. Understanding which one applies to you determines when to start and how to scope.
An enterprise customer asked for a pentest report as a condition of signing. This is the most common trigger and the clearest one. Somewhere in the security questionnaire or the vendor onboarding pack, they have asked for a recent penetration test report. You have roughly two to six weeks to produce one before the deal slows down. If this is you, scope tightly, run the engagement, and get the report in the buyer's hands.
You are preparing for a SOC 2 or ISO 27001 audit. Both frameworks require penetration testing. SOC 2 references it under the Common Criteria for system operations, and ISO 27001 requires technical vulnerability management as an explicit control (Annex A 8.8 in the 2022 version of the standard). Auditors want to see evidence that you are actively testing for vulnerabilities, not just running scanners. If your SOC 2 or ISO 27001 timeline is starting, your VAPT should be scheduled to complete before your evidence collection window closes. We covered how these two frameworks compare in our SOC 2 vs ISO 27001 post.
You are raising a Series A or later round. Investor diligence at Series A rarely goes deep on security, but it does at Series B. Either way, having a recent VAPT report available signals maturity to the diligence team and prevents a scramble mid-round. This trigger is more about timing than urgency: you want a report that is under twelve months old on the day the term sheet lands.
You have crossed a product complexity threshold. This is the least discussed trigger and the one that catches founders out. Every time you ship a major new feature, a new integration, or a new authentication flow, your attack surface changes. If it has been over a year since your last VAPT and you have materially expanded the product, you are due for another one regardless of whether a customer has asked.
Founders in the GCC will encounter a fifth trigger that is worth naming. Enterprise buyers in the UAE and Saudi Arabia, particularly those in financial services or government-adjacent sectors, are increasingly asking for penetration test reports as part of vendor onboarding. This is not a formal regulatory requirement in most cases, but it is a commercial one. If your ICP includes DIFC or ADGM-regulated fintechs, an enterprise in Riyadh, or a partner integrating with a UAE government platform, a recent VAPT report shortens your sales cycle.
What founders get wrong about VAPT
Three patterns come up often enough to be worth naming.
The first is treating VAPT as a subscription. A VAPT is a point-in-time engagement, not a monthly service. You run it, you get a report, you remediate the findings, and the report is typically valid for twelve months unless you ship something material. Founders who sign up for continuous vulnerability scanning tools sometimes assume that replaces a VAPT. It does not. Automated scanning is useful between engagements, but it is not what an enterprise buyer or an auditor is asking for when they ask for a pentest report.
The second is under-scoping to save cost, then having to run a second engagement because the first report did not answer the buyer's question. If your customer is asking about your API security and you only scoped the web application, the report will not carry the weight you need it to. Scope the first engagement to what your buyer actually asked about, plus your APIs by default.
The third is running the VAPT too late in your audit or sales cycle. Testing takes time, and remediation takes more time. A typical engagement for a mid-complexity SaaS product runs two to four weeks of testing, followed by two to four weeks for remediation and retest. If you start a VAPT four weeks before your SOC 2 evidence window closes, you will be under real pressure. Start eight to twelve weeks before you need the final report in hand.
What the deliverable actually looks like
A useful VAPT report has four things that buyers and auditors look for.
An executive summary that a non-technical reader can understand, including the overall risk posture and the count of findings by severity. This is the section your enterprise buyer will read first.
A detailed technical findings section with each vulnerability described, the severity rating, the reproduction steps, and the evidence. This is what your engineering team will actually work from during remediation.
A remediation guidance section that tells your team specifically how to fix each finding, not just that they need to fix it. The difference between a useful report and a generic one is whether the guidance is actionable.
A retest section that documents which findings have been closed after your team remediates them. A report without evidence of retest is a report that says your product had vulnerabilities. A report with retest is one that says your product had vulnerabilities and they are now fixed. The second one closes deals.
Reports that lack any of these four sections tend to be scanner output dressed up with a cover page. If a buyer or auditor pushes back on your report, this is usually why.
What this post does not cover
This post is deliberately about the first VAPT decision. It does not cover the mechanics of picking a specific testing firm, the differences between compliance-driven testing and red team engagements, or how to build an internal vulnerability management programme for after your first VAPT. Those are separate posts.
We also want to be honest about a positioning boundary. Adversarial testing of AI systems, model red-teaming, and LLM penetration testing are a distinct discipline from traditional application and API testing. If your product wraps a third-party LLM API, your first VAPT should still be a conventional application and API test. AI-specific adversarial testing is a separate conversation and one where the market itself is still forming its standards.
Frequently asked questions
How long does a VAPT take?
A greybox VAPT on a mid-complexity SaaS product typically runs two to four weeks of active testing. Add two to four weeks for remediation and retest before your final report is signed off. Plan for a total of six to eight weeks from kickoff to report in hand.
How often should we run a VAPT?
Annually as a default. More frequently if you have shipped a significant new feature, changed your authentication model, or added a new integration that materially expanded your attack surface. Compliance frameworks like SOC 2 and ISO 27001 expect an annual cadence at minimum.
Do we need a VAPT if we are already running automated vulnerability scans?
Yes. Automated scans catch known vulnerabilities in software components. They do not catch business logic flaws, authorisation issues specific to your product, or chained attack paths. A pentest report backed by human testing is what buyers and auditors are asking for. Scanning is complementary, not a substitute.
We are pre-revenue. Do we still need a VAPT?
Not always. If you have no enterprise customers, no compliance timeline, and no fundraise on the near horizon, you can defer. The moment any of those change, the calendar starts. Founders who defer indefinitely tend to run their first VAPT under time pressure and pay for that pressure in scope compromises.
Will the report expose our vulnerabilities to a buyer?
Yes and that is the point. A useful VAPT report shows vulnerabilities were found, were rated, were remediated, and were retested. Buyers respect that arc. What they do not respect is a report with no findings and no evidence of testing depth, because it signals the engagement was superficial.
Is a VAPT the same as a security audit?
No. A VAPT tests your product for vulnerabilities. A security audit checks whether your organisation is following a framework of controls, such as SOC 2 or ISO 27001. The two are related and often run in the same window, but they answer different questions. A VAPT tells you whether an attacker can get in. An audit tells you whether you are running the practices that make it less likely.
Where to start
If you are reading this because a customer has asked for a pentest report, the fastest path is a scoping call that maps their specific question to a testing scope you can commit to. If you are reading this because you are preparing for an audit or a fundraise, you have more room to sequence the engagement carefully alongside the rest of your compliance work.
Either way, the first decision is not which firm to pick. It is what to scope, what deliverable you actually need at the end, and how the engagement fits into whatever is driving the deadline. That is the conversation worth having first.
If you would like to talk through your situation, our free 30-minute Discovery call exists exactly for this.
Secure your business with expert help
Company
Services
© 2026 Auro Security. All rights reserved.
Connect
insights