Skip to main content
Compliance Services

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.

By Security Brigade Editorial Team
August 9, 20266 min read
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:

  1. The paragraph 151 population, 61 systems, each with the recorded basis for inclusion and the date it entered scope.
  2. Cadence status against the clock: VA and PT due and completed, next due date per system.
  3. Open findings by severity and age, each against its paragraph 153 time-bound commitment.
  4. Closure evidence, split into verified by retest and asserted by the owner.
  5. Recurrence: any CVE-class issue reappearing after a previous closure.
  6. Paragraph 152 deviations, with ISC approval references.
  7. Paragraph 150 lifecycle triggers fired in the quarter.
  8. 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