India's Reserve Bank of India issued the Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions 2026 on July 31, 2026, with immediate effect — replacing all prior cybersecurity circulars for commercial banks. If your bank's IT and security teams have not yet mapped these 233 paragraphs to your current controls, this checklist gives you the prioritised action plan to start today.

What Has Changed and Why It Matters

The RBI's 2026 framework is not an incremental update — it is a comprehensive, legally binding replacement of everything that came before. Unlike the older 2016 circular, this direction names specific roles (CISO, Head of IT, ITSC), mandates exact frequencies (quarterly ITSC meetings, half-yearly DR drills, 6-hour incident reporting on DAKSH), and extends accountability to ATM Switch ASPs and all third-party IT vendors. Non-compliance is not a technicality risk; it is a supervisory risk that will surface in IS audits and RBI inspections.

Governance Checklist: Board and Committee Structure

The direction makes board-level IT governance mandatory, not optional. Use this checklist to confirm your governance architecture is compliant.

• Board Approved Policies (Para 7–8): Confirm your Board has formally approved policies for IT Strategy, Information Security, Cybersecurity, Business Continuity, and Incident Response. These must be reviewed at least annually by the Board.
• IT Strategy Committee of the Board – ITSC (Para 16–19): The ITSC must have a minimum of 3 directors. The Chairperson must be an independent director with at least 7 years of IT management experience. The ITSC must meet at least quarterly. If yours meets only annually, that is a gap.
• IT Steering Committee – Senior Management (Para 21–22): A separate IT Steering Committee at Senior Management level, with IT and business representation, must also meet at least quarterly and report to the ITSC and MD/CEO.
• Information Security Committee – ISC (Para 23): The ISC must be formed under ITSC oversight. Its head must come from the risk management function — not IT. The CISO is a member, not the head.
• CISO Appointment and Independence (Para 27–28): The CISO must be at General Manager rank or equivalent. Critically, the CISO must have no direct reporting relationship to the Head of IT and must not be given business targets. The CISO reports directly to the Executive Director overseeing risk management and must present a quarterly cybersecurity review to the Board/RMCB/ITSC.
• Head of IT Function (Para 24–26): Must be technically competent and senior. Responsible as the first line of defence for IT controls.

Baseline Security Controls Checklist (Chapter V — The Core of the Framework)

Chapter V of the directions contains the largest compliance surface — 30 control domains spanning paragraphs 47 to 211. Below are the highest-priority items with their paragraph references so your team can locate the exact requirement.

Asset and Data Management

• Information Asset Inventory (Para 47–50): Maintain an up-to-date, centralised inventory of all information assets including hardware, software, network devices, and services. Include business criticality ratings. Maintain an enterprise data dictionary (Para 49).
• Data Leak Prevention (Para 51–54): DLP strategy must cover endpoint, data in transit, and data at rest — including at vendor-managed facilities. Implement remote wipe/locking capability for mobile devices including laptops (Para 54).
• Data Migration Policy (Para 55): Formal policy required for data migration with mandatory audit trails and sign-offs from business users and application owners at each migration stage.

Network and Endpoint Controls

• Authorised Software Only (Para 56–59): Centralised, up-to-date inventory of authorised software. Application whitelisting recommended. Mechanism to block unauthorised software on PCs, laptops, servers, mobile devices, and cloud environments. Emergency patch process for actively exploited critical vulnerabilities.
• Secure Configuration (Para 66–67): Documented baseline security configurations for all device categories — endpoints, mobile, OS, databases, applications, network devices, and security systems — reviewed periodically throughout the lifecycle.
• Network Security (Para 68–78): Up-to-date network architecture diagram at org level. Centralised inventory of authorised devices. Multi-layered boundary defences — firewalls, proxies, DMZ, IPS/IDS. Mechanism to automatically identify and block unauthorised device connections. IPv6 readiness for public-facing infrastructure (Para 78).
• Physical and Environmental Controls (Para 60–63): DC and DR sites must be geographically separated. Both must have e-surveillance. Environmental monitoring for temperature, water, smoke, access alarms, and power.

Application Security

• Application Security Life Cycle (Para 79–92): Security must be embedded across the entire SDLC — not bolted on post-deployment. Threat modelling, secure coding practices aligned with OWASP (but not limited to OWASP Top 10 — Para 85), security testing in environments resembling production. Separate dev/test/production environments (Para 82).
• Source Code and Vendor Assurance (Para 90–92): Obtain source code (or source code escrow arrangement) for all critical applications. Get a written certificate from the vendor that the application is free of known vulnerabilities and malware — and repeat this certificate requirement for every material change.

Access Control and Identity

• Least Privilege and Need-to-Know (Para 104–113): Access only where a valid business need exists. No administrative rights on end-user devices. Centralised authentication and authorisation system covering applications, OS, databases, network devices, and local/remote connectivity.
• Multi-Factor Authentication (Para 110): MFA is mandatory for privileged users of critical information systems and critical activities. Risk-based MFA for other access.
• Privileged Access Management (Para 111): Centralised PAM controls to allow, manage, log, and monitor all privileged/superuser/administrative access.
• Teleworking Controls (Para 114): Remote access systems must be secure. MFA mandatory for enterprise access to critical systems from alternate locations. All remote-access devices must be identified and registered.

Email, Messaging and Anti-Phishing

• Email Security (Para 117–120): Implement DMARC for all email domains (Para 120). Controls against spoofing, look-alike domains, malicious attachments, and spam. Require vendors and partners to implement equivalent email security measures.
• Anti-Phishing (Para 148): Subscribe to anti-phishing and anti-rogue-app services from external providers for detection and takedown of phishing websites and rogue mobile applications.

Third-Party and Vendor Risk

• Third-Party Risk Programme (Para 126–135): Formal vendor risk assessment process addressing concentration risk, single point of failure, supply chain risks, and regulatory compliance. Contracts must include right-to-audit by both the bank and RBI. Background checks and NDAs are mandatory for all third-party personnel accessing critical assets.
• ATM Switch ASP Controls (Para 136–139): Banks using third-party ATM Switch ASPs must contractually mandate 24 specific controls — from network segregation and IAM to VAPT, SIEM, CSOC setup, and PCI-DSS compliance. These controls must be written into the contract agreement.

VAPT Requirements Checklist

The directions are unusually prescriptive about Vulnerability Assessment and Penetration Testing — making it one of the clearest compliance checkboxes.

• Critical and internet-facing systems (Para 151): VA at least every 6 months. PT at least every 12 months.
• Non-critical systems: Risk-based approach to frequency.
• Post-implementation testing (Para 152): VA/PT required after every IT project completion or system upgrade, in an environment resembling production. Any deviation from production must be documented and approved by the ISC.
• CERT-In empanelled auditors (Para 159): For CERT-In empanelled auditors, the bank shall follow CERT-In's Comprehensive Cyber Security Audit Policy Guidelines.
• Auditor accountability (Para 158): If a system that passed VAPT is later compromised due to a vulnerability that was not identified, that is classified as a deficiency of the auditor and must be factored in contract renewal decisions.
• Quarterly reporting (Para 161): Status of VA/PT observation closures must be placed before the ITSC and ISC at least quarterly.
• CVSS scoring (Para 154): Use a documented vulnerability scoring mechanism such as CVSS for all VA/PT programmes.

Incident Response and CCMP Checklist

According to the RBI framework, a Cyber Crisis Management Plan (CCMP) is mandatory and must be Board-approved as part of the overall cybersecurity framework.

• Cyber Incident Response Policy (Para 175): Must cover incident classification, roles and responsibilities, customer reporting mechanisms, communication strategy, containment measures, threat intelligence sharing, post-incident review, and periodic testing of response plans.
• 6-Hour Reporting Obligation (Para 182): All cyber incidents must be reported on the DAKSH platform (https://daksh.rbi.org.in) within 6 hours of detection. Proactive notification to CERT-In is also required.
• Cyber Crisis Management Plan (Para 192–193): The CCMP must address Detection, Containment, Response, and Recovery. It must specifically address zero-day attacks, ransomware, DDoS, destructive malware, business email fraud (spear phishing, whaling, vishing), and identity/password frauds.
• Threat Intelligence Sharing (Para 185–186): Banks must participate in threat intelligence sharing with IDRBT's IB-CART and coordinate with CERT-In, telecom service providers, and RBI as required.
• Digital Forensics Standby (Para 211): Network forensics and DDoS mitigation services must be maintained on standby — not engaged only after an incident.

Business Continuity and DR Checklist

• DR Drill Frequency (Para 165): Critical information systems: DR drills at least half-yearly. Other systems: risk-based frequency.
• Full Working Day Switchover (Para 167): DR testing must include actual switchover to the DR site used as the primary site for at least a full working day, covering Beginning of Day to End of Day operations.
• RTO/RPO Targets (Para 170–171): Defined RTO and RPO for all critical systems. The direction specifically calls for minimal RTO and near-zero RPO for critical information systems.
• DC and DR Configuration Parity (Para 173): Configurations and security patches at DC and DR sites must be identical.
• Backup Integrity (Para 169): Periodic restoration testing of backed-up data. Backup data must be secured from unauthorised access.

CSOC Requirements Checklist

A Cyber Security Operations Centre is mandatory. The framework specifies three operational tiers of staff capability required within the CSOC.

• Level 1 (Para 221): Round-the-clock monitoring by trained personnel with relevant vendor/product certifications.
• Level 2: Specialised expertise in network, data, and endpoint security for root cause analysis and corrective actions.
• Level 3: Advanced SOC analysts — deep packet analysis, IOC collection, forensic evidence collection, malware reverse engineering, custom script development.
• Technology requirements (Para 215–220): SIEM for log correlation and continuous monitoring. Security analytics engine capable of wire-speed deep packet inspection. Malware detection and analysis tools. Honeypot services. Real-time dashboards with IP geo-location visibility. Ticketing, case management, and workflow integration.

Patch Management Checklist

• Documented policy (Para 98): Business impact assessment before applying or withholding a patch. Rollback mechanism for failed patches. All changes must be justified by business needs and documented.
• Critical vulnerability patches (Para 58): Emergency patch management process required for actively exploited vulnerabilities identified in CERT-In advisories or OEM releases.
• End-of-Support monitoring (Para 37–38): Monitor EOS dates for all software and hardware AMC dates. Technology refresh plan must be in place before assets reach EOS.

Metrics and Awareness Checklist

• Security Metrics (Para 194–197): Define KPIs and KRIs — including anti-malware coverage, patch latency, vulnerability metrics, and user awareness training coverage. IT performance scorecard and maturity level measurement.
• Employee Training (Para 203): Cybersecurity awareness is mandatory for all new recruits. Annual training for lower and middle management. Annual training for Board members and Senior Management on IT and cybersecurity risks (Para 204).
• Customer Education (Para 205–208): Proactive customer awareness on phishing, OTP/password sharing risks. Mechanism for customers to report phishing sites with bank follow-up action.
• Transaction Monitoring (Para 209–210): Risk-based transaction monitoring across all delivery channels. Customer notification via alternate channel for all fund transfers above a customer-defined threshold.

Key Takeaways

• The RBI Cybersecurity Directions 2026 are effective immediately — there is no transition grace period specified. Banks should treat July 31, 2026 as day zero.
• The CISO must be independent of IT operations — reporting to risk management, not the Head of IT. If your current structure has the CISO reporting to the CTO/CIO, it is a direct gap under Para 27.
• Third-party vendors are inside your compliance perimeter — particularly ATM Switch ASPs who must contractually meet 24 specified controls (Para 136–138).
• 6-hour incident reporting on DAKSH is a hard deadline — not a target. SOC and CERT-In notification processes must be automated and pre-tested.
• VAPT findings closure is now a board-level agenda item — quarterly status reports to ITSC and ISC are mandatory (Para 161).
• A full DR switchover — operating from the DR site for a minimum of a complete working day — is required at least twice a year for critical systems (Para 165, 167).

Frequently Asked Questions

Does this framework apply to all banks in India?

The RBI Cybersecurity Directions 2026 apply to Commercial Banks as defined under the Banking Regulation Act, 1949. This includes nationalised banks, the State Bank of India, and private sector banks — but excludes Small Finance Banks, Payments Banks, and Local Area Banks. Foreign banks operating through branches in India are subject to a 'comply or explain' approach for specific chapters and paragraphs (Para 4).

What is the difference between the ITSC and the ISC under the new directions?

The IT Strategy Committee (ITSC) is a Board-level body that provides governance and strategic oversight of IT across the bank. The Information Security Committee (ISC) is an operational-level committee under ITSC oversight that manages day-to-day cybersecurity — developing policies, approving security projects, reviewing incidents, and reporting to the ITSC and MD/CEO. The CISO's office manages and monitors the SOC and drives cybersecurity projects under the ISC.

How quickly must a bank report a cyber incident to RBI?

Under Para 182, banks must report cyber incidents within 6 hours of detection on the DAKSH platform (https://daksh.rbi.org.in). Banks must also proactively notify CERT-In of incidents. There is no minimum severity threshold stated — the obligation applies broadly to cyber incidents as defined in the framework.

Achieving compliance with the RBI Cybersecurity Directions 2026 across all 233 paragraphs requires mapping your current controls, identifying gaps, and executing a prioritised remediation plan — all while maintaining live operations. White Aegis Governance, Risk & Compliance services help banks translate complex regulatory frameworks into actionable implementation roadmaps, from governance structure design to VAPT programme management and CSOC readiness assessments. Contact us for a free consultation at https://www.whiteaegis.com/#contact — our team of GRC specialists works directly with banking IT and security teams to close compliance gaps efficiently and sustainably.