Red Teaming Under the RBI's 2026 Directions

Whether an Indian regulator requires a red team is a question most vendors answer in the direction that suits them. The text is public, and it settles the question in one word.

In the RBI's 2026 cyber security Directions, red teaming appears as something a regulated entity may undertake, not something it shall. Paragraph 162 of the commercial banks instrument is the provision, and proposals that present it as an obligation are misreading it.

There are six instruments, not one

On 31 July 2026 the Reserve Bank repealed 628 circulars and issued 64 consolidated Directions in their place. Six of them cover cyber security, one for each entity class, and all six commenced on issuance with no transition period:

• commercial banks, reference RBI/DoS/2026-27/410
• small finance banks
• payments banks
• urban co-operative banks
• NBFCs
• credit information companies

This matters before anything else, because a paragraph number is only meaningful against the instrument it sits in. A vendor citing "the RBI Directions" without saying which one is citing six documents at once.

What the six say about red teaming, entity by entity

The comparison is short, and it is the part nobody else publishes.

Four instruments make it permissive. Two do not raise it at all. No instrument sets a red-team frequency, and none of the six establishes a supervised threat-led testing programme of the kind some other jurisdictions run.

Nor is this new. The 2016 Cyber Security Framework said the same thing at Annex 1, section 18.5: red teams may be used. That framework was repealed on 31 July 2026, so it is no longer the instrument to cite, but the wording matters for one reason. Red teaming has been permissive under RBI cyber security policy for a decade, and nothing in 2026 tightened it.

What is genuinely mandatory

The Directions are prescriptive about routine testing and permissive about adversarial exercises. The difference is where the calendar obligations sit.

Paragraph 151 sets the cadence: vulnerability assessment at least once every six months, and penetration testing at least once every twelve months. Two intervals, not one. An entity running a single annual exercise and calling it VAPT satisfies the penetration testing leg and misses the vulnerability assessment leg by a factor of two.

The same paragraph draws the scope, and the test is disjunctive. It reaches systems that are critical and / or sit in the DMZ with a customer interface. Either limb on its own brings a system in, which is wider than the reading most scoping conversations start from.

Paragraph 150 extends testing across the lifecycle: pre-implementation, post-implementation and after changes, with test-environment deviations documented and approved. Paragraph 154 requires the documented VA and PT approach, covering scope, coverage and CVSS-type scoring, to apply to cloud-hosted systems as well. In the 2023 Master Direction that provision said "may". It now says "shall", which is the cleanest checkable change in the instrument.

Security Brigade maintains the paragraph-level reading, including which entity types each Direction binds: red teaming requirements and the RBI Directions, 2026.

Why "may" still matters

A permissive provision still carries weight. Three practical consequences.

Supervisory expectation runs ahead of the text. What a regulator expects of a large, systemically important entity is more than the minimum wording requires of everyone. A bank of a certain size explaining that it has never tested detection because paragraph 162 said "may" is arguing about wording and leaving the risk unanswered.

The mandatory testing has a ceiling. Vulnerability assessment and penetration testing establish what is broken. Neither shows whether anyone would notice an intruder who got past them, and keeping to the paragraph 151 intervals does not answer that question. Paragraph 182 requires cyber incidents to be reported on the DAKSH platform within six hours of detection, and six hours is a rehearsal problem before it is a policy problem. An entity that has never exercised detection discovers its actual response time during the incident.

It shapes what to buy first. Because it is permissive, a red team stops being a compliance line item and becomes a risk decision. Buy it when it will change something. If your penetration tests still surface unpatched hosts, that is where the money belongs, and the sequencing argument is in purple team: when it beats a red team.

What the Directions do require, about whoever tests you

This is the part that changes procurement, and it is easy to miss because it sits away from the testing paragraphs. Of 233 paragraphs, three are about the firm doing the work, and they are identical across all six instruments.

Paragraph 156 requires the credentials and competency of the testing firm, and of the personnel it assigns, to be established at every selection, appointment, engagement and renewal. Not once at onboarding. Every time. Paragraph 157 requires explicit assurance for each area assessed, stated in the report instead of implied by its absence. Paragraph 158 is the one nobody is discussing: it addresses what follows when something is missed, which is a question to put to a prospective auditor before the engagement, not after a breach.

Paragraph 159 provides that where a CERT-In empanelled auditor is engaged, CERT-In's audit policy guidelines come into the supervisory relationship. That is a reason to care who holds empanelment, and it is separate from the question of what the testing covers.

Threat-led penetration testing, and which meaning is intended

Threat-led penetration testing is the term to watch, because it is used two ways and the gap between them is wide.

In several jurisdictions it names a defined, supervised programme with prescribed threat intelligence, prescribed scoping and the regulator in the room. Elsewhere it is a marketing label for an intelligence-informed red team. Neither usage is dishonest on its own, and a proposal that does not say which one it means is unusable. Three questions settle it: which named framework, who produces the threat intelligence, and whether a supervisor has been told the exercise is happening. The full comparison is in what TLPT actually means.

For SEBI-regulated entities the position is set by a different instrument entirely, and red teaming and SEBI CSCRF covers it.

Reading a vendor's compliance claim

Two questions settle most of it.

• Which instrument, and which paragraph? A claim that cannot be pinned to a citation is marketing. All six Directions are public.
• Does the claim say "shall" where the instrument says "may"? If a proposal tells you red teaming is mandatory under the 2026 Directions, that is a statement you can check against paragraph 162, and it is wrong.

The same discipline applies to who may perform the work. Every Indian regulator that accepts an audit report accepts it from a CERT-In empanelled auditor, so empanelment is a precondition to establish at scoping, and it attaches to the firm for a defined period instead of to any single report. The practical question a supervisor asks is a question about dates: whether the firm held empanelment on the days the work was performed. Security Brigade has been CERT-In empanelled continuously since 2008.

If you are deciding what to commission, choosing a red team provider sets out what to ask, and what a red team engagement costs covers what moves the price.