VAPT Case Study India: Pre-IPO Engagement for a Consumer-Lending NBFC
VAPT case study from India for a pre-IPO NBFC — 90 days to RBI's technical inspection, "no surprises" was the brief. Three months to a regulatory deadline, a complex loan origination stack, and "no surprises" as the success criterion.
The VAPT Case Study Challenge
“No surprises” was the tightest constraint. RBI’s technical inspection includes a VAPT report review; if a critical finding lands a week before inspection and cannot be fixed in time, the whole inspection slips. The engagement therefore had to surface high-severity issues fast and pace the rest so the dev team could fix in parallel with continued testing.
The platform was also non-trivial: a customer-facing React app, a loan-officer admin app, nine GraphQL and REST backends, three third-party integrations (CIBIL, Aadhaar e-KYC, payment gateway), and Kafka pipelines feeding their underwriting model.
Our VAPT Case Study India Approach
We split the engagement into three parallel work-streams to compress wall-clock time:
- Stream A — external web + customer app. Authenticated grey-box, two testers.
- Stream B — internal/admin app + API. Authenticated grey-box, one tester.
- Stream C — internal network + AD. Assumed-breach scenario from a corporate laptop.
We pushed every confirmed high-severity finding to the dev team within 24 hours of confirmation — the formal report came at the end, but they were not waiting on it to start fixing.
What We Built Beyond This VAPT Case Study India
Beyond the VAPT itself, we contributed three operational artefacts the client kept:
- A reusable scope document and ROE template — they will run two more VAPT cycles per year going forward.
- An API security testing checklist that the QA team integrated into their CI pipeline (basic auth/auth tests, rate limit asserts).
- A short runbook for the SOC team on how to recognise post-exploitation traffic patterns we had used during testing.
VAPT Case Study India Outcomes
- 23 valid findings — 3 critical (one IDOR exposing other borrowers’ loan documents, one server-side request forgery, one stored XSS in admin app), 8 high, 12 medium.
- All findings remediated within 6 weeks of report; retest confirmed closure on every item.
- RBI inspection cleared with no IT findings related to platform security.
- Engineering culture shift — security review became a release-gate item from then on.
What We'd Do Differently
The biggest miss was on our side, not theirs. We did not loop in the dev team’s tech lead until the kickoff call — by then the engagement plan was already shaped around the platform owner’s mental model. The first three days, our findings were going through one extra layer of translation. On the next NBFC engagement we ran, we made tech-lead participation a non-negotiable kickoff requirement; that engagement closed two weeks faster for the same scope.
We also under-scoped the third-party integration testing initially. The Aadhaar e-KYC flow had subtle logic flaws that only surfaced after four hours of black-box exploration. We added a buffer for “third-party trust boundary” testing on subsequent engagements.
Stack & Tools
- Burp Suite Pro, Caido for parallel proxying
- Custom GraphQL fuzzers,
nuclei,ffuf - Nessus Pro for network sweep, Impacket for AD post-exploitation
- Postman + Bruno for API exploration
- Dradis for evidence aggregation, our internal Markdown report templates
FAQ
Was this a CERT-In empanelled engagement?
Methodology aligned with CERT-In requirements; the lead tester was empanelled. For NBFCs subject to specific RBI directives, we route the engagement through our empanelled-auditor framework and produce the inspection-ready report format.
How long was the formal report?
74 pages including the executive summary, finding-by-finding technical detail with reproduction steps, CVSS v3.1 vector strings, and the retest evidence appendix. The executive summary was 3 pages — the part the board actually read.
Did the critical IDOR allow you to actually access another customer's data?
We confirmed it on test accounts only. The platform owner had set up two seeded test borrowers with documents we were authorised to access; we used those throughout. We did not enumerate real borrower IDs at any point — it was not necessary to demonstrate impact.
What was the most common finding category?
Authorisation flaws — IDOR variants and missing object-level access checks. This is consistent across most NBFC platforms we have tested; auth correctness gets harder to maintain as products grow product features faster than test coverage.
Why This VAPT Case Study India Pattern Repeats
This VAPT case study India is one of several pre-IPO and pre-RBI engagements we have delivered with a similar pattern: short window, high stakes, zero tolerance for surprises. The VAPT case study India playbook — three parallel streams, 24-hour finding push to dev, ASVS-aligned methodology — works because it compresses wall-clock time without sacrificing depth. Indian regulated entities planning a VAPT case study India engagement should expect the same shape: scoped weeks, dev-team-embedded, regulator-ready report. The deliverable is the inspection-pass, not the page count.
Further reading: VITI Security cybersecurity services · CERT-In national cybersecurity authority.
Need help on something like this? VITI Security works with operators, BPOs, and SMBs across India and abroad.
Request a Scoping Call
