RBI Cybersecurity Directions for Small Finance Banks, Payments Banks and Credit Information Companies

On 31 July 2026 the Reserve Bank issued six entity-specific cybersecurity Directions in a single day. Three of them govern small finance banks, payments banks and credit information companies, and all three came into force the moment they were signed. There is no transition window, no glide path and no phased applicability anywhere in the text. What separates these three instruments from the other half of the set is what they leave out: unlike the NBFC Direction, which switches whole chapters on and off by Scale Based Regulation layer, and the urban co-operative bank Direction, which tiers by four levels of digital depth, RBI/DoS/2026-27/419, /428 and /470 apply in full to every entity in their populations from day one. Between them, small finance banks, payments banks and credit information companies account for fewer than thirty regulated entities in India, and every one of them now carries the complete baseline.

The bank Direction is not your instrument

This is the first thing that trips people up, and it is settled in a single sentence of the commercial banks Direction. Paragraph 3 of RBI/DoS/2026-27/410 defines its own scope as "banking companies (other than Small Finance Banks, Payments Banks, and Local Area Banks), corresponding new banks, and the State Bank of India, as defined respectively under clauses (c), (da), and (nc) of Section 5 of the Banking Regulation Act, 1949."

Small finance banks and payments banks are carved out by name. If your compliance team has been reading the commercial banks instrument since 31 July, it has been reading the wrong document. Your obligations sit in:

• Small finance banks — RBI/DoS/2026-27/419, DoS.CO.CSITEG.13/31.01.015/2026-27. 232 paragraphs, eight chapters. Applicability at para 3, commencement "with immediate effect" at para 2.
• Payments banks — RBI/DoS/2026-27/428, DoS.CO.CSITEG.22/31.01.015/2026-27. 232 paragraphs, eight chapters. Same paras 2, 3 structure.
• Credit information companies — RBI/DoS/2026-27/470, DoS.CO.CSITEG.64/31.01.015/2026-27. 227 paragraphs, eight chapters. Para 3 scopes it to CICs as defined under clause (e) of Section 2 of the Credit Information Companies (Regulation) Act, 2005.

All three carry the same signature: N. Suganandh, Chief General Manager, Department of Supervision. The drafting is close to identical across the set, which is precisely why the paragraph numbers are dangerous. The commercial banks VA/PT cadence sits at para 151. The same obligation is para 150 for small finance banks, para 150 for payments banks and para 146 for credit information companies. Cite para 151 in a board paper or a tender document and you have cited an instrument that does not apply to you.

One relaxation in the commercial banks instrument has no counterpart here either. The 'comply or explain' approach at CB para 4 exists only for foreign banks operating in India through branch mode. Nothing equivalent appears in /419, /428 or /470.

No tiering means the full baseline, now

Each of the three Directions repeals the existing cybersecurity and IT governance instructions applicable to its entity type: SFB para 229, PB para 229, CIC para 224, each pointing to circular DoS.CO.PPG.66/11.01.005/2026-27 dated 31 July 2026, which repealed 628 circulars with immediate effect alongside 64 consolidated Directions. The savings clauses (SFB para 230, PB para 230, CIC para 225) preserve action already taken under the repealed instructions, but the forward-looking obligation is the 2026 text and nothing else.

So the practical question is not whether the RBI cybersecurity framework has changed for you. It is which of the roughly 230 paragraphs now bear a clock, an artefact or an external dependency. Six areas do most of the work.

VA every six months, PT every twelve

SFB para 150, PB para 150 and CIC para 146 are word-for-word identical: "For critical information systems and / or those in the DMZ having customer interface, VA shall be conducted at least once in every six months and PT at least once in 12 months. For non-critical information systems, a risk-based approach shall be adopted to decide the requirement and periodicity of conduct of VA / PT."

Read the scope carefully. It is disjunctive. A system does not need to be both critical and customer-facing in the DMZ. Either limb pulls it into the six-month vulnerability assessment and twelve-month penetration test cadence. In practice this catches internet banking platforms, mobile app back-ends, customer APIs and the DMZ estate, alongside core systems that never face a customer at all.

The surrounding paragraphs are where scoping arguments are usually lost:

• All critical and internet-facing systems get periodic VA and PT regardless (SFB para 148, PB para 148, CIC para 144).
• Lifecycle testing applies to critical, internet-facing web and mobile applications, servers and network components at pre-implementation, post-implementation and after changes (SFB para 149, PB para 149, CIC para 145).
• Post-implementation testing runs on production. Where a test environment is unavoidable, its version and configuration must resemble production, and any deviation should be documented and approved by the Information Security Committee (SFB para 151, PB para 151, CIC para 147) — note that RBI uses "should" here, against "shall" for the rest of the paragraph.
• Cloud is no longer optional. The documented VA/PT approach covering scope, coverage and a vulnerability scoring mechanism "shall also apply" to information systems hosted in a cloud environment (SFB para 153, PB para 153, CIC para 149). The 2023 IT governance Master Direction used "may". That single word is the cleanest change in the document.
• Closure is a quarterly board artefact. The status of closure of VA/PT observations goes to the IT Strategy Committee and the Information Security Committee at least quarterly (SFB para 160, PB para 160, CIC para 156), with findings monitored by the information security and IS audit teams and senior management (SFB para 159, PB para 159, CIC para 155), and remediation delivered in a time-bound manner without recurrence of known CVEs (SFB para 152, PB para 152, CIC para 148).

Three paragraphs that regulate your testing vendor

This is the genuinely new content, and it has had almost no attention. Three consecutive paragraphs place obligations on you about the firm that tests you.

Auditor competency at every renewal. You "shall have control / check over audit methodology, processes, and competence of auditors", and at the time of selecting, appointing, engaging or renewing, you 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 (SFB para 155, PB para 155, CIC para 151). Firm level and named-individual level, every cycle.

Explicit assurance in the report. You shall review the coverage and scope and ensure that "reasonable assurance for each of the areas therein shall be provided explicitly in the VA / PT audit reports", and that requirement shall be stated at the time of empanelling or awarding the contract (SFB para 156, PB para 156, CIC para 152). This is a report-format mandate. Most testing reports on the market today do not satisfy it.

A later breach becomes the auditor's recorded deficiency. If systems, applications or infrastructure that were subjected to VA/PT are "found to have been compromised at a later date, apparently due to vulnerabilities that were not observed or highlighted on timely basis in the VA / PT", that "will qualify as a deficiency in discharge of function by the VA / PT auditor", and shall be factored into competency evaluation at selection and renewal (SFB para 157, PB para 157, CIC para 153). Retrospective, breach-triggered performance liability, written into the Direction.

Then the credentials question. SFB para 154, PB para 154 and CIC para 150 require testing by "appropriately trained and independent information security experts / auditors", and SFB para 158, PB para 158 and CIC para 154 provide that with CERT-In empanelled auditors, the entity "shall be guided by CERT-In's Comprehensive Cyber Security Audit Policy Guidelines". Put those alongside the competency clause and the position is straightforward: you are required to evidence firm-level and personnel-level credentials at every selection and renewal, and CERT-In empanelment is how that evidence is produced and defended in front of a supervisor. It also imports a defined audit policy regime into the engagement. CERT-In empanelment is the standard supervisors expect for RBI audit work, and it is named outright in other RBI instruments including the PA-PG system audit and the data-localisation System Audit Report.

Security Brigade has held CERT-In empanelment continuously since 2008, across every revision of the empanelment regime in eighteen years. We evidence named-auditor identity, designation and credentials as a matter of course, which is exactly what SFB para 155, PB para 155 and CIC para 151 ask you to collect.

Red teaming is permissive. Do not let anyone tell you otherwise

SFB para 161, PB para 161 and CIC para 157 all use the same verb: the entity "may conduct red teaming exercises". That is a discretionary paragraph sitting immediately after a mandatory one. VA and PT at six and twelve months are "shall". Red teaming is not, in any of the three instruments. Red teaming is a good exercise for a mature security programme. It is not the paragraph that closes your supervisory gap, and a proposal that presents it as mandatory has misread the text.

Anti-phishing takedown must come from outside

SFB para 147, PB para 147 and CIC para 143 are the sharpest procurement instruction in the document: the entity "shall subscribe to anti-phishing / anti-rogue app services from external service providers for identifying and taking down phishing websites / rogue applications."

This is a "shall" that cannot be closed with an internal team. RBI has specified the delivery model, not just the outcome. It covers both limbs, phishing domains and rogue mobile applications, which means the app stores are in scope alongside the domain space.

ShadowMap, Security Brigade's threat exposure platform, runs continuous phishing and lookalike-domain detection with takedown executed through 86 provider relationships across 12 provider types, plus brand protection monitoring across app-store surfaces. It is the cleanest product-to-paragraph fit in the whole instrument.

Six hours, and the clock is on DAKSH

SFB para 181, PB para 181 and CIC para 177 read the same way: report cyber incidents "within six hours of detection on DAKSH platform", and "also pro-actively notify CERT-In regarding cyber incidents."

The six hours attaches to the DAKSH limb in these Directions. The CERT-In notification is expressed as an additional duty with no timeline stated in this instrument; CERT-In's own 2022 Directions set a six-hour requirement separately and on their own terms. Write your runbook so both limbs fire, and do not conflate the two obligations in your incident policy, because the escalation paths and the evidence you file are different.

Around it: analysis of incidents for severity, impact and root cause including forensic analysis where necessary (SFB para 180, PB para 180, CIC para 176), and clear communication plans for escalation to the Board, senior management and customers (SFB para 182, PB para 182, CIC para 178).

Application security has moved past the OWASP Top 10

The application chapter is where technology leads find the most work. In all three instruments, the scope of application security assessments "shall be comprehensive and shall not be restricted to testing solely against the OWASP top 10 vulnerabilities" (para 84 in each), with lifecycle testing conducted "in an environment closely resembling or a replica of the production environment" (para 85 in each).

On source code the modality changes twice in three paragraphs. You shall obtain source code for all critical applications or put a source code escrow arrangement in place, including all product updates and programme fixes (para 89). You may consider source code audits by professionally competent personnel or service providers (para 90). You shall obtain a certificate or written confirmation from the application developer or vendor that the application is free of known vulnerabilities, malware and covert channels, repeated on material changes (para 91). That last one is the vendor's attestation, not the tester's, and a security assessment report does not discharge it.

Access controls carry a rare "mandatory" inside a "shall": multi-factor authentication is mandatory for privileged users of critical information systems and critical activities (para 109 in each), with user access credentials protected against leakage and attack (para 106 in each).

Small finance banks and payments banks additionally carry the ATM Switch Application Service Provider chain. Paragraph 135 cross-references twelve control areas the ASP must implement, para 136 requires them in the contract, and para 137 enumerates 24 baseline cybersecurity controls the bank shall mandate contractually with the ASP. If you run your switch through shared services, that contract needs reopening. The credit information companies instrument has no ATM switch section, but para 134 still requires background checks, non-disclosure agreements and security policy compliance agreements for all third-party service providers.

Credit information companies: four entities, one naming trap

Every credit information company registered with RBI under Section 2(e) of the CIC(R) Act, 2005 — currently four — is fully in scope for all 227 paragraphs of /470. There is no threshold, no layer and no level. It is the smallest population in the set and the one with the least room to argue about applicability.

The trap is the acronym. In the NBFC Direction, RBI/DoS/2026-27/461, "CIC" means Core Investment Company, and those entities are scoped to Chapter III alone and expressly excluded from Chapter V. In /470, "CIC" means Credit Information Company under Section 2(e) of the CIC(R) Act, 2005. Two different acronyms, two different populations, two different obligation sets. Any guidance that mixes them is guidance to distrust.

For a CIC the governance clauses deserve a second read. Paragraph 26 requires a senior executive, preferably of General Manager rank, designated as CISO, with no direct reporting relationship to the Head of IT and no business targets. Paragraph 27(6) puts the CISO's reporting line to the Executive Director or equivalent overseeing risk management, and para 27(7) requires a quarterly review of cybersecurity risks, arrangements and preparedness before the Board, the Risk Management Committee of the Board or the IT Strategy Committee. Small finance banks and payments banks carry the same structure at para 27(6) and para 27(7).

Where monitoring sits, and where we stop

Chapter VI in all three instruments is a full build-and-run specification for a Cyber Security Operations Centre. RBI expressly permits you to buy it: SFB para 222, PB para 222 and CIC para 217 require you to determine 24x7 staffing requirements and to "adopt suitable sourcing and operating models including in-house staffing or managed service arrangements".

Security Brigade does not operate a SOC, MDR or SIEM service. We work alongside whichever monitoring provider you appoint, and our testing output feeds their detection content. That is the boundary, and it is worth stating plainly rather than discovering in month three of an engagement.

Chapter VII, on the other hand, sits close to our work. The IS Audit Policy is approved and reviewed annually by the Audit Committee of the Board (SFB para 224, PB para 224, CIC para 219), audit planning is risk-based (SFB para 227, PB para 227, CIC para 222), and where external resources are used in areas where in-house skills are lacking, responsibility and accountability stay with the competent authority inside the Internal Audit function (SFB para 226, PB para 226, CIC para 221).

What to do in the next ninety days

1. Redo the scoping determination against the disjunctive test. List every information system that is critical or in the DMZ with a customer interface. That list, not last year's list, drives the para 150 / para 146 cadence.
2. Move to a six-month VA cycle now. Annual testing does not meet the Direction. The six-month VA cadence carries forward verbatim from the 2023 IT governance Master Direction, so there is no transition period to shelter behind and no argument that this is new.
3. Build the auditor competency file. Firm credentials and named personnel credentials, dated, refreshed at every renewal. That is what para 155 / para 151 asks you to be able to produce.
4. Rewrite the report specification into your contract. Per-area explicit reasonable assurance, stated at award, per para 156 / para 152.
5. Subscribe to external anti-phishing and anti-rogue-app takedown. para 147 / para 143 will not be satisfied by an internal process.
6. Extend the VA/PT methodology to cloud-hosted systems and write it down. para 153 / para 149 changed "may" to "shall".
7. Test the six-hour DAKSH path end to end, with the separate CERT-In notification as its own step.

Security Brigade has been CERT-In empanelled since 2008, has delivered more than 6,700 assessments and works with over 1,000 clients across banking, payments and financial infrastructure. Our VA/PT programmes are built around the six- and twelve-month cadence, cloud scope, lifecycle testing triggers and the quarterly closure pack your IT Strategy Committee and Information Security Committee now need.

If you run a small finance bank, a payments bank or a credit information company, the paragraph numbers in this piece are the ones that apply to you. Talk to us about mapping them to a testing calendar that survives supervisory review.