Foreign Bank Branches and Comply-or-Explain: What Paragraph 4 Actually Buys You

On 31 July 2026 the Reserve Bank's Department of Supervision replaced a decade of cybersecurity circulars with six entity-specific Directions, every one of them in force from the moment of issuance. There is no glide path in any of them, and there is exactly one comply-or-explain device in the entire family. The UCB and NBFC instruments do scope by Level and by layer respectively, but that is graduated applicability — which chapters reach you at all — not a right to deviate from what does. It runs to a single paragraph, and it belongs to you.

Search the Small Finance Banks, Payments Banks, Urban Co-operative Banks, NBFC and Credit Information Company instruments for the phrase "comply or explain" and you will find nothing. 'It appears in exactly one instrument — paragraph 4 of the Commercial Banks Directions, RBI/DoS/2026-27/410 — and it addresses foreign banks operating in India through branch mode.' No other regulated population got one.

Which makes para 4 worth reading precisely, because it is considerably narrower than its reputation is about to become.

What para 4 actually says

Two limbs.

The first is definitional and it solves the obvious problem: reference to the Board or Board of Directors in these Directions "should be read as reference to the controlling office / head office which has the oversight over the branch operations in India". No India-incorporated board is required. Board-addressed obligations attach upward.

The second is the relaxation proper. Such a foreign bank "shall be subject to a 'comply or explain' approach in terms of the applicability of Chapter II, Chapter III, Chapter IV, and Chapter VII" — Role of the Board, IT Governance and Oversight, IT and Information Security Risk Management, and Information Systems Audit — "and for the following select paragraphs in Chapter V", which para 4 then enumerates in sixteen numbered groups:

para 4 group	Subject	Paragraphs
(1)	Inventory Management of Information Assets	49
(2)	Data Migration Controls	55
(3)	Physical and Environmental Controls	62, 63
(4)	Capacity Management	64, 65
(5)	Application Security Life Cycle	89, 90, 92
'	(6)	Maintenance, Monitoring and Analysis of Audit Logs
(7)	Patch, Vulnerability and Change Management	98
(8)	User Access Control / Management	104, 105, 110
(9)	Controls on Teleworking	114
(10)	Third-Party Arrangements	126
(11)	Cryptographic Controls	140
(12)	Straight Through Processing	141, 142
(13)	Vulnerability Assessment and Penetration Test	151–155
(14)	Business Continuity and Disaster Recovery	163–174
(15)	Cyber Incident Response and Recovery	175, 181, 183, 187, 190
(16)	Metrics	195, 196

Now the arithmetic. Chapters II, III, IV and VII are paras 7 to 10, 11–38, 39–46 and 224–229 — forty-six paragraphs. The sixteen Chapter V groups add forty-four more. Ninety paragraphs, out of the 223 operative paragraphs running from para 7 to para 229.

The 133 paragraphs para 4 does not reach

Chapter V alone runs from para 47 to para 211 — 165 paragraphs, of which para 4 names 44. The other 121 bind a branch exactly as they bind State Bank of India. So does para 143's duty to run a CSOC.

The CSOC duty, and the benchmark behind it. para 4's chapter list is II, III, IV and VII. Para 143 is absent from it, and para 143 is the hard one: "The bank shall set up a CSOC to ensure continuous surveillance and keep itself regularly updated on the latest nature of emerging cyber threats." That duty sits in Chapter V and is unrelaxed for a branch. Read the paragraph to its end, though, because the second sentence matters: "An indicative, but not exhaustive, minimum baseline guidance on CSOC is given in Chapter VI of these Directions." Chapter VI is the benchmark your design will be judged adequate against, not a second mandate stacked on the first — and it too is absent from para 4's list. Paras 212 to 223 are a build-and-run specification: a framework for establishment and operation (para 212), governance with Board/ITSC threat-intelligence briefing and dashboards (para 213), SIEM-based log collection, correlation and continuous monitoring (para 215), root-cause identification, IOC collection and honeypot services (para 216), a security analytics engine delivering wire-speed on-the-fly deep packet inspection (para 218), malware analysis and imaging for forensics (para 219), an L1/L2/L3 role structure with round-the-clock Level 1 monitoring (para 221), and a determination on 24x7 staffing using "suitable sourcing and operating models including in-house staffing or managed service arrangements" (para 223).

Chapter VI does carry internal calibration — para 212 requires the framework to be commensurate with technology risk profile, scale and complexity of operations. But that calibration sits inside the obligation. It is a design you must be able to defend as adequate, not a deviation you are permitted to explain.

Anti-phishing, para 148. The bank "shall subscribe to anti-phishing / anti-rogue app services from external service providers for identifying and taking down phishing websites / rogue applications". Not in the list. An express instruction to buy a capability from outside, binding without relaxation.

Incident reporting, para 182. Group 15 names para 175, 181, 183, 187 and 190. It does not name para 182. The six-hour clock — report cyber incidents within six hours of detection on the DAKSH platform, and separately, pro-actively notify CERT-In — is one of the paragraphs a branch cannot argue with. Note the two limbs: the six hours attaches to DAKSH. The Direction sets no timeline on the CERT-In limb.

Third-party arrangements. Group 10 gives you para 126, the vendor risk assessment process, and stops. Paras 127 to 139 bind. That includes para 133 (RBI shall have access to all information resources), para 135 (credentials, background checks, NDAs and security-policy agreements for third-party personnel), and paras 136 to 139 — where a bank running its ATM Switch through a shared-services provider must ensure the enumerated cybersecurity controls are implemented and maintained by that ASP, factor them into the contract under para 137, and mandate the 24 baseline controls at para 138(1) to (24), ending at PCI-DSS and PCI-SSF.

Application security. Group 5 gives you para 89, 90 and 92. It does not give you para 85, where the scope of application security assessments "shall be comprehensive" and expressly not restricted to the OWASP Top 10, 'nor para 86, which requires periodic application security testing of web and mobile applications throughout their lifecycle — pre-implementation, post-implementation and after changes — in an environment closely resembling or replicating production.'

Asset inventory. Group 1 relaxes para 49 — the enterprise data dictionary. Para 47, the inventory itself including key personnel and facilities, is not relaxed. Neither is para 48 or para 50.

Comply or explain is not exempt-if-inconvenient

para 4 closes: the approach "shall allow such foreign bank to deviate from any specific part of the above referred Chapters and select paragraphs of Chapter V of these Directions subject to examination and acceptance by RBI of a reasonably justifiable explanation for the same, as part of the supervisory process."

Three consequences.

The burden sits with the bank, and the standard is a reasonably justifiable explanation — not commercial preference, and not group-policy alignment asserted for its own sake.

Acceptance belongs to RBI and happens in the supervisory process. Until a deviation has been examined and accepted, it is unratified. An explanation written into an internal policy and never put in front of a supervisor is not an accepted deviation; it is an open finding waiting for a cycle to arrive.

And the unit is "any specific part". Deviations are enumerated one at a time, each with what you do instead. A blanket statement that the branch follows head-office standards is not an explanation; it is the thing an explanation has to justify.

The committee question

The practical objection — we have no Indian board and no board-level IT Strategy Committee — is answered inside para 17(1), which carries this note: "Foreign banks operating in India through branch mode may leverage upon controlling office / head office / regional / zonal Committees for compliance with this Master Direction as long as governance obligations / responsibilities outlined for the prescribed committees are met."

Leverage, not waiver. The committee you nominate must actually discharge the prescribed committee's responsibilities for the India operation — para 19's functions, at para 18's quarterly cadence, with an independent chairperson carrying para 17(2)'s minimum seven years of substantial IT expertise and para 17(3)'s technically competent members. What travels is the forum. The obligations do not travel with it.

Group 13 stops at para 155, and that is the whole story

The most consequential line in para 4 is the one that relaxes para 151 to 155 and goes no further.

Inside the relaxation: para 151's cadence — VA at least once every six months and PT at least once in 12 months for critical information systems and/or those in the DMZ having a customer interface, risk-based for non-critical systems. 'para 152's production-environment rule, with any deviation to be documented and, in the instrument's own softer register, 'should' be approved by the ISC.' para 153's time-bound remediation without CVE recurrence. Para 154's documented approach covering scope, coverage and CVSS-type scoring, which "shall also apply" to systems hosted in a cloud environment. Para 155's requirement for trained and independent testers.

Outside it, on both sides: paras 149 and 150 — periodic VA and PT for all critical and internet-facing systems, and lifecycle testing of critical internet-facing web and mobile applications, servers and network components pre-implementation, post-implementation and after changes. And para 156 to 161 in their entirety.

So a branch may argue about how often it tests, and even about para 155's trained-and-independent standard — both sit inside group (13). It may not argue about how those testers were selected and credentialed (para 156), what the report must state (para 157), what happens when they miss something (para 158), or who sees the closure status (para 161). The unrelaxed part begins exactly where the auditor's accountability does.

Para 156 is the selection regime, and it binds absolutely. At selecting, appointing, engaging or renewing a VA/PT auditor, the bank shall consider requisite qualification, professional expertise "(of the firm or company as well as the audit personnel engaged by the entity)", appropriate credentials and suitable competency. Firm level and personnel level, at every renewal.

CERT-In empanelment is how a bank evidences that. It is a standing, externally verified assessment of precisely the attributes para 156 directs you to weigh, at both levels, and it is the standard supervisors expect behind RBI audit work. 'para 159 then attaches a defined standard to that engagement: "in case of CERT-In empanelled auditors, the bank shall be guided by CERT-In's Comprehensive Cyber Security Audit Policy Guidelines."' Engaging an empanelled firm imports a defined audit-policy standard into the engagement — which is exactly the material a branch needs when it is explaining a cadence deviation, because the argument then stops being "we test less often" and becomes "what we do is at least as good, and here is the externally verifiable basis for saying so".

Security Brigade has been CERT-In empanelled continuously since 2008, across 1,000+ clients and 6,700+ assessments.

Para 157 is a procurement instruction as much as a reporting one. The bank shall review the coverage and scope of the VA/PT and ensure reasonable assurance for each of the areas therein "shall be provided explicitly in the VA / PT audit reports", and the same "shall be mentioned at the time of empanelling or selecting and awarding the contract". Per-area explicit assurance belongs in the RFP and the contract, not in a conversation at delivery.

Para 158 puts performance liability on the tester. A system subjected to VA/PT which is later compromised, ceteris paribus, "apparently due to vulnerabilities that were not observed or highlighted on timely basis in the VA / PT will qualify as a deficiency in discharge of function by the VA / PT auditor" — to be factored in when selecting or renewing. Ask a prospective tester what they make of para 158. The answer is diagnostic.

Para 161 requires VA/PT closure status to go to the ITSC and ISC at least quarterly. It binds absolutely, so whichever committee you leverage under para 17(1) needs it as a standing agenda item four times a year.

For completeness: red teaming at para 162 is "may". It has been permissive since 2016 and it still is.

What to have documented before your next supervisory cycle

1. A para 4 deviation register, part by part — what you deviate from, what you do instead, why it is at least as good, who approved it, and when it was last placed before RBI. If it has no column for "examined and accepted", it is not finished.
2. A committee map under para 17(1) — which controlling office, head office, regional or zonal committee discharges which prescribed committee's obligations, evidence that para 17(2) and para 17(3) are satisfied, quarterly minutes that visibly cover India operations, and para 161 closure reporting on the agenda.
3. An inventory of the non-relaxed obligations — the 133 paragraphs para 4 does not touch, with named owners. Begin with Chapter VI and para 143, then para 148, paras 149 to 150, paras 156 to 161, para 182 and paras 127 to 139.
4. An auditor file per VA/PT provider: firm-level and named-personnel credentials as para 156 requires, refreshed at each renewal, plus the ongoing para 158 performance review.
5. Contract language: para 157's explicit per-area assurance stated at empanelment or award; para 154's documented approach including cloud-hosted systems; and where an ATM Switch ASP is in the picture, para 138's baseline controls written into the agreement as para 137 requires.
6. A para 182 runbook that keeps the limbs separate — six hours to DAKSH from detection, proactive CERT-In notification alongside it, and the escalation path to the controlling office that para 183 requires.

The position para 4 actually leaves you in

It is a good deal, and a narrower one than it looks. Para 4 gives a branch room to argue about governance architecture and testing cadence — the two areas where a global institution's home-country regime genuinely does equivalent work. It gives no room at all on the CSOC, on taking down phishing sites, on the six-hour clock, on the third-party chain, or on the calibre and accountability of the people who test you.

That is the more interesting place to be. A branch that deviates must be able to show that what it does is at least as good, and "at least as good" is an evidence argument rather than a compliance one. It is won with methodology, named and credentialed testers, an explicit report and a closure record a supervisor can follow from finding to fix. Those are precisely the things para 4 declined to relax.