VAPT cycle — vulnerability assessment and penetration testing programme
Primary statement
VAPT cycle operates as: (1) Vulnerability Assessment + Penetration Testing after every major release (SEBI PR.4 — new feature, significant change, circular implementation, infrastructure migration); (2) periodic VAPT per criticality (RBI ITGRCA RM.3 — quarterly critical, annual important); (3) application security including secure SDLC integration (RBI PR.6); (4) API security across the API lifecycle with threat protection, testing, lifecycle management (RBI PR.27); (5) asset inventory underlying scoping (SEBI ID.1); (6) cryptographic key management VAPT scope (SEBI PR.8); (7) cyber resilience metrics integration (RBI GV.6).
Audit-fatigue payoff
A unified VAPT cycle — release-triggered + periodic-by-criticality + API-specific + cloud-specific — satisfies VAPT requirements across all 10 contributing frameworks. SEBI PR.4 release-trigger + RBI ITGRCA RM.3 periodic cadence + RBI PR.27 API-specific testing form the audit-defensible cycle.
Strictness matrix
Scope
Scope: VAPT after every major release (new feature, significant change, SEBI circular implementation, infrastructure migration). Release-triggered scope is the broadest VAPT trigger model — most frameworks specify periodic cadence only.
Ceiling source: sebi_cscrf:CSCRF.PR.4
Rationale: SEBI CSCRF PR.4 release-triggered VAPT is the strictest scope. Other frameworks specify periodic VAPT without release triggers.
Threshold
Threshold for API security testing: API-specific testing across the API lifecycle — design, build, deploy, operate, retire. Threat protection (rate limiting, schema validation, anomaly detection). Reflects the expansion of API-driven banking (UPI, Account Aggregator, ONDC, open banking).
Ceiling source: rbi_csf:RBI.PR.27
Rationale: RBI CSF PR.27 API-specific testing is uniquely strict for financial services where API is the new perimeter.
Method
Method: (1) VAPT scope based on asset inventory (SEBI ID.1); (2) release-triggered VAPT (SEBI PR.4); (3) periodic VAPT per criticality (RBI ITGRCA RM.3 — quarterly critical, annual important); (4) API-specific testing across API lifecycle (RBI PR.27); (5) integration with secure SDLC pre-production review (RBI PR.6); (6) cryptographic key management testing scope (SEBI PR.8); (7) manual penetration testing (not just automated scanning); (8) CERT-In empanelled testing firm for sectoral assurance.
Ceiling source: sebi_cscrf:CSCRF.PR.4
Rationale: SEBI CSCRF PR.4 with the release-trigger combined with RBI ITGRCA RM.3 periodic cadence and RBI PR.27 API specifics is the most prescriptive method.
Frequency
VAPT cadence: quarterly for critical systems, annual for important, ad-hoc for material change (RBI ITGRCA RM.3). Release-triggered VAPT additionally per SEBI PR.4. API security testing across the lifecycle (continuous via pipeline + periodic deeper testing per release).
Ceiling source: rbi_itgrca:ITGRCA.RM.3
Rationale: RBI ITGRCA RM.3 quarterly-critical cadence is the strictest periodic frequency. Combined with SEBI PR.4 release trigger, this is the audit-defensible cycle.
Evidence
Required evidence: (1) VAPT programme document with scope, cadence, methodology; (2) recent VAPT reports per cycle (release-triggered + periodic) with manual-test evidence; (3) CERT-In empanelment certificate of testing firm; (4) findings closure with re-test evidence; (5) API security testing evidence (RBI PR.27); (6) asset inventory underlying scoping (SEBI ID.1); (7) integration with cyber resilience metrics (RBI GV.6).
Ceiling source: rbi_itgrca:ITGRCA.RM.3
Rationale: RBI ITGRCA RM.3 evidence is comprehensive. The manual-test-evidence + CERT-In empanelment + release-triggered evidence are uniquely strict.
Auditor test pattern
Step 1: Inspect the VAPT programme document. Step 2: Verify CERT-In empanelment of the testing firm. Step 3: Sample 1 recent major release; verify release-triggered VAPT was performed. Step 4: For Maturity Level 4 banks, verify API security testing evidence (RBI PR.27). Step 5: Sample 1 critical system; verify quarterly periodic VAPT cadence. Step 6: Verify findings closure with re-test evidence. Step 7: Inspect manual-test evidence (not just automated scan output).
Common findings
Common 2024–26 findings: (1) Release-triggered VAPT skipped under release pressure; (2) Automated scanning passed off as penetration testing; (3) CERT-In empanelment of firm but not specific testing team — credentialing gap; (4) API security testing absent despite API-driven product launch; (5) Findings closed by self-attestation without re-test; (6) Critical systems VAPT cadence annual, not quarterly per ITGRCA RM.3.