If you are reading this page, your tender response, your annual security obligation, your buyer’s due-diligence questionnaire, or your sectoral regulator just used the words VAPT report from a CERT-In empanelled auditor. That phrasing is increasingly the universal floor for technology procurement in India in 2026 — RBI’s outsourcing master direction, SEBI’s CSCRF, IRDAI’s guidelines, MeitY’s GeM marketplace, almost every state-government RFP, and a growing share of US enterprise buyers all reference it. The VAPT market in Bangalore is also one of the most over-subscribed in Indian compliance — there are dozens of vendors of varying competence, and the price band stretches from ₹40,000 (which is too cheap to be useful) to ₹15,00,000 (which is too expensive for the scope). This page is meant to help a Bangalore CTO, CISO, or procurement lead calibrate where on that band the right vendor sits, what a useful VAPT engagement actually delivers, and what the report looks like at the end.
What VAPT actually means in 2026
VAPT — Vulnerability Assessment and Penetration Testing — is a compound discipline that combines two distinct but complementary methodologies. Vulnerability Assessment is the systematic identification and ranking of security weaknesses across an in-scope environment, using a mix of automated scanning, configuration review, and known-vulnerability matching against CVE / NVD / vendor advisories. Penetration Testing is active exploitation of identified weaknesses (under defined rules of engagement) to demonstrate real-world impact, chain attack paths, and distinguish theoretical findings from exploitable ones.
In Indian practice in 2026, most procurement teams use "VAPT" as shorthand for both — a methodology that produces a ranked finding list (the VA part) and then validates exploitability for the highest-impact findings (the PT part). Pure-VA engagements (scanning only, no exploitation) are still sold by some vendors but are rarely useful as a buyer-readiness or audit-readiness deliverable; they identify what might be a problem without proving what is. Pure-PT engagements (red-team exercises with broad rules of engagement and goal-based testing) are sold to mature security organisations but are overkill for first-time-VAPT buyers.
The methodology that most Bangalore engagements actually need is scope-based VAPT: a defined list of in-scope assets, a structured testing plan covering each asset, manual analysis layered on top of tool output, exploitation of findings to validate impact, and a written report with reproduction steps and remediation guidance for each finding.
CERT-In empanelment — and why it matters
CERT-In (the Indian Computer Emergency Response Team, operated by the Ministry of Electronics and Information Technology) maintains an empanelment list of Information Security Auditing Organisations — third-party auditors that CERT-In has technically vetted to perform information-security audits and incident-response work. Empanelment is granted for typically three years, requires a documented technical assessment, financial due-diligence review, and sample-audit verification, and is renewed via reassessment.
Empanelment matters in three concrete ways for a Bangalore vendor buying VAPT:
1. Tender eligibility
Most BFSI, government, telecom, capital-markets, and critical-infrastructure RFPs require the auditor to be CERT-In empanelled. The technical-eligibility section of the tender document typically reads "the audit shall be conducted by an organisation listed on the current CERT-In empanelment of Information Security Auditing Organisations" — non-empanelled vendors are filtered out before the financial bid is even opened.
2. Regulatory requirement linkage
RBI’s Master Direction on Outsourcing of Information Technology Services (April 2023) requires regulated entities to obtain VAPT reports from CERT-In empanelled auditors at defined frequencies. SEBI’s CSCRF requires the same for stock exchanges, depositories, AMCs, RTAs, and other Market Infrastructure Institutions (MIIs). IRDAI’s information security guidelines for insurance vendors echo the requirement. If your buyer is RBI / SEBI / IRDAI regulated, your VAPT must come from an empanelled vendor — full stop.
3. CERT-In incident-reporting framework
Direction 20(3)/2022 of 28 April 2022 obligates Indian organisations to report cyber-security incidents to CERT-In within six hours. The framework for those reports presupposes a documented audit relationship and an incident-response plan that has been reviewed against current best practice — relationships easiest to establish through an empanelled auditor. We bundle CERT-In incident-reporting templates and the underlying contact procedures into every VAPT engagement.
Verifying empanelment is a one-minute exercise: visit cert-in.org.in/auditors, search for the firm’s name, confirm the empanelment number and validity period. Always do this before signing — empanelment status changes quarterly and trusting a vendor’s claim without verification has cost more than one Bangalore procurement team a re-tender.
Who in Bangalore is required to do VAPT
VAPT is mandatory or strongly-expected for several categories of Bangalore-based organisations under various regulatory frameworks. The list below is not exhaustive but covers the obligations our clients most commonly deal with.
Banks, NBFCs, and payment aggregators
RBI requires annual VAPT at a minimum for all RBI-regulated entities, with quarterly testing for systems supporting digital banking channels. Reports are submitted to RBI as part of the annual cybersecurity audit obligation.
Stock brokers, depositories, AMCs, RTAs, and other MIIs
SEBI’s CSCRF requires quarterly VAPT, half-yearly cybersecurity audits, and annual cyber-resilience drills for Market Infrastructure Institutions. Smaller market participants (registered intermediaries) follow a less-intensive schedule. See our SEBI CSCRF page for the full schedule.
Insurance companies and intermediaries
IRDAI’s 2017 (revised 2023) Information and Cyber Security Guidelines require annual VAPT at minimum, with reports submitted as part of the insurer’s annual ICSG audit.
Telecom service providers and ISPs
DoT and TRAI obligations for telecom security require periodic security audits including VAPT.
Government and PSU technology vendors
MeitY’s requirements, GeM’s vendor-eligibility criteria, and most state-government RFPs require VAPT certificates from empanelled auditors.
Vendors selling into UIDAI / Aadhaar ecosystem
UIDAI’s AUA / KUA / Sub-AUA frameworks require VAPT as part of the operational compliance.
SaaS vendors selling into BFSI
Even if you are not directly regulated, your BFSI buyer’s outsourcing-vendor onboarding will require a current VAPT report from an empanelled auditor as a pre-onboarding control.
Companies pursuing SOC 2 / ISO 27001
Both frameworks require evidence of a vulnerability-management programme. The VAPT report is the canonical evidence; we co-deliver VAPT alongside SOC 2 and ISO 27001 in roughly 40% of those engagements.
Six VAPT scope types we deliver
Most engagements bundle two or three of the following scope types into a single VAPT statement of work. We sequence the testing so that early-phase findings inform later-phase scope refinement.
1. External network and infrastructure
Internet-facing IP ranges, perimeter services, exposed ports, VPN gateways, mail servers, DNS, web servers, jump hosts. Methodology: subdomain enumeration (passive + active), service fingerprinting, version-specific vulnerability matching against CVE / NVD, exploitation of identified weaknesses, lateral-movement testing where in-scope.
2. Internal network and Active Directory
Internal segmentation, privileged-access review, Active Directory enumeration, Kerberos and NTLM testing, BloodHound graph analysis, GPO and ACL review, ADCS escalation paths (ESC1–ESC8), Tier-0 path identification. Requires VPN access or on-site presence in your Bengaluru office.
3. Web application security
OWASP ASVS L1–L3, OWASP Top 10 2021, business-logic testing, IDOR across tenancy boundaries, race conditions, authentication and session-management edge cases, SSRF, XXE, file-upload abuse. Detailed methodology on our web application security page.
4. API security
OWASP API Top 10 (2023 edition) plus extensions for GraphQL (introspection, depth, batched queries, alias amplification, field suggestion abuse), gRPC, and SOAP/XML. Authentication, authorisation, rate-limiting, mass-assignment, and the BOLA / BOPLA classes.
5. Mobile application security
iOS and Android, MASVS L1 / L2, MASTG techniques, OWASP Mobile Top 10. Static analysis (IPA / APK reverse engineering, hardcoded secrets, obfuscation review) and dynamic analysis (Frida, Objection, runtime hooking, certificate-pinning bypass, jailbreak / root detection bypass). Methodology on our mobile application security page.
6. Cloud security configuration and posture
AWS, Azure, GCP, OCI, and DigitalOcean. CIS benchmark mapping, IAM graph analysis, privilege-escalation paths, encryption posture, S3 / Blob / Cloud Storage exposure, network security groups, secrets management, ISO 27017 control mapping for SOC 2 / ISO readiness. Methodology on our cloud security page.
Methodology — manual-led, tool-augmented
Every VAPT engagement we deliver follows the same five-phase methodology, regardless of scope type. The phases are sequential per asset but parallelised across the engagement.
Phase 1 · Reconnaissance
Passive and active information gathering. For external scope: WHOIS, DNS enumeration, subdomain discovery (Amass, Subfinder, certificate-transparency log mining), Shodan and Censys profiling, technology fingerprinting (Wappalyzer, BuiltWith), GitHub and public-bucket reconnaissance for leaked secrets. For internal scope: network sweeps, service enumeration, AD discovery via tools like AD Explorer, BloodHound ingestion.
Phase 2 · Threat modelling
Per-asset threat model written against your sequence diagrams, authentication flows, data flows. We use a STRIDE-derived approach that produces an attack-tree per critical asset, prioritising surfaces by impact-if-compromised. The threat model gates the testing plan — high-impact surfaces get more depth, low-impact surfaces get baseline coverage.
Phase 3 · Testing
The bulk of the engagement effort. Roughly 70% manual analysis by senior engineers (most findings of value are not flagged by automated tools), 30% tool-assisted using a curated stack: Burp Suite Pro, Nessus Professional, Nuclei templates, sqlmap, Frida, Objection, BloodHound, ScoutSuite, Prowler, kube-bench, and our own internal tooling. We do not run a single Nessus scan and call it a VAPT — that is what cheaper firms do.
Phase 4 · Exploitation and impact validation
For each high or critical finding, we validate exploitability under the engagement’s rules of engagement. Exploitation produces a chain of evidence (request-response captures, screenshots, terminal output, video for complex chains) that is included in the report verbatim. Theoretical findings remain in the report as such, distinguished from validated exploits.
Phase 5 · Reporting and retest
Report drafted by the lead auditor, peer-reviewed by a second senior engineer, signed by the partner. Each finding includes severity (CVSS 3.1 + business-impact narrative), reproduction steps, evidence, and remediation guidance specific to your stack. Two retest cycles included within 90 days. Final retest report stamps each finding as closed, residual, or open.
Frameworks and standards covered
Our methodology is mapped to the frameworks Indian buyers and regulators reference:
- CERT-In Audit Methodology — primary framework, mandated by empanelment
- OWASP Top 10 2021 + OWASP API Top 10 2023
- OWASP ASVS Levels 1, 2, and 3 (web application verification)
- OWASP MASVS / MASTG (mobile application)
- NIST SP 800-115 (technical guide to information security testing)
- NIST CSF 2.0 functional mapping for SOC 2 and ISO 27001 evidence
- PTES (Penetration Testing Execution Standard)
- ISSAF (Information Systems Security Assessment Framework)
- CIS Benchmarks for OS, database, cloud, and Kubernetes
- MITRE ATT&CK framework for technique coverage in red-team scope
The 4–6 week engagement roadmap
Week 0 · Scoping
One-day workshop in your Bengaluru office (or remote). We map your in-scope estate, write the rules of engagement, define exploitation limits, identify critical-asset constraints, and document point-of-contact escalation paths. Output: a written SOW that pins the scope, the price, and the timeline.
Week 1 · Reconnaissance and threat modelling
Passive recon, asset enumeration, threat models drafted for each in-scope surface. Kickoff call confirms readiness for active testing.
Weeks 2–3 · Active testing
Manual analysis layered on tool output, exploitation under rules of engagement, daily standup with your security team, immediate notification of any critical findings (we do not wait for the report to tell you about a P0 issue).
Week 4 · Reporting
Report drafted by the lead auditor, peer-reviewed, signed by the partner. Delivered as a PDF with a separate executive-summary deck for board / investor consumption.
Weeks 5–6 · Retest cycles
You remediate, we retest. Two cycles included; the final retest produces a closure report that can be attached to your SOC 2 / ISO 27001 / regulator submission.
What you receive — the report
The deliverable is a signed VAPT report (typically 60–180 pages depending on scope) plus a one-page executive summary, a finding-tracker spreadsheet for your remediation team, and a CERT-In compliant certificate of audit referencing the empanelment number. The report sections are:
- Engagement summary (scope, timeline, methodology)
- Executive summary (business-level findings narrative)
- Risk rating distribution and trend analysis
- Detailed findings (one section per finding, with reproduction, evidence, severity, and remediation)
- Remediation roadmap (prioritised by risk and effort)
- Retest results (after remediation cycles)
- Annexures (raw scan output, tool versions, PoC code where applicable)
The report is signed by the lead auditor (named, with empanelment number) and the partner overseeing the engagement. The certificate of audit is the artifact your buyer or regulator needs to see; the report is what your security team uses to actually remediate.
VAPT pricing in INR
- One web application or one mobile platform
- OWASP-aligned testing
- 2-week engagement
- Two retest cycles within 90 days
- CERT-In compliant certificate
- Web app + API + cloud config review + external network
- 4–6 week engagement
- Threat-model-led methodology
- Two retest cycles within 90 days
- CERT-In compliant certificate + report
- Web + mobile (iOS + Android) + APIs + AD + cloud + external
- 8–10 week engagement
- Red-team-style chain testing
- Three retest cycles
- Quarterly retainer option from ₹2,40,000/quarter
Top fifteen findings we report repeatedly
Across 600+ VAPT engagements over the last five years, the following findings recur often enough to be predictable. If you have not done a VAPT recently, plan to remediate against this list before kickoff — your engagement will be more useful if we are finding novel issues rather than re-confirming the obvious.
- Outdated TLS configuration (TLS 1.0/1.1 still enabled, weak ciphers in the negotiation list)
- Hardcoded secrets in mobile applications visible after IPA/APK reverse
- IDOR across tenancy boundaries in multi-tenant SaaS APIs
- Verbose error messages exposing stack traces, framework versions, internal paths
- Insufficient rate limiting on authentication and password-reset endpoints
- Server-Side Request Forgery in URL-fetch or webhook-validation features
- S3 / Blob storage misconfiguration with public read or public write
- Unrestricted file-upload with content-type bypass or path traversal
- Privilege escalation via IAM (over-permissive policies, dangerous combinations like iam:PassRole + lambda:CreateFunction)
- Kerberoastable accounts in Active Directory with weak passwords
- Plain-text secrets in CI/CD pipeline variables and Lambda environment variables
- Mass-assignment in user-update APIs allowing role escalation
- JWT misconfiguration (alg:none accepted, weak HMAC keys, missing expiry validation)
- Cross-site scripting in admin panels and customer-success tooling (often skipped from production scans)
- Vulnerable dependencies in production builds (npm / pip / maven), particularly in transitive dependencies
VAPT application by Bangalore industry vertical
Different industries put different demands on the VAPT scope. BFSI engagements are quarterly per RBI expectations and produce reports formatted for regulator submission; the test plan emphasises payment-flow security, customer-data handling, and integration security with NPCI / RBI infrastructure. SEBI-regulated entities follow CSCRF cadence (see our SEBI CSCRF page) with quarterly external testing and annual cyber-resilience drill. HealthTech engagements add PHI-specific test cases including IDOR across patient records and clinical-data exposure paths. Government and PSU engagements run under specific tender requirements and produce reports formatted per CERT-In’s submission expectations. SaaS engagements typically integrate with SOC 2 / ISO 27001 evidence cycles and produce a deliverable acceptable for both audit and buyer-side vendor security review.
How VAPT fits with your other security investments
A VAPT engagement is one component of a mature security programme. It is not a substitute for a SAST / DAST / SCA toolchain in CI, not a substitute for a security-engineering function, and not a substitute for the incident-response retainer that handles the day a real attacker succeeds. Each plays a different role. Tooling in CI catches issues early in the development cycle, where remediation is cheap; the security-engineering function maintains the day-to-day controls; the IR retainer handles the events the prevention layers miss; the VAPT engagement is the periodic external validation that everything is working as intended. We design our engagements to fit alongside the rest of your programme rather than to replace any of it; the report explicitly identifies which findings indicate gaps in tooling, which indicate gaps in process, and which indicate gaps in architecture, so the remediation work goes to the right team.
Evaluating a VAPT vendor in Bangalore — six questions
The Bangalore VAPT vendor population is large and uneven. The questions below separate substantive vendors during procurement.
1. Empanelment status: CERT-In empanelment with current validity; verifiable on the CERT-In list. 2. Manual-effort percentage: what fraction of the engagement is manual analysis vs automated scanning? Vendors quoting more than 50% automated are typically running a tool-output rebrand. We are 70% manual; we will publish the breakdown for any engagement. 3. Senior-engineer ratio: how many senior engineers (5+ years application security) work on the engagement? Vendors quoting "a team" without specifying seniority are typically staffing junior. 4. Retest cycles included: how many retest cycles within the SOW? "Retests are billed separately" is a soft signal that the vendor expects to find issues you cannot remediate inside one cycle. 5. Sample report: ask for a sample anonymised report. Reports light on reproduction steps, light on architectural recommendations, or formatted as severity-ranked checklists rather than narrative findings indicate generic delivery. 6. Pricing transparency: can the vendor publish pricing? Will they fix it in writing? Vendors that decline both are pricing for negotiation rather than for delivery.
We answer all six specifically and in writing during scoping.
To start a VAPT engagement, the next step is a thirty-minute scoping call. You leave the call with a written SOW, a fixed price in INR, and a kickoff date. Most engagements begin within five business days.