Case Study: Moving a Commercial Bank from Annual Testing to the Paragraph 151 Cadence
A commercial bank running annual point-in-time VAPT re-scoped to the RBI Directions, 2026 — six-monthly vulnerability assessment, production-environment testing, cloud in scope, and a quarterly closure pack for the ITSC and ISC that did not previously exist as an artefact.
On this page (6)
The bank had run the same programme for six years. One annual penetration test, a six-week window, a report in March, a remediation plan, and the next kickoff the following January. On 31 July 2026 the gap stopped being a matter of supervisory judgement and became a numbered paragraph. The Reserve Bank of India (Commercial Banks — Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 (RBI/DoS/2026-27/410) commenced immediately on issuance, with no glide path anywhere in the text. Paragraph 151 puts vulnerability assessment on a six-monthly clock and penetration testing on a twelve-monthly one. The next IT Strategy Committee meeting was eleven weeks away, and paragraph 161 required a closure-status pack for that committee and for the Information Security Committee that had never existed as a document.
Median time from a finding being raised to closure being independently verified: 214 days under the annual programme, 38 days by the end of the second quarter on the paragraph 151 cadence.
The starting position
The old programme was built against the 2016 Cybersecurity Framework's annual rhythm and never re-cut when the 2023 Master Direction put VA on a six-month clock at §26(a). Paragraph 151 carries that cadence forward word for word — what changed is that it now sits in a numbered operative Direction with a quarterly committee report attached, not in guidance a programme could drift past. What it could not do was answer, on demand, the four questions the 2026 Directions ask. Which systems are in scope under paragraph 151, and on what recorded basis under paragraph 154's documented approach. When each was last tested against the clock (paragraph 151). What is open, how old it is, and whether the fix was verified rather than asserted (paragraphs 153 and 160). And who has been told (paragraph 161). The annual report answered all four once a year, in March.
Scoping: what "critical and / or DMZ having customer interface" actually catches
Paragraph 151 is disjunctive. It reads "For critical information systems and / or those in the DMZ having customer interface". Either limb triggers the cadence on its own. A critical system that is not internet-facing is in scope; a customer-facing DMZ system the bank does not rate critical is also in scope. Most scoping conversations start from the wrong assumption that both conditions must hold.
We ran the scope against the bank's own asset inventory under paragraph 47, which already indicated business criticality and which the bank was permitted to build on its own criteria. Of 140 systems in the inventory, 61 landed in the paragraph 151 population. The remainder went onto the risk-based track that the second sentence of paragraph 151 provides for non-critical systems, with the periodicity written down rather than left implicit.
Two categories moved that the bank had not expected. Nine cloud workloads came in under paragraph 154, which states that the documented VA/PT approach "shall also apply to the bank's information systems hosted in a cloud environment". The equivalent sentence in the 2023 Master Direction said "may", and the bank's previous scope statement had excluded those workloads as provider responsibility. That one word is the cleanest delta in the instrument.
Post-implementation testing also moved out of UAT — not because paragraph 152 is new (it carries the 2023 Master Direction §26(d) wording forward) but because nothing in the old programme had ever been audited against it. Paragraph 152 requires the test to run on the production environment; where it genuinely cannot, the bank shall ensure the test environment's version and configuration resemble production, and any deviation should be documented and approved by the ISC. In the first two quarters, 3 of 17 post-implementation tests ran in a test environment, each carrying a version and configuration comparison and an ISC approval reference.
Paragraph 150 supplied the third trigger: lifecycle VA/PT of critical, internet-facing web and mobile applications, servers and network components, pre-implementation, post-implementation and after changes. The programme stopped being a calendar and became a calendar plus a release hook.
Retest discipline, because paragraph 158 moves the risk
Paragraph 158 is the sentence nobody in the market is discussing. If a tested system is later compromised through a vulnerability that was not observed or highlighted on a timely basis in the VA/PT, that "will qualify as a deficiency in discharge of function by the VA / PT auditor", and it must be factored in at selection and renewal.
That reshapes the engagement. A finding closed on the strength of a ticket update is a finding neither party can defend. Every critical and high finding is retested against the live system, and the pack separates closed-and-verified from closed-on-assertion. Paragraph 153's requirement to sustain compliance and avoid recurrence of known CVEs is checked at each six-month cycle rather than assumed.
Paragraph 156 is the other half. At every selection, appointment, engagement or renewal, the bank must consider qualification, professional expertise, credentials and competency of the firm and of the audit personnel engaged. Security Brigade has been CERT-In empanelled continuously since 2008, and paragraph 159 imports CERT-In's Comprehensive Cyber Security Audit Policy Guidelines into the supervisory relationship once an empanelled auditor is engaged. Named auditor identity, designation and credentials went into the engagement file at kickoff, not when a supervisor asked.
The report had to be rebuilt for paragraph 157
Paragraph 157 requires the bank to review coverage and scope and ensure that "reasonable assurance for each of the areas therein shall be provided explicitly in the VA / PT audit reports", with that requirement stated at the time of empanelling or awarding the contract.
The standard Indian report format lists findings and leaves assurance to be inferred from their absence. Under paragraph 157, an area with no findings must carry an explicit assurance statement of its own. The bank specified the format it needed at award rather than discovering the gap at report time: every agreed area — authentication, session management, authorisation, business logic, API surface, cloud configuration, network segment — to carry its own assurance line, the tests supporting it, and the coverage limits qualifying it. That is a procurement decision available to any bank reading paragraph 157, and the earlier it is made the cheaper it is.
What the first quarterly pack contained
Paragraph 161 asks for one thing: the status of closure of VA/PT observations, to the ITSC and ISC, at least quarterly. The bank had no template. Eight sections, four pages, identical every quarter:
- The paragraph 151 population, 61 systems, each with the recorded basis for inclusion and the date it entered scope.
- Cadence status against the clock: VA and PT due and completed, next due date per system.
- Open findings by severity and age, each against its paragraph 153 time-bound commitment.
- Closure evidence, split into verified by retest and asserted by the owner.
- Recurrence: any CVE-class issue reappearing after a previous closure.
- Paragraph 152 deviations, with ISC approval references.
- Paragraph 150 lifecycle triggers fired in the quarter.
- Cloud systems in scope under paragraph 154.
The value of paragraph 161 is not the reporting. It is that a committee seeing the same eight rows every ninety days notices an ageing finding long before an examiner does.
What moved
214 days to 38 did not come from testing harder. It came from a scope written down, a clock external to the bank, a retest that has to happen before anything is called closed, and a committee that sees the position four times a year instead of once.
Chapter VI monitoring stayed with the bank's own provider. Paragraph 223 expressly permits managed-service arrangements for the CSOC, and the VA/PT programme feeds that function rather than substituting for it.
The bank's internal documents still call this the RBI cybersecurity framework. The instrument that governs it now is the 2026 Directions: 233 numbered operative paragraphs where there used to be an annex describing itself as indicative. Security Brigade has been CERT-In empanelled since 2008, with 6,700+ assessments delivered for 1,000+ clients.
About the author
Security Brigade Editorial Team
Continue reading
All articles →ATM Switch and CBS Providers: The Controls Your Bank Customers Must Now Impose on You
Four of the six RBI Directions require banks to impose named cybersecurity controls on their ATM Switch and core banking service providers by contract — 24 of them for commercial banks, 37 for urban co-operative banks. The obligation flows down even where it does not sit at the top.
Foreign Bank Branches and Comply-or-Explain: What Paragraph 4 Actually Buys You
The RBI Directions, 2026 contain exactly one comply-or-explain device, and it applies only to foreign banks operating in India through branch mode. It covers four chapters and sixteen named paragraph groups — and it is a relaxation subject to RBI accepting your explanation, not an exemption.
RBI Cybersecurity Directions for Small Finance Banks, Payments Banks and Credit Information Companies
Three entity types, three instruments, no internal tiering — which means the full baseline binds from day one. SFBs and payments banks are expressly carved out of the commercial banks Direction, which confuses people who assume it covers them.