VAPT Services in Mumbai: Find a CERT-In Empanelled Provider
Most VAPT reports I have reviewed in Mumbai were sold as penetration tests and delivered as vulnerability scans. There is a difference, and it is not academic. A scan runs a tool, prints a list of CVEs, and calls it a day. A penetration test has a human being who chains three medium-severity findings into a full account takeover, then writes down exactly how they did it so your engineers can reproduce and fix it. One costs a fraction of the other. Guess which one most buyers actually pay for without realising.
If you are procuring VAPT (Vulnerability Assessment and Penetration Testing) for a business in Mumbai — a fintech in BKC, a broker in Fort, a manufacturer in MIDC, a hospital in Andheri — the hard part is not finding a vendor. There are hundreds. The hard part is telling the ones who will actually break into your systems from the ones who will email you a Nessus PDF with your logo on the cover. This piece is about how to tell them apart, what a real engagement costs and how long it takes, and what a defensible report has to contain.
Why CERT-In empanelment is the first filter, not the last
CERT-In (the Indian Computer Emergency Response Team, under MeitY) maintains a list of empanelled security auditing organisations. When people say they want a CERT-In empanelled VAPT provider, they usually mean one of two things, and it matters which.
The first is a compliance driver. If you are a regulated entity — a bank or NBFC under RBI, a stockbroker or depository participant under SEBI, an insurer under IRDAI, a payment aggregator under the RBI PA-PG guidelines — your auditor and, increasingly, your VAPT provider are expected to be CERT-In empanelled. Post the CERT-In Directions of April 2022, any organisation that suffers a reportable incident must notify CERT-In within six hours, and the forensic and audit trail you produce afterwards is judged against empanelled-grade work. If your VAPT was done by an unlisted vendor, a regulator can and does question its weight.
The second is a quality signal. Empanelment is not a rubber stamp — the organisation has to demonstrate methodology, qualified staff and process. But here is the part vendors will not tell you: empanelment sits with the organisation, not the individual tester who shows up on your engagement. An empanelled firm can still put a fresh graduate on your job. So empanelment is a necessary filter to get onto your shortlist. It is not sufficient. You still have to interrogate who does the actual testing and how.
| Your context | Is CERT-In empanelment effectively required? | Why |
|---|---|---|
| RBI-regulated bank / NBFC / co-op bank | Yes | RBI cyber-security frameworks and IT examinations expect empanelled auditors; findings from unlisted vendors carry less weight |
| SEBI broker / DP / AMC | Yes | SEBI CSCRF and system audit circulars reference CERT-In empanelled auditors |
| Payment aggregator / prepaid instrument issuer | Yes | RBI PA-PG guidelines require independent, credentialed security audit |
| Company pursuing / holding PCI DSS | Not strictly, but strongly preferred | PCI needs a QSA/ASV; empanelled firms that are also QSAs cover both mandates |
| Private company doing due diligence for an enterprise customer | Depends on the customer's clause | Many enterprise and government tenders name CERT-In empanelment explicitly |
| Startup doing a pre-launch security check | No | Quality of tester matters more than the badge at this stage |
Vulnerability assessment versus penetration test: the distinction that decides your price
This is where most Mumbai procurement goes wrong, so let me be blunt about the two halves of VAPT.
A vulnerability assessment (the VA) is breadth. Authenticated and unauthenticated scans across your estate, a version-and-configuration audit, findings mapped to CVEs and CVSS scores. It is largely tool-driven, it is fast, and it is cheap. It answers the question what is potentially wrong.
A penetration test (the PT) is depth. A human tester takes the findings and tries to actually exploit them — chaining a verbose error message into an SQL injection, an injection into database access, database access into cracked password hashes, and cracked hashes into a working login on your admin panel. It answers the question what can an attacker actually do, and how far can they get. This is manual, slow and expensive, and it is the part that finds the business-logic flaws no scanner will ever catch — the coupon that stacks infinitely, the account ID you can increment in the URL to read someone else's KYC (identity verification) documents, the OTP (one-time password) you can bypass by replaying a stale token.
Ask any vendor to show you a sample report and go straight to the findings. If every finding reads Detected by scanner, Confirm and patch, you are buying a VA dressed as VAPT. If findings read Step 1 through Step 6 with request/response evidence and a proof-of-concept, that is a real PT.
| Dimension | Vulnerability Assessment | Penetration Test |
|---|---|---|
| Primary method | Automated scanning | Manual exploitation, tool-assisted |
| Question answered | What is potentially exposed? | What can be exploited, and how far? |
| Finds business-logic flaws? | No | Yes |
| False positives | Common | Manually validated out |
| Relative cost | Low | High |
| Typical use | Continuous / quarterly hygiene | Annual, pre-launch, post-major-change |
Scoping: the conversation that determines whether the test is worth anything
A test is only as good as its scope, and a rushed scope is the single most common reason a VAPT gives false comfort. Before anyone touches a keyboard, a competent provider will pin down exactly what is in and out.
What a serious provider will insist on nailing down
- Asset inventory: exact IPs, domains, subdomains, application URLs, mobile app builds, and cloud accounts in scope — and, critically, what is explicitly out of scope
- Test type per asset: black-box (no prior knowledge), grey-box (with credentials and some architecture detail), or white-box (full source and design access) — grey-box finds far more per rupee for most apps
- Environment: production or a production-like staging clone; testing on a stale staging build that does not match production is a classic way to pass an audit and still get breached
- Roles and credentials: at least two accounts per privilege level so the tester can check horizontal and vertical privilege escalation
- Rules of engagement: test windows, rate limits, whether social engineering and DoS are in or out, and an emergency stop contact
- Data handling: whether real production data is present, and how findings and evidence containing sensitive data will be stored and destroyed
For a Mumbai fintech carrying customer PAN, Aadhaar-linked KYC and bank details, that last point is not paperwork. Under the DPDP Act 2023, your VAPT provider is effectively a data processor the moment their report contains a screenshot of a real customer record. Put the data-handling and deletion terms in the contract, not the kickoff call.
What a Mumbai VAPT actually costs — real INR ranges
Vendors dodge this question, so here are honest ranges from the Indian market as of 2026. Prices vary with complexity, number of user roles, API surface and whether you need a formal re-test, but these are the brackets you should expect. Treat anything dramatically below the floor as a scan, not a test.
| Engagement | Typical INR range | Rough duration |
|---|---|---|
| Web application PT (single app, grey-box, few roles) | Rs 60,000 - Rs 2,50,000 | 5 - 12 working days |
| Web app + REST API PT (multiple roles, integrations) | Rs 1,50,000 - Rs 5,00,000 | 10 - 20 working days |
| Mobile app PT (Android + iOS, with backend API) | Rs 1,50,000 - Rs 4,00,000 | 8 - 15 working days |
| External network / infrastructure PT (per /24 range) | Rs 75,000 - Rs 3,00,000 | 5 - 15 working days |
| Internal network PT (Active Directory, lateral movement) | Rs 2,00,000 - Rs 8,00,000+ | 10 - 25 working days |
| Cloud configuration review (AWS / Azure / GCP) | Rs 1,00,000 - Rs 4,00,000 | 5 - 12 working days |
| Full-scope annual for a regulated fintech | Rs 6,00,000 - Rs 25,00,000+ | 4 - 8 weeks |
Two things buyers underestimate. First, the re-test. A finding is not closed until someone verifies your fix, and a report without a re-test cycle leaves you asserting closure to a regulator on faith. Insist that one round of re-testing is included in the price. Second, the report and debrief. Half the value of a good PT is the walkthrough call where the tester explains the attack chain to your engineers. If a vendor quotes suspiciously low, they have usually cut the manual depth, the re-test, or the debrief — often all three.
A scene from the audit room
A payments company in Lower Parel hired us after a cheaper vendor had given them a clean external network report three months earlier. Their board wanted comfort before a funding round. We ran a grey-box test on the customer web app with two low-privilege merchant accounts.
The scanner found nothing exciting — some missing security headers, an outdated library. The interesting part came by hand. A transaction-history endpoint took a merchant ID in the URL. We changed the digits to a neighbouring value and it returned another merchant's settlement records — full transaction amounts, settlement bank accounts, contact details. An insecure direct object reference, textbook, and completely invisible to a scanner because every request was technically valid. We then found the same pattern on the refund endpoint, which meant a hostile merchant could trigger refunds against transactions that were not theirs.
None of that appeared in the earlier clean report because that vendor had run a tool and never logged in as a real user with real intent. The board did not need a longer CVE list. They needed one person who would think like an attacker who wanted their money. That is the entire difference between a scan and a penetration test, and it is why the badge on the cover matters less than the mind behind the keyboard.
What a defensible penetration test report must contain
When a regulator, a customer's security team or an acquirer reviews your VAPT, they are reading the report — not watching the test. A report that cannot stand on its own is worthless no matter how good the testing was. Judge every provider by their sample report against this list.
- An executive summary a non-technical director can read: what was tested, the overall risk posture, and the two or three things that actually matter — not a wall of CVSS scores
- Scope statement: exact assets tested, the test type, dates, and what was explicitly excluded, so no one can later claim a breached system was in scope
- Methodology: the standards followed — OWASP Top 10 and OWASP ASVS for apps, OWASP MASVS for mobile, PTES or NIST SP 800-115 for the overall process — so the work is reproducible and defensible
- Per-finding detail: title, severity with justification, affected asset, step-by-step reproduction, request/response or screenshot evidence, business impact in plain terms, and a specific remediation — not Apply patch
- A proof-of-concept for high and critical findings that a developer can actually follow to reproduce the issue
- A remediation-priority view: what to fix this week versus this quarter, ordered by real exploitability, not raw CVSS
- A re-test / closure section confirming which findings were verified as fixed, with dates
- Named, credentialed testers and the empanelment reference — so the report has provenance
One more test. Severity ratings should reflect your context, not a generic score. A cross-site scripting flaw on a static marketing page and the same flaw on your logged-in banking dashboard are not the same risk, and a good report says so. If every finding is rated straight off the CVSS calculator with no business context, the tester was not really thinking about your business.
How to choose, in one page
Once you have a shortlist of CERT-In empanelled firms, this is the checklist I would run before signing anything. It weeds out the scan-sellers fast.
- Ask for a redacted real report and read the findings section first — look for step-by-step exploitation and PoCs, not a scanner dump
- Ask who does the testing: names, certifications (OSCP, CREST, GXPN and similar) and years of hands-on offensive work — not just the firm's badge
- Confirm the split of manual versus automated effort; for an app PT, manual should dominate
- Confirm one round of re-testing is included in the quoted price
- Confirm grey-box access with multiple roles is planned, so privilege escalation is actually tested
- Check the report maps to the standards you are judged against (OWASP, PCI DSS, RBI / SEBI frameworks)
- Get the DPDP-compliant data-handling and evidence-destruction terms in writing
- Ask for the debrief call to be scheduled with your engineers as part of delivery
- Confirm the empanelment is current — the CERT-In list is periodically renewed, and lapsed empanelment can invalidate your compliance position
- Be suspicious of any quote far below the ranges above; cheap almost always means shallow
For regulated Mumbai entities, sequence it right. Do your VAPT well ahead of your annual RBI or SEBI examination and re-audit windows, so you have time to remediate and re-test before the regulator arrives — not the week before, when a critical finding turns into a fire drill.
The bottom line
The report that says everything is fine is the one to distrust. Real penetration testing produces uncomfortable findings, because a real attacker would find them too — the point is to find them first, on your terms, with a paper trail. In a city with as many vendors as Mumbai, the badge gets a firm onto your shortlist. The mind behind the keyboard, the depth of the manual work and the honesty of the report decide whether the money was well spent.
At CyberSigma we are CERT-In empanelled and we do this hands-on — senior testers who sit in the audit room, chain the findings by hand and write reports that hold up in front of RBI, SEBI and your toughest enterprise customer. If you want a scoping conversation before your next examination window, we are happy to have it.
FAQs
Is a CERT-In empanelled VAPT legally mandatory for my Mumbai business?
It depends on who regulates you. RBI-regulated banks and NBFCs, SEBI-regulated brokers and depositories, insurers under IRDAI, and payment aggregators are effectively expected to use CERT-In empanelled auditors, and many government and enterprise tenders name it explicitly. A private startup has no legal mandate, but the empanelment is still a useful quality filter.
How long does a typical web application VAPT take in Mumbai?
For a single grey-box web application with a few user roles, expect five to twelve working days of testing, plus a few days for reporting and a re-test cycle. A multi-role app with APIs and integrations runs ten to twenty working days. Anything promised in a day or two is a scan, not a penetration test.
What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan is automated breadth — a tool lists potential issues and CVEs. A penetration test is manual depth — a human tries to actually exploit and chain those issues to see how far an attacker could get, including business-logic flaws no scanner can find. VAPT should include both, but many vendors sell the scan and label it VAPT.
How often should we do VAPT?
At minimum annually, and additionally after any major change — a new application, a significant architecture or cloud migration, or a new integration handling sensitive data. Regulated entities should also align testing with their RBI or SEBI examination cycles, doing it early enough to remediate and re-test before the examiner arrives.
Does a VAPT provider come under the DPDP Act if they see our customer data?
In practice, yes. The moment a report contains real customer records — screenshots, exports, KYC documents used as evidence — the provider is handling personal data on your behalf. Your contract should specify DPDP-compliant handling, storage, access control and secure destruction of all evidence and reports.
Why do VAPT quotes vary so much for what looks like the same job?
Because the manual depth varies enormously. A low quote usually means a tool-driven scan with little hands-on exploitation, no included re-test and no engineer debrief. A higher quote reflects senior testers spending real days trying to break in by hand and validating every finding. Always compare sample reports and the manual-versus-automated split, not just the number.
Liked the post? Share on:




Leave A Comment