Regulation & Assurance

RBI 2026 Cybersecurity: Board Responsibilities

Map RBI’s 2026 commercial-bank cybersecurity duties to board approvals, committee oversight and practical evidence for a documented governance review.

Three professionals review an evidence folder during a governance meeting.
In this article 6 sections
ShareLinkedInWhatsAppEmail

A framework that talks to the board, not just the CISO

RBI issued its Commercial Banks cybersecurity, technology risk, resilience and assurance directions on 31 July 2026, effective immediately. Paragraph 3 excludes Small Finance Banks, Payments Banks and Local Area Banks; paragraph 4 sets special arrangements for foreign-bank branches. Do not extend these directions automatically to NBFCs or fintechs. RBI paragraphs 2–4: commencement and applicability

The framework includes explicit board and committee responsibilities alongside technical controls. For a board discussion, the practical question is how control findings become owned decisions and tracked improvement actions.

From “was it patched” to “who is accountable”

Board oversight predates the 2026 directions. A useful review connects control evidence with responsibility for remaining gaps: who owns the action, what is its priority, and when will it be reviewed? The recommendations below are practical reporting suggestions, not quotations of mandatory agenda wording.

An operational dashboard and a governance record serve different purposes. Show what was tested, what remains unresolved, and what decision the board or relevant committee is being asked to make. A named action owner is our suggested reporting practice, not a substitute for the formal responsibilities below.

Three things worth bringing to your next board cycle

Depending on your institution’s current reporting maturity, three changes are worth making before the next board review, not after a supervisory visit prompts them:

A cyber risk item on the board’s own agenda, distinct from a general technology or operational risk item. Folding cyber risk into a broader risk slide makes it easy to review superficially; a dedicated item makes it harder to skip the detail.

Assign an accountable function and a delivery owner to each material gap. Record who can accept residual risk under the bank’s own delegation, and distinguish that decision from the person implementing the fix.

A comparison to the previous review, not a static snapshot. “What changed since we last discussed this” is a more defensible answer than a fresh slide that could have been presented at any point in the last two years.

Where this connects to a wider governance picture

None of this needs to be built from scratch. Depending on scope, this typically connects to work already underway on obligation-to-control mapping, evidence reviews and improvement roadmaps — the same building blocks used across governance, privacy and AI-risk programmes more broadly. The starting point is usually the same requirements brief and capability map used for any governance engagement; RBI’s board-level expectation is one more input into what that evidence needs to show.

Map the requirement to a reviewable record

Chapter II supplies specific responsibilities. The evidence examples here are suggested ways to make those responsibilities reviewable; the directions do not prescribe this exact board-pack format. RBI Chapter II, paragraphs 7–10

  • Paragraphs 7–8: board approval of the listed IT, information-asset, continuity, information-security and cybersecurity strategies and policies, with review at least annually. Suggested evidence: a policy register linking the approved version, resolution, review date and unresolved exceptions.
  • Paragraph 9: a board-level IT Strategy Committee, with composition and functions under paragraphs 16–19. Suggested evidence: current terms of reference, membership and a calendar linked to the committee’s responsibilities.
  • Paragraph 10: Audit Committee oversight of information-systems audit. Suggested evidence: the audit plan, significant findings and the committee record showing how overdue actions were challenged.
  • For each material action, show the affected service, evidence date, accountable owner, target date and dependency. An overdue item should explain the business exposure and the decision required; a red status indicator alone is insufficient context.
  • Separate closure from acceptance. Closure needs evidence that the control works in the relevant scope; acceptance records a conscious decision to retain a risk. Keep both traceable to the bank’s authorised process.

Start with one reporting cycle and reconcile the pack to the underlying registers before circulation. Preserve restricted technical evidence in a controlled repository and give directors a proportionate summary. Repeated deferral should remain visible rather than being presented as a newly raised issue each quarter.

Sources and further guidance

Regulatory applicability depends on the organisation and the provisions in force. Check the linked primary sources before acting.

Related reading and capabilities

Frequently asked questions

Does this framework apply to every financial business?

No. Establish the entity’s regulatory category first. An NBFC, fintech or excluded bank category must identify its own applicable instruments; borrowing a useful governance practice does not change legal applicability.

Must every technical finding go to the full board?

Use the bank’s materiality and delegation rules. Operational teams can manage routine findings while relevant committees receive significant risks, exceptions and decisions. This article does not prescribe a universal escalation threshold.

What demonstrates that an action is closed?

Retain a dated test or review covering the original gap, the person who accepted the evidence and any remaining limitation. A ticket marked complete without verification is weak closure evidence.