Paragraph 148: The One RBI Obligation You Are Not Allowed to Satisfy In-House

Most of the RBI (Commercial Banks — Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 — the instrument that replaced what everyone still searches for as the RBI cybersecurity framework — tells a bank what outcome to reach and leaves the delivery model alone. Paragraph 148 does not. It reads, in full:

> "The bank shall subscribe to anti-phishing / anti-rogue app services from external service providers for identifying and taking down phishing websites / rogue applications."

Two words carry that sentence. *Shall*, and *external*. Across 233 paragraphs this is the only place RBI mandates an outside supplier for a security capability. The instrument names a counterparty twice more — para 90 requires source code from the bank's vendors or an escrow arrangement, para 92 the developer's own written confirmation — but neither buys the bank something it could otherwise have built in-house. An internal team, however good, does not discharge para 148. A licence for a tool you run yourself does not discharge it. The obligation is to hold a subscription with an outside provider, and it has been in force since 31 July 2026 with no transition period.

## Read it against the two paragraphs above it

RBI shifts register three times in three consecutive paragraphs, and the contrast is the clearest guide to how the whole instrument should be read.

Para 146: "The bank shall implement whitelisting of internet websites / systems." A mandatory outcome, your choice of method.

Para 147: "The bank shall consider implementing secure web gateways…" A mandatory duty to consider with a discretionary outcome. The bank may decline, but it has to be able to show it evaluated.

Para 148: "The bank shall subscribe… from external service providers." Mandatory, and prescriptive about how.

Anyone summarising these three as "RBI requires anti-phishing controls" has flattened the only distinction that matters at an inspection.

Note also that para 148 has two verbs, joined: **identifying and taking down**. A feed that detects lookalike domains and hands you a spreadsheet answers half of it. Enforcement is not an optional upgrade to the subscription; it is named in the paragraph.

And note the tense. *Subscribe* is a continuing state, not a project with a completion date. The primary artefact para 148 asks for is a contract in effect, not a report filed once a year.

This is not, in substance, brand-new. The same requirement sat in the 2016 Cyber Security Framework's Annex 1, in an annex that described itself as indicative rather than exhaustive. What changed on 31 July is enforceability: it is now a numbered operative paragraph in a Direction that commenced on issuance, in an instrument written specifically for your entity type. That is the honest headline, and it is a bigger change than a new control would have been.

## Find your paragraph before you find your provider

RBI issued six entity-specific Directions on 31 July 2026, not one circular. Local area banks are carved out of all six (CB para 3). The anti-phishing duty is not in the same place in each of the six, and it is not in all of them.

| Entity | Instrument | Paragraph | Applies to |
|---|---|---|---|
| Commercial banks | RBI/DoS/2026-27/410 | **Para 148** | All in scope |
| Small finance banks | /419 | **Para 147** | All in scope |
| Payments banks | /428 | **Para 147** | All in scope |
| Urban co-operative banks | /437 | **Para 123** | Level II and above only |
| Credit Information Companies | /470 | **Para 143** | All, no tiering (para 3) |
| NBFCs | /461 | **none** | No takedown-subscription duty |

Two of those rows need spelling out.

**UCBs.** para 123 sits in Chapter IV, under the heading "J. Anti-Phishing". Chapter IV is the Level II baseline. UCB scoping at para 4 runs on four Levels of digital depth, not asset size: UCB scoping at para 4 runs on four Levels of digital depth, not asset size, and Level II is conjunctive: the UCB must be a sub-member of Centralised Payment Systems and satisfy at least one of internet banking (view or transaction based), mobile banking through an application, or direct membership of CTS, IMPS or UPI. A CPS sub-member that is also a direct UPI member is inside para 123, whatever its balance sheet. Above that, a UCB that is a direct CPS member, or runs its own ATM Switch or a SWIFT interface, is Level III and picks up Chapter IV with it. A Level I UCB is not, and carries no VA/PT obligation of its own either (para 116 sits in the same Level II chapter). It does still have to impose one by contract: para 83(11), paras 84 and 85(34)-(35) sit in the Level I chapter and require every UCB to oblige its third-party ATM Switch ASP to conduct VA/PT and share the reports with the UCB and RBI. The UCB text also says "anti-rogue **application** services" where the other four — commercial banks, SFBs, payments banks and CICs — say "app": same duty, different draftsman.

**NBFCs.** There is no counterpart. The word "rogue" does not appear anywhere in /461. An NBFC that has been told it must buy takedown services under the 2026 Directions has been mis-sold. What NBFCs do carry is scoped by SBR layer, and para 3 applies each chapter only to its own layer, so the two phishing duties never land on the same firm. Para 27, in Chapter IV, requires a Base Layer NBFC of ₹500 crore and above to take preventive and corrective measures against cyber threats expressly including email phishing, spear phishing, whaling and vishing. Para 98, in Chapter V, requires a Middle, Upper or Top Layer NBFC to review its security infrastructure and policies at least annually and take steps to tackle phishing and spoofing attacks. A Base Layer NBFC below ₹500 crore, and a Core Investment Company of any size, gets Chapter III — para 7 to 9, and neither of those duties. Those are real duties with a real evidentiary burden. They are not a subscription mandate, and saying otherwise is the sort of claim a compliance buyer checks in ninety seconds.

## The two paragraphs that turn para 148 into a programme

para 148 in isolation is a procurement line. Two neighbours make it operational.

**Para 206 — the inbound channel.** "The bank shall encourage customers to report phishing mails / phishing sites and on such reporting, the bank shall take effective remedial action." Siblings at SFB para 205, PB para 205 and CIC para 201. This is the paragraph that converts a customer email into a supervisory expectation. "Effective remedial action" against a phishing site hosted outside your estate has exactly one meaning: a notice filed with the party that can remove it, and chased. Para 206 is where a supervisor discovers whether your para 148 subscription is wired to anything. Note that the UCB instrument carries no para 206 equivalent — the customer-reporting limb is a bank and CIC obligation.

**Para 107 — credential leakage.** "The bank shall protect user access credentials such as logon user-id, authentication information and tokens, access profiles, against leakage / attacks." Siblings at SFB para 106, PB para 106, CIC para 106. For UCBs the equivalent language appears only as a control the UCB must impose by contract on a third-party ATM Switch Application Service Provider, at para 85(22) read with paras 83 to 84. Phishing exists to harvest credentials, and credentials stolen by infostealer malware never touch your phishing page at all. A para 148 programme that watches only for fake sites and fake apps is watching one of the two routes.

## What a supervisor will actually ask to see

Be specific about the artefacts, because this is where most programmes are thin.

- **The subscription itself.** An agreement with a named external provider, in force, whose scope covers both identification and takedown. This is the para 148 evidence proper.
- **A dated case record per incident.** What was found, on which surface, when it was detected, when the notice went out, which counterparty received it, what that counterparty did.
- **The outcomes that were not removals.** A pipeline that reports only its successes is advertising, not a record. Denials, counter-notices and findings that were never eligible for a notice belong in the same table as the completions.
- **Escalation history.** Which provider was approached, in what order, and what happened when the first one declined.
- **Scope at run, with an as-at date.** A count of what was under watch is worth little without the date it was true.
- **The para 206 join.** A customer-reported phishing site should be traceable to a filed, dated case.

## Where ShadowMap fits

ShadowMap is a Security Brigade product, and it is built around exactly the two verbs in para 148.

**Identifying.** Domain and brand surveillance across the surfaces a customer would plausibly mistake for you: registered lookalike domains and typosquats, social-platform impersonation, app stores, and executive impersonation accounts. App-store surveillance is the limb that answers "rogue applications" directly, and it is the one most anti-phishing subscriptions quietly omit. Detection alone is the commodity; the harder half is disposition — telling an impersonator from a reseller you authorised.

**Taking down.** Eighty-six takedown provider relationships across twelve counterparty types — hosting, social platforms, registrars, cloud storage, app stores, CDNs, paste and forum sites, developer tools, marketplaces, code platforms, search engines, and an honest residual. Nobody outside the provider can delete anything, so the service is knowing which counterparty holds the power, which evidence that counterparty's policy will accept, and which of them will simply refuse. Every case carries one explicit status from a published vocabulary of eight, four of them terminal, and three of those four are not removals. Takedowns are unlimited under the licence, subject to fair use, so nobody on your side has to decide whether an impersonation is worth filing against.

**Credentials, for para 107.** ShadowMap runs its own stealer-log collection alongside a licensed breach corpus, retains roughly 41TB of raw source material behind 12B+ breach and credential records, holds it permanently, and reprocesses it as extraction improves. The count is not the point. The question para 107 makes you answer is which of the leaked credentials still open something.

One boundary, stated once. External monitoring and takedown is not a Cyber Security Operations Centre. Chapter VI (paras 212 to 223) is a separate build, and para 223 expressly permits managed-service arrangements — we work alongside whoever your bank has chosen to run it.

## The credential question behind the procurement

para 148 makes you buy from outside. Para 156 sets the standard the same supervisor applies to the VA / PT auditor or consultant: at every selection, appointment, engagement or renewal, the bank must consider requisite qualification, professional expertise — of the firm as well as the audit personnel engaged — appropriate credentials, and suitable competency. Para 159 imports CERT-In's Comprehensive Cyber Security Audit Policy Guidelines into that relationship. Empanelment is how those credentials get evidenced, and it is the standard supervisors expect for RBI audit work.

Security Brigade has been CERT-In empanelled continuously since 2008, across 6,700+ assessments for 1,000+ clients. When the anti-phishing subscription and the VA/PT programme sit with the same firm, the para 156 file is already written.

**The short version:** find your paragraph — paras 148, 147, para 123 or para 143 — confirm the subscription covers takedown and not just detection, wire para 206 into it, and make sure the record it produces names its failures. That last one is what makes the rest of it believable.