RBI VAPT Requirements in 2026: Six Months, Twelve Months, and What "Critical and/or DMZ" Means

If your RBI VAPT calendar has one entry on it, it is wrong by a factor of two. Paragraph 151 of the RBI (Commercial Banks — Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 requires vulnerability assessment **at least once in every six months** and penetration testing **at least once in 12 months** for critical information systems and / or those in the DMZ having customer interface. That instrument, RBI/DoS/2026-27/410, was issued on 31 July 2026 and came into effect immediately upon issuance. So did its five siblings. There is no glide path, no phased commencement and no "with effect from" date anywhere in the set.

The six-monthly VA requirement is not new — it carried forward almost verbatim from the 2023 Master Direction on IT Governance, Risk, Controls and Assurance Practices. What is new is that it now sits in a single consolidated Direction written for your entity type. From 2016 to July 2026 two instruments ran in parallel — the 2016 Cybersecurity Framework, whose baseline control catalogue described itself as indicative but not exhaustive, and the 2023 Master Direction, which never repealed it. That ambiguity is gone. The annual-VAPT line is everywhere — in RFP templates, compliance calendars and vendor datasheets across the market. Para 151 ends the argument.

Here is what the paragraph actually says, and how a bank works out which systems it covers.

## The two clocks, and the paragraph number for your instrument

RBI issued six entity-specific Directions on 31 July 2026, not one circular. The VA/PT obligation appears in all of them, at a different paragraph number in each. Citing the wrong one in a Board note is the fastest way to lose an argument with your auditor.

| Entity | Instrument | VA/PT paragraph | Cadence |
|---|---|---|---|
| Commercial banks | RBI/DoS/2026-27/410 | para 151 | VA 6-monthly, PT 12-monthly |
| Small finance banks | /419 | para 150 | VA 6-monthly, PT 12-monthly |
| Payments banks | /428 | para 150 | VA 6-monthly, PT 12-monthly |
| Credit information companies | /470 | para 146 | VA 6-monthly, PT 12-monthly |
| NBFCs (Middle, Upper and Top Layer) | /461 | para 121 | VA 6-monthly, PT 12-monthly |
| Urban co-operative banks (Level II and above) | /437 | para 116 | VA of critical applications and those on DMZ 6-monthly; PT at least once a year |

Two scoping notes that decide whether the row above applies to you at all. NBFC obligations are allocated by SBR layer under para 3: Chapter III alone for Base Layer NBFCs below ₹500 crore and for Core Investment Companies, Chapter IV for Base Layer at or above ₹500 crore, Chapter V for Middle, Upper and Top Layer excluding CICs. Para 121 sits in Chapter V. UCB obligations are allocated by four Levels of digital depth under para 4, not by asset size. Level II is a UCB that is a sub-member of Centralised Payment Systems and satisfies at least one of: internet banking (view or transactional), a mobile banking app, or direct CTS / IMPS / UPI membership. Level III adds direct CPS membership, an own ATM Switch, or a SWIFT interface. Para 116 sits in Chapter IV, so the VA/PT duty begins at Level II.

And note that "CIC" means two different things across the set. In /461 it is Core Investment Company. In /470 it is Credit Information Company. Different populations, different obligations.

## "Critical and / or DMZ" is disjunctive

This is the phrase that most scoping exercises get wrong, and the error runs in the direction that leaves systems untested.

Para 151 reads: "For critical information systems **and / or** those in the DMZ having customer interface". That is a union, not an intersection. A system is in scope if it is critical. A system is also in scope if it sits in the DMZ with a customer interface. It does not have to be both.

The practical consequence is that internet-facing systems nobody has classified as critical are still in scope. A customer-facing marketing microsite that takes lead-form data, a loan-application portal that has not yet been added to the criticality register, a partner API published through the DMZ — each is caught by the second limb on its own. RBI defines the DMZ at CB para 5(12), adopting NIST SP 800-82 Rev. 2: a perimeter network segment logically between internal and external networks.

Everything outside both limbs still gets tested. The second sentence of para 151 requires a risk-based approach to decide the requirement and periodicity of VA/PT for non-critical information systems. "Not critical" is a decision you document, not an exemption you assume.

## Lifecycle testing is a separate obligation, not the same clock

The six-month and twelve-month intervals are floors on periodic testing. Para 150 imposes a second, event-driven duty: the bank shall periodically conduct VA/PT of critical, internet-facing web and mobile applications, servers and network components **throughout their lifecycle including pre-implementation, post-implementation, and after changes**.

Siblings: SFB para 149, PB para 149, CIC para 145, NBFC para 121 (second sentence), UCB para 116. UCB para 115 adds application security testing of web and mobile applications before going live and after every major change.

A bank shipping fortnightly releases against a six-monthly test cycle satisfies para 151 and fails para 150. The two paragraphs have to be run as one programme: a periodic baseline on the calendar, plus release-gated testing on the change pipeline.

## Production, not test — and the one deviation route

para 152 is explicit. In the post-implementation scenario, VA/PT **shall be performed on the production environment**. Where unavoidable circumstances force PT into a test environment, the bank must ensure the version and configuration of that environment resembles production, and para 152 provides that any deviation should be documented and approved by the Information Security Committee. The NBFC instrument is stricter on exactly this point: para 124 makes that documentation and ISC approval a "shall".

That is a named committee with a minuted decision, not an engineering judgement call. If your standing practice is to test in UAT because production testing is inconvenient, you now need an ISC approval on the file for it — every time. Siblings: SFB para 151, PB para 151, CIC para 147, NBFC para 124.

## Fixing is timed, and CVE recurrence is a finding

para 153 requires the bank to fix identified vulnerabilities and associated risks **in a time-bound manner** and to ensure that compliance is sustained to avoid recurrence of known vulnerabilities such as those in the CVE database. Siblings: SFB para 152, PB para 152, CIC para 148, NBFC para 125. The UCB instrument is looser here — para 118 requires only that detected vulnerabilities be remediated promptly in terms of the UCB's own risk treatment framework, with no time-bound wording and no CVE-recurrence limb.

Read the second half carefully. A vulnerability that was closed and has come back is not a fresh finding, it is evidence that remediation was not sustained. Retest discipline and configuration drift control are what this paragraph buys.

## Cloud moved from "may" to "shall"

If you want a single checkable delta between the old regime and the new one, this is it.

Para 154 requires a documented approach for the conduct of VA/PT covering scope, coverage, a vulnerability scoring mechanism such as CVSS, and all other aspects — and then: "This **shall** also apply to the bank's information systems hosted in a cloud environment."

The 2023 Master Direction said the documented approach **may** also apply to cloud-hosted systems. One word changed, and with it every workload a bank has moved to a hyperscaler since 2023 comes inside a mandatory testing regime with a written methodology behind it. Siblings: SFB para 153, PB para 153, CIC para 149, NBFC para 126. The UCB instrument carries no cloud counterpart.

## Quarterly closure to the ITSC and the ISC

para 161 requires that the status of closure of VA/PT observations be put to the **IT Strategy Committee and the Information Security Committee at least on a quarterly basis**. Siblings: SFB para 160, PB para 160, CIC para 156. The NBFC and UCB instruments do not carry this paragraph.

This is a new artefact on a new cadence. Testing twice a year and reporting four times a year means two of every four quarterly packs report on remediation progress against findings raised in an earlier quarter. If your VA/PT reports arrive as PDFs with no closure-tracking structure behind them, that pack is currently being assembled by hand.

## A worked scoping example

A mid-sized private bank runs 380 applications. The scoping conversation, in the order para 151 forces it:

1. **Pull the inventory.** para 47 requires an up-to-date inventory of information assets including business and customer data, applications, supporting IT infrastructure, key personnel and facilities, indicating business criticality. Para 47 also confirms the bank may use its own criteria for identifying critical assets — so write the criteria down: para 154 requires the documented VA/PT approach to cover scope and coverage, and your criticality criteria are what that scope rests on.
2. **Apply limb one.** Core banking, the payment switch, treasury, the data warehouse holding customer data, the identity provider, the card management system. Say 46 applications. In scope, along with the infrastructure supporting them.
3. **Apply limb two, independently.** Everything in the DMZ with a customer interface: internet banking, the mobile banking backend, the UPI-facing services, the loan origination portal, the customer chat gateway, the open partner APIs, the grievance portal, the account-opening microsite. Say 31 systems, of which 22 already appeared in step 2. Nine new systems, and typically it is the last three in that list that nobody had classified.
4. **Union, not intersection.** 46 + 9 = 55 systems on the para 151 clock. VA every six months, PT every twelve.
5. **Cloud does not reduce the number.** para 154 applies the documented approach to cloud-hosted systems as a "shall". Systems in step 2 or 3 that happen to run on AWS or Azure stay in, and the cloud configuration and identity layer comes in with them.
6. **The remaining 325 get a documented risk-based decision** under the second sentence of para 151 — with periodicity recorded, not omitted.
7. **Overlay para 150** on the release calendar for the internet-facing subset, and route any test-environment PT through the ISC under para 152.

That is the whole method. In practice limb two is where the additions come from, and they are almost all internet-facing.

## Who is allowed to do the testing

para 155 requires VA/PT to be conducted by appropriately trained and independent information security experts or auditors. Para 156 is where the procurement work moved: at the time of selecting, appointing, engaging **or renewing** the contract, the bank shall consider requisite qualification, professional expertise **of the firm as well as the audit personnel engaged**, appropriate credentials and suitable competency. Firm-level and named-individual credentials, evidenced at every renewal.

CERT-In empanelment is how banks evidence that, and para 159 makes the point directly: where the bank engages CERT-In empanelled auditors, it shall be guided by CERT-In's Comprehensive Cyber Security Audit Policy Guidelines. Engaging an empanelled firm imports a defined audit-policy regime that the bank is then supervised against, rather than leaving competency as an assertion in a proposal document.

Two more paragraphs belong in your next RFP. Para 157 requires that reasonable assurance **for each of the areas** covered be provided **explicitly** in the VA/PT report, and that this be stated at the time of empanelling or awarding the contract — so put the report format in the contract, not in the kick-off call. Para 158 provides that a system which was subjected to VA/PT and is later compromised, apparently due to vulnerabilities not observed or highlighted on a timely basis, **will qualify as a deficiency in discharge of function by the VA/PT auditor**, to be factored in at selection and renewal. Your testing partner now carries a documented performance record that follows them into every renewal conversation.

Separately, and worth stating because the market is confusing the two: red teaming is permissive, not mandatory. CB para 162, SFB para 161, PB para 161 and CIC para 157 all say the entity **may** conduct red teaming exercises. The UCB and NBFC instruments do not mention red teaming at all. Para 151 is a "shall". Para 162 is not. Do not let a vendor sell you the second by citing the first.

## Where to start

The RBI cybersecurity framework did not become more demanding on 31 July 2026 so much as it became enforceable, paragraph by numbered paragraph, per entity type, with immediate effect. The gap most banks will find is not the six-month interval. It is the nine internet-facing systems that limb two catches, the cloud estate that moved from "may" to "shall", and the quarterly closure pack that nothing currently produces.

Security Brigade has been CERT-In empanelled continuously since 2008 — Security Brigade has been CERT-In empanelled continuously since 2008 and has delivered over 6,700 assessments for more than 1,000 clients — and has delivered over 6,700 assessments for more than 1,000 clients, including scheduled commercial banks, NBFCs, payment institutions and co-operative banks. We scope RBI VA/PT programmes to the paragraph that applies to your instrument, run the six-month and twelve-month cadence alongside release-gated lifecycle testing under para 150, cover cloud-hosted systems under para 154, and deliver findings in a structure your ITSC and ISC can take straight into the quarterly para 161 review.

If you want to know how many systems limb two adds to your scope, that is a two-hour conversation with your asset inventory open. Talk to our team about scoping a programme to this cadence..