Financial servicesIndia

RBI CTRRAF 2026 - Commercial Banks

Connect bank-wide cyber governance with reviewable evidence

Bring technology-risk actions, policy responsibilities and audit follow-up into one programme for your commercial bank.

Full title
Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026
Issued by
Reserve Bank of India, Department of Supervision
Issued and in force
31 July 2026, effective on issue. Text updated as on 1 October 2026.
Applies to
Commercial banks, including the State Bank of India and corresponding new banks. Separate Directions cover other regulated entities.
Nature
Binding regulatory Directions, reviewed through RBI supervision and the bank’s own information systems audit
Structure
Eight chapters, including 31 baseline cybersecurity and resilience requirement areas

Overview

What the Directions require

The Directions set out how a commercial bank must govern technology, manage IT and cyber risk, protect its systems, respond to incidents and prove that its controls work. They bring the earlier cybersecurity framework and IT governance instructions for commercial banks into one set of Directions, which were issued by the Reserve Bank of India’s Department of Supervision on 31 July 2026 and took effect on issue. The earlier instructions on the same subject stand repealed, with a saving clause for actions already taken under them.

CTRRAF stands for Cybersecurity, Technology: Risk, Resilience and Assurance Framework. The Directions run from Board-level accountability, through IT governance and risk management, down to baseline technical controls, a Cyber Security Operations Centre and information systems audit. Many requirements apply with greater rigour to critical systems, and the bank decides which systems are critical through its own risk assessment.

Accountability sits at the top. The Board approves the IT, information security, cybersecurity and business continuity strategies and policies, and the cybersecurity policy must be distinct from the broader IT and information security policy. An IT Strategy Committee of the Board, an IT Steering Committee, an Information Security Committee and an independent Chief Information Security Officer each have defined roles, meeting frequencies and reporting lines.

For most banks, the hard part is not interpreting the text. It is running it: giving every requirement an owner, keeping evidence current between inspections, closing findings on time and showing the Board, the IT Strategy Committee and the Audit Committee where the bank stands.

Who it applies to

The Directions apply to commercial banks, which they define as:

  • Banking companies, other than Small Finance Banks, Payments Banks and Local Area Banks
  • Corresponding new banks
  • The State Bank of India
  • Foreign banks operating in India in branch mode, where the Board is read as the controlling or head office. They follow a comply-or-explain approach for Chapters II, III, IV and VII and for specified paragraphs of Chapter V, with a reasonable explanation for any deviation.
  • Third-party ATM Switch Application Service Providers, through baseline controls the bank must apply in its arrangements with them

Other regulated entities have their own Directions. See Small Finance Banks, Payments Banks, Urban Co-operative Banks, NBFCs, Credit Information Companies and All India Financial Institutions.

Structure

How the Directions are organised

Eight chapters, from the role of the Board to information systems audit. Chapter V holds the baseline controls, grouped here by theme for easier reading.

Chapter I

Preliminary

Short title and commencement, applicability, and definitions used throughout the Directions.

Chapter II

Role of the Board

The Board owns technology and cyber risk.

Board-approved policies
The Board approves the IT, information security, cybersecurity and business continuity strategies and policies, and reviews them at least annually. The Board may delegate the review to the IT Strategy Committee.
Board-level committees
Responsibilities are shared with Board committees, including the IT Strategy Committee and the Audit Committee of the Board, which oversees information systems audit.
Chapter III

IT governance and oversight

Who does what, how often they meet and to whom they report.

IT governance framework
A framework that sets out how technology is governed, from strategy to delivery.
Information security and cybersecurity policies
An information security policy, and a cybersecurity policy that is distinct and separate from the broader IT and information security policy.
IT Strategy Committee
At least three directors. The Chairperson is an independent director with substantial IT expertise, meaning at least seven years of relevant experience. Meets at least quarterly and reviews business continuity and disaster recovery at least annually.
Senior management and IT Steering Committee
Senior management representation from IT and business functions. Meets at least quarterly.
Information Security Committee
Works under the IT Strategy Committee and is headed by an official from the risk management vertical.
Head of IT function
A sufficiently senior and technically competent official.
Chief Information Security Officer
Preferably at General Manager level or equivalent. Must not report directly to the Head of IT and must not carry business targets. Reports directly to the Executive Director overseeing risk management, and reviews cyber risk and preparedness before the Board, its Risk Management Committee or the IT Strategy Committee at least quarterly.
IT project management
Governance of technology projects through their life cycle.
IT architecture
An architecture reviewed by the IT Strategy Committee at least annually.
IT services management
Management of IT services and their delivery.
Chapter IV

IT and information security risk management

A risk management framework for IT and information security, with periodic review.

Periodic review of IT risks
IT-related risks are reviewed periodically, and the risk policy is reviewed at least annually.
Risk management framework
A framework for identifying, assessing and treating IT and information security risk.
Identification, assessment and documentation
Risks are identified, assessed and documented, and categorised as low, moderate, high and very high, or with a similar scale.
Chapter V

Baseline controls: assets, data and infrastructure

Chapter V sets 31 baseline cybersecurity and resilience requirement areas. These cover what the bank owns and how it is configured and run.

Inventory management
Keeping an inventory of information assets.
Data leak prevention
Controls to prevent the leakage of data.
Data migration controls
Controls over the migration of data between systems.
Preventing unauthorised software
Controls that stop unauthorised software running on bank systems.
Physical and environmental controls
Protection of facilities and equipment. Data centre and disaster recovery sites must be geographically well separated.
Capacity management
Capacity assessed annually or more often.
Secure configuration
Systems configured securely.
Network management and security
Management and protection of the bank’s networks.
Application security life cycle
Security built into how applications are designed, built, tested and run.
Audit logs
Logging and review, including the activities of users with elevated access and privileged access to critical systems.
Patch, vulnerability and change management
Patches applied and vulnerabilities and changes managed in a controlled way.
Removable media
Controls over the use of removable media.
Cryptographic controls
Use of cryptography to protect information.
Straight through processing
Controls over automated, straight through processing of transactions.
Chapter V

Baseline controls: access, detection and testing

User access control
Access granted and managed by need, with privileged access allowed, managed, logged and monitored.
Teleworking
Controls for secure remote working.
Customer authentication
Authentication of customers on the bank’s channels.
Secure mail
Protection of the bank’s email systems.
Continuous surveillance
Continuous monitoring of the bank’s environment.
Advanced threat defence
Defences against advanced threats.
Anti-phishing
Measures against phishing.
Vulnerability assessment and penetration testing
For critical systems and systems in the DMZ with customer interfaces: vulnerability assessment at least once every six months and penetration testing at least once in twelve months. Closure status is reported to the IT Strategy Committee and the Information Security Committee at least quarterly.
Red teaming
The bank may run red team exercises to find vulnerabilities, test its defences and simulate an attacker. These are optional.
Risk-based transaction monitoring
Monitoring transactions according to risk.
Forensics
Network forensics, forensic investigation and DDoS mitigation support arranged and on standby.
Chapter V

Baseline controls: resilience, response, third parties and people

Third-party arrangements
Risk assessment and proportionate controls for IT and cybersecurity third parties, covering concentration risk, conflicts of interest, single points of failure, legal compliance and supply chain risk. The bank stays accountable. Contracts include the bank’s right to audit and RBI’s right to inspect, and RBI must have access to information resources the bank uses, even where they are not on bank premises. Data location rules apply, and third-party personnel need background checks and non-disclosure agreements. Baseline controls apply to ATM Switch Application Service Providers.
Business continuity and disaster recovery
Good practice such as ISO 22301. Disaster recovery drills for critical systems at least half-yearly, running the disaster recovery site as primary for at least a full working day. Backups restored periodically to test them. A minimal recovery time objective approved by the IT Strategy Committee, near-zero recovery point objective for critical systems, and identical configurations and patches at the primary and recovery sites.
Cyber incident response and recovery
A policy covering classification, roles, reporting, communication, containment and post-incident review, with documented responses to ransomware, data destruction and DDoS attacks. Cyber incidents are reported to RBI on the DAKSH platform within six hours of detection, and CERT-IN is notified.
Cyber Crisis Management Plan
Documented as part of the Board-approved cybersecurity framework, covering detection, containment, response and recovery.
Metrics
Key performance and risk indicators, such as patch latency and awareness coverage, and recovery metrics, including recovery time and recovery point objectives for all critical systems.
Awareness
Annual training for Board members and senior management, annual training for lower and middle management, and mandatory awareness for new recruits.
Customer education
Educating customers about cyber risks.
Chapter VI

Cyber Security Operations Centre

A Cyber Security Operations Centre sized to the bank’s technology risk profile.

Governance
A framework for setting up and running the centre. The Board or IT Strategy Committee and senior management are briefed on threat intelligence, with dashboards, metrics and defined reporting.
Capabilities
Log collection and correlation through SIEM tools, continuous monitoring and alerting, root-cause analysis, incident investigation, malware analysis and forensic imaging, integrated with ticketing and case management.
Staff
Competent staff on a continuous basis in three levels: round-the-clock monitoring, specialists for root-cause analysis, and advanced analysts for deep analysis and forensics. The bank chooses an in-house or managed-service model and plans staffing, training and retention.
Chapter VII

Information systems audit

Independent assurance over technology and cyber controls.

Oversight
The Audit Committee of the Board oversees information systems audit and reviews critical IT, information security and cybersecurity issues.
IS Audit Policy
Covers mandate, purpose, authority, the audit universe and audit periodicity. Approved by the Audit Committee and reviewed at least annually.
Function and skills
A separate IS audit function, or resources with the required skills, within internal audit. Where external auditors fill skill gaps, accountability stays with internal audit.
Planning and frequency
Risk-based audit planning, with the option of continuous auditing for critical systems.
Chapter VIII

Repeal and other provisions

Earlier instructions on the cybersecurity framework and IT governance for commercial banks are repealed, with a saving clause. Other laws continue to apply.

Implementation roadmap

How to implement it, step by step

A practical sequence for putting the Directions into operation and keeping them there.

  1. 1

    Confirm applicability and scope

    Confirm that the bank falls under the Commercial Banks Directions rather than another entity’s Directions. Foreign banks in branch mode should note which parts are comply-or-explain. List information systems and decide, through risk assessment, which are critical, because several requirements apply specifically to critical systems.

    OutputsApplicability noteCritical systems list
  2. 2

    Put governance in place

    Have the Board approve the IT, information security, cybersecurity and business continuity policies, with the cybersecurity policy kept separate. Constitute or re-check the IT Strategy Committee, IT Steering Committee and Information Security Committee. Confirm the CISO’s level, independence and reporting line. Fix a calendar for quarterly meetings and annual reviews.

    OutputsApproved policiesCommittee chartersGovernance calendar
  3. 3

    Assess gaps requirement by requirement

    Map current practice against each chapter and each of the 31 baseline areas. Record every gap with an owner, a target date and a risk rating on the bank’s scale.

    OutputsGap registerOwners and dates
  4. 4

    Remediate the baseline controls

    Close gaps in order of risk, starting with critical systems. Build the recurring work into operations: six-monthly vulnerability assessments and annual penetration tests for critical and customer-facing DMZ systems, half-yearly disaster recovery drills, periodic access and log reviews.

    OutputsRemediation planTesting schedule
  5. 5

    Build detection and response

    Set up or contract the Cyber Security Operations Centre. Approve the incident response policy and the Cyber Crisis Management Plan. Rehearse the six-hour reporting route to RBI on DAKSH and the notification to CERT-IN.

    OutputsCSOC modelIncident response policyCCMP
  6. 6

    Bring third parties into scope

    Risk-assess IT and cybersecurity vendors. Update contracts with the bank’s right to audit, RBI’s right to inspect, data location terms and personnel checks. Apply the baseline controls to any ATM Switch Application Service Provider.

    OutputsVendor risk assessmentsUpdated contracts
  7. 7

    Establish assurance and reporting

    Approve the IS Audit Policy and a risk-based audit plan. Set up quarterly CISO reporting, quarterly VA/PT closure reporting, and key performance and risk indicators, including recovery objectives for critical systems.

    OutputsIS Audit PolicyAudit planBoard and committee packs
  8. 8

    Keep it running and inspection-ready

    Run the annual reviews and training, track amendments to the Directions, and keep the evidence for each requirement current, so that a supervisory review finds a record of continuous work, not a file assembled for the occasion.

    OutputsEvidence libraryAnnual review records

Audit and evidence guide

What auditors look for, and the evidence to keep

Compliance is reviewed through RBI’s supervision of the bank and through the bank’s own information systems audit, which the Audit Committee of the Board oversees. Reviewers look for proof that each requirement operates, at the frequency the Directions set.

What reviewers look for

  • Board and committee minutes showing approvals and reviews at the required frequency
  • A cybersecurity policy that is distinct from the IT and information security policy
  • The CISO’s level, independence from the Head of IT and reporting line to the Executive Director overseeing risk
  • How critical systems were identified and how the stricter requirements were applied to them
  • Vulnerability assessment and penetration testing reports, and how findings were tracked to closure
  • Disaster recovery drill records, including running the recovery site as primary for a full working day
  • Incident records showing detection time and reporting to RBI on DAKSH within six hours, and to CERT-IN
  • Third-party contracts with audit and inspection rights, and evidence of ongoing due diligence
  • CSOC monitoring, staffing and escalation in practice
  • An IS Audit Policy, a risk-based audit plan and follow-up of audit findings

Recurring obligations and timelines

Board review of IT, information security, cybersecurity and BCP policiesAt least annually
IT Strategy Committee meetingsAt least quarterly
IT Steering Committee meetingsAt least quarterly
CISO review of cyber risk before the Board, RMCB or ITSCAt least quarterly
Vulnerability assessment of critical and customer-facing DMZ systemsAt least every 6 months
Penetration testing of the same systemsAt least every 12 months
VA/PT closure status to ITSC and Information Security CommitteeAt least quarterly
Disaster recovery drills for critical systemsAt least half-yearly
IT architecture review by the ITSCAt least annually
Review of BCP and DR by the ITSCAt least annually
IS Audit Policy review by the Audit CommitteeAt least annually
Training for Board members and senior managementAnnually
Cyber incident reporting to RBI on DAKSHWithin 6 hours of detection

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Governance

  • Board and committee minutes
  • Approved policies with version history
  • IT Strategy Committee constitution
  • CISO appointment and reporting line

Risk management

  • IT and information security risk register
  • Critical systems list and rationale
  • Risk assessments and treatment decisions

Baseline controls

  • Asset inventory
  • Secure configuration baselines
  • Patch and change records
  • Access and privileged access reviews
  • Log review records

Testing

  • VA and PT reports
  • Findings closure tracker
  • Red team reports, where run
  • DR drill reports

Incident response

  • Incident register with detection and reporting times
  • DAKSH and CERT-IN submissions
  • Cyber Crisis Management Plan
  • Post-incident reviews

Third parties

  • Vendor risk assessments
  • Contracts with audit and inspection clauses
  • Background check and NDA confirmations

Operations centre

  • Monitoring and escalation records
  • Staffing roster across levels
  • Threat intelligence briefings to the Board or ITSC

IS audit

  • IS Audit Policy and approvals
  • Risk-based audit plan
  • Audit reports and action tracking

Areas that often need attention

  • Policies approved once but not reviewed on schedule
  • Cybersecurity policy folded into the IT policy instead of kept separate
  • CISO reporting lines that conflict with the independence requirements
  • VA/PT findings open with no tracked closure or committee reporting
  • DR drills that never run the recovery site as primary for a full day
  • Incident detection times not recorded, so six-hour reporting cannot be shown
  • Third-party contracts without audit or inspection rights
  • Evidence scattered across email and shared drives at inspection time

How Netra helps

Where each part of the work lives in Netra

Netra loads the Commercial Banks Direction as requirements, tasks and policies. Each part of the work then lives in the module built for it, on one record.

Every requirement owned and tracked

Task Engine

Requirements arrive as tasks with owners and due dates. Recurring tasks cover quarterly, half-yearly and annual obligations so that evidence stays current.

Live status for each chapter and requirement

Compliance Centre

Status is derived from completed tasks and evidence, never typed in, so every figure traces back to the work.

Board-approved policies and annual reviews

Policy Hub

A policy library generated at onboarding, with review dates and a score that rises as the work behind each policy is done.

IT and information security risk register

Risk Manager

Inherent and residual heatmaps, with risks reduced as the linked tasks are completed.

Third-party arrangements

Third-Party Risk

Find vendors from what Accounts and Purchase pay, assess them through a vendor portal and record each decision with a defensible rating.

IS audit and supervisory reviews

Audit Centre

Run internal and regulatory audits end to end, with findings and corrective actions, using evidence already in a tamper-evident vault.

Reporting to the Board and committees

Dashboard & Reports

A live Posture Score and a one-click board report for the Direction, built from live data.

Knowing which systems a requirement touches

Asset Management

Assets linked to tasks, so teams know where to act and which evidence applies.

Netra organises the work, evidence and reviews. It is not a SIEM, an operations centre or a reporting channel to RBI, and it does not by itself establish compliance. The bank remains responsible for implementation and regulatory interpretation.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Financial services

RBI CTRRAF 2026 - Urban Co-operative Banks

Make cyber compliance manageable for your UCB team

Financial services

RBI CTRRAF 2026 - Small Finance Banks

Keep security assurance aligned with your SFB operations

Financial services

DORA

Keep digital resilience work ready for review

See RBI CTRRAF 2026 - Commercial Banks in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.