The Reserve Bank's 2016 circular tells banks to adopt a Board-approved cyber security policy, run a Security Operations Centre and a Cyber Crisis Management Plan, and report cyber incidents. Its Annex 1 sets 24 areas of baseline controls, from asset inventory to customer education.
Free account needed to download. You come straight back to the file.
Who it is for. All scheduled commercial banks other than Regional Rural Banks, as the circular was addressed. Other regulated entities should check what RBI has issued for them.
What this list covers. RBI circular RBI/2015-16/418, DBS.CO/CSITE/BC.11/33.01.001/2015-16 of 2 June 2016. The circular body was read on RBI's notification page and Annexes 1 to 3 from an Internet Archive copy (January 2022) of RBI's own PDFs; RBI may have amended or replaced parts since, so check its site for the current text: 163 requirements. Each has a reference, a heading and a sentence in plain English.
| Ref | Control | What it requires |
|---|---|---|
| Para 3 | Board-approved cyber security policy | Have the Board approve a cyber security policy that sets the strategy for countering cyber threats, matched to your business complexity and risk appetite. The circular asked banks to confirm this to RBI's CSITE Cell by 30 September 2016. |
| Para 4 | Keep it separate from the IT policy | Write the cyber security policy as its own document, apart from the wider IT or information security policy, so it can spell out cyber risks and the measures that address them. |
| Para 5 | Assess inherent cyber risk and controls | Judge inherent risk from your technology, connections, channels, products, services, culture and threats, and rate it (low to very high, or similar). Then evaluate the controls, from Board oversight to incident response. |
| Para 6 | Continuous surveillance and a SOC | Test for vulnerabilities at sensible intervals. Set up a Security Operations Centre at the earliest if you lack one, and make sure it watches continuously and keeps up with emerging threats. |
| Para 7 | Security-friendly IT architecture | Design the IT architecture so security measures can always be applied. The Board's IT Sub-Committee reviews it, upgrades follow your risk assessment, and risk-versus-cost trade-off decisions are written down for supervisors. |
| Para 8 | Implement the baseline and start the SOC | Put the Annex 1 minimum baseline in place (it is indicative, not exhaustive), and proactively start setting up a SOC to monitor and manage cyber risk in real time, using the Annex 2 outline. |
| Para 9 | Network and database security | Review network security thoroughly. Allow no unauthorised access to networks or databases. Where access is allowed for a time, follow a defined process, close it afterwards, and keep responsibility with the bank's own officials. |
| Para 10 | Protect customer information | Preserve the confidentiality, integrity and availability of customer and other sensitive data wherever it sits (with you, customers or vendors), using suitable systems and processes across the whole data lifecycle. |
| Para 11 | Cyber Crisis Management Plan | Develop a Cyber Crisis Management Plan as part of the Board-approved strategy. Revisit BCP and DR for the nuances of cyber risk, and draw on CERT-In, NCIIPC, RBI and IDRBT guidance. |
| Para 12 (aspects) | Cover detection, response, recovery, containment | Make the plan address detection, response, recovery and containment: prevent attacks where you can, spot intrusions promptly, and respond to, recover from and contain the fallout. |
| Para 12 (threats) | Be ready for named cyber threats | Prepare for zero-day, remote access and targeted attacks, and take preventive and corrective steps against DDoS, ransomware, destructive malware, business email fraud, phishing, vishing, drive-by downloads and identity or password fraud. |
| Para 13 | Preparedness indicators and independent checks | Develop indicators of risk and preparedness to measure how adequate your cyber resilience framework is and how well it is followed. Test with independent compliance checks and audits by qualified professionals; staff awareness may be included. |
| Para 14 | Report unusual cyber incidents to RBI | Report all unusual cyber security incidents to the Reserve Bank, whether the attack succeeded or was only attempted. |
| Para 14 (IB-CART) | CISOs' Forum and IB-CART | Take part in the CISOs' Forum run by IDRBT and promptly report incidents to IB-CART. The circular encourages this, to build shared threat intelligence and timely alerts. |
| Para 15 | Supervisory incident reporting | Report information security and cyber incidents promptly to RBI in the format of Annex 3. RBI collects both summary and detailed information. |
| Para 16 | Gap assessment under Board oversight | Find material control gaps early and fix them under the guidance of the Board's IT Sub-Committee and the Board. The CISO was to send RBI the gaps, planned measures, timelines and effectiveness measures by 31 July 2016. |
| Para 17 | Organisational arrangements | Review how the organisation is arranged so that security concerns are understood, get enough attention and are escalated to the right level quickly. |
| Para 18 (internal) | Awareness for staff, management and Board | Build a high level of cyber awareness among staff at every level, and familiarise top management and the Board with the finer points of the threats, bringing them up to speed where needed. |
| Para 18 (external) | Awareness for customers, vendors and partners | Promote an understanding of your cyber resilience objectives among customers, vendors, service providers and other stakeholders, and require and ensure action that supports joint implementation and testing. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 1.1 | Keep an asset inventory | Keep a current inventory of data (customer data included), applications, supporting IT and facilities, hardware, software, network devices, key people and services, each marked for business criticality. You may set your own criteria for critical assets. |
| Annex 1 - 1.2 | Classify data | Classify data and information using the bank's own classification or sensitivity criteria. |
| Annex 1 - 1.3 | Protect data inside and outside the network | Manage and protect data within and beyond the network boundary, based on how it is stored, sent, processed, accessed and used, and how exposed it is, given its sensitivity. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 2.1 | Software inventory and allow-listing | Keep a current, preferably central, inventory of authorised and unauthorised software. Consider allow-listing approved applications, software and libraries. |
| Annex 1 - 2.2 | Control software installation | Control installation of software on PCs, laptops, workstations, servers and mobile devices, centrally or otherwise, and be able to block and spot unauthorised software being installed or run. |
| Annex 1 - 2.3 | Apply patches expeditiously | Track vendor patches and CERT-In advisories and apply security patches promptly under the patch policy. Keep an emergency process for patches that close well-known, actively exploited flaws. |
| Annex 1 - 2.4 | Framework for exceptions | Define how exceptions are justified, time-limited, approved and periodically reviewed, naming who approves and who reviews. Reviewers should be senior people who understand the business and technical context. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 3.1 | Protect the location of critical assets | Put suitable environmental controls around critical assets, protecting them from natural and man-made threats. |
| Annex 1 - 3.2 | Monitor environmental controls and physical security | Monitor for breaches of controls on temperature, water, smoke, access alarms, power, telecom and server availability, and access logs, and apply physical security measures to protect critical assets. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 4.1 | Network architecture diagram | Prepare and keep current a network architecture diagram for the whole organisation, wired and wireless. |
| Annex 1 - 4.2 | Inventory of authorised network devices | Keep a current, central inventory of authorised devices connected to the network, on or off premises, and of the devices that enable the network. Consider tools that automate network discovery and management. |
| Annex 1 - 4.3 | Configure and review network devices | Configure all network devices appropriately and periodically assess whether the configurations still give the level of network security you want. |
| Annex 1 - 4.4 | Secure wireless networks | Put suitable controls on wireless LANs, wireless access points and wireless client access systems. |
| Annex 1 - 4.5 | Admit only compliant authorised devices | Be able to identify authorised laptops, phones, tablets and similar devices, and connect them only when they meet the bank's security requirements. |
| Annex 1 - 4.6 | Block unauthorised devices automatically | Have a mechanism that automatically spots devices connecting to the network without authorisation and blocks them. |
| Annex 1 - 4.7 | Detect and fix unusual activity | Put in place a way to detect and remedy unusual activity on systems, servers, network devices and endpoints. |
| Annex 1 - 4.8 | Standard operating procedures | Establish standard operating procedures for all major IT activities, including connecting devices to the network. |
| Annex 1 - 4.9 | SOC monitors network logs | Have the Security Operations Centre monitor logs of network activity and be able to escalate abnormal or undesirable activity. |
| Annex 1 - 4.10 | Multi-layered boundary defences | Layer the boundary defences: properly configured firewalls, proxies, DMZ perimeter networks and network-based IPS and IDS. Filter both inbound and outbound traffic. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 5.1 | Baseline security configurations | Document and apply baseline security configurations for every category of device and system, across its life from design to deployment, and review them periodically. |
| Annex 1 - 5.2 | Review critical device configuration and patches | Periodically evaluate configurations and patch levels of critical devices such as firewalls, switches and security devices, including in data centres, third-party hosted sites and shared-infrastructure locations. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 6.1 | Security across the application life cycle | Build information security into every stage of the application life cycle. |
| Annex 1 - 6.2 | Source code audit or vendor assurance | For critical business applications, consider source code audits by competent people or providers, or get assurance from the provider or OEM that the application carries no hidden malicious or fraudulent code. |
| Annex 1 - 6.3 | Secure coding practices | Consider applying secure coding practices to applications developed in-house or jointly with others. |
| Annex 1 - 6.4 | Specify security requirements early | Beyond business functions, specify security needs clearly from the start and throughout development or purchase: access control, authentication, transaction authorisation, integrity, logging, audit trail, sessions, event tracking and exceptions. |
| Annex 1 - 6.5 | Separate environments | Keep development, test and production environments properly separate. |
| Annex 1 - 6.6 | Threat modelling and security testing | Base development on threat modelling, secure coding principles and security testing against global standards, followed by a secure rollout. |
| Annex 1 - 6.7 | OWASP baselines and defence in depth | Tackle vulnerabilities proactively using best-practice baselines such as OWASP, and apply defence in depth for layered security. |
| Annex 1 - 6.8 | Containerised mobile apps | Consider a containerised, encrypted business app on smartphones, kept apart from personal data and apps, with the ability to wipe that container remotely and make the data unreadable. |
| Annex 1 - 6.9 | Evaluate new technology first | Assess new technologies for existing and emerging security threats. IT and security teams should reach reasonable comfort and maturity before using them for critical systems. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 7.1 | Risk-based patching strategy | Follow a documented, risk-based approach to listing the IT components to patch, finding patches and applying them, so that fewer systems are vulnerable and for a shorter time. |
| Annex 1 - 7.2 | Track patch status | Have systems and processes to identify, track, manage and monitor patch status for internet-connected end-user devices and for server operating systems, databases, applications and middleware. |
| Annex 1 - 7.3 | Configuration management for changes | Manage changes to applications, supporting technology, service components and facilities through robust configuration management and baselines that keep the changes trustworthy. |
| Annex 1 - 7.4 | VA/PT of internet-facing assets | Periodically run vulnerability assessment and penetration testing on internet-facing web and mobile applications, servers and network components throughout their life, including before and after go-live and after changes. |
| Annex 1 - 7.5 | Application security testing | Periodically test the security of web and mobile applications across their life, in an environment that closely resembles or replicates production. |
| Annex 1 - 7.6 | Root cause and patch after incidents | As a threat mitigation step, find the root cause of an incident and apply the patches that close the weakness. |
| Annex 1 - 7.7 | Review access device configuration | Periodically check configuration and patch levels of access devices, so that points between data centre VLANs, LAN/WAN interfaces, the external network, and partner, vendor and provider links are securely set up. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 8.1 | Secure access from anywhere | Give secure access to assets and services from inside or outside the network, protecting data at rest (for example encryption where the device supports it) and in transit (for example VPN or secure web protocols). |
| Annex 1 - 8.2 | Protect customer access credentials | Guard customers' logon IDs, authentication information, tokens and access profiles against leakage and attack. |
| Annex 1 - 8.3 | No admin rights on end-user machines | Disallow administrative rights on workstations, PCs and laptops. Give access on a need-to-know basis, for a set duration, through an established process. |
| Annex 1 - 8.4 | Central authentication and authorisation | Use central authentication and authorisation for applications, operating systems, databases, and network and security devices, with strong passwords, 2FA or MFA based on risk, least privilege and separation of duties. |
| Annex 1 - 8.5 | Control privileged access | Use suitable, for example central, systems and controls to allow, manage, log and monitor privileged, superuser and administrative access to critical servers, operating systems, databases, applications and network devices. |
| Annex 1 - 8.6 | Invalid logons and dormant accounts | Put controls in place to minimise invalid logon counts and to deactivate dormant accounts. |
| Annex 1 - 8.7 | Watch logon patterns | Monitor for any abnormal change in the pattern of logons. |
| Annex 1 - 8.8 | Control installation on PCs and laptops | Implement measures to control software installation on PCs, laptops and similar devices. |
| Annex 1 - 8.9 | Remote management of mobile devices | Have controls to manage, wipe or lock mobile devices, including laptops, remotely. |
| Annex 1 - 8.10 | Control macros and email attachment types | Put measures in place to control the use of VBA and macros in office documents, and to limit the attachment types email systems allow. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 9.1 | Bank-to-customer identity verification | Provide a framework or mechanism that lets customers positively verify the identity of the bank. |
| Annex 1 - 9.2 | Secure customer identity information | Keep customer identity information secure. |
| Annex 1 - 9.3 | Bank as identity provider | Act as the identity provider for identifying and authenticating customers who access partner systems, using secure authentication technologies. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 10.1 | Secure email and messaging | Run secure email and messaging, including those of partners and vendors, with measures against spoofing, look-alike mail domains, risky attachments and malicious links. |
| Annex 1 - 10.2 | Email server controls | Document and apply controls specific to email servers. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 11.1 | Accountability for outsourced security risk | Stay accountable for managing, and getting assurance on, security risk in outsourced and partner arrangements. |
| Annex 1 - 11.2 | Weigh outsourcing and pick vendors on risk | Carefully weigh the need to outsource critical processes, and choose vendors and partners on a thorough risk assessment. |
| Annex 1 - 11.3 | Due diligence and oversight | Regularly do effective due diligence on third-party vendors, service providers and partners, and oversee and manage them. |
| Annex 1 - 11.4 | Vendor risk framework | Set a framework, policies and procedures, backed by baseline system security standards, to evaluate, approve, review, control and monitor the risk and materiality of all vendor and outsourcing activity. |
| Annex 1 - 11.5 | Provider compliance and audit rights | Make sure, and be able to show, that service providers (another bank included) meet the country's legal and regulatory requirements. Contracts should give the bank audit rights and regulators inspection rights. |
| Annex 1 - 11.6 | RBI access to information resources | Make all information resources the bank uses, online or in person, available to RBI officials when asked, even where the infrastructure is not on the bank's premises. |
| Annex 1 - 11.7 | Data location and cross-border rules | Follow the legal and regulatory requirements on where infrastructure sits and on moving data out of the country. |
| Annex 1 - 11.8 | Vet third-party personnel | Be thoroughly satisfied about the credentials of vendor and third-party staff who access and manage the bank's critical assets. |
| Annex 1 - 11.9 | Background checks and agreements | Require background checks, non-disclosure agreements and security policy compliance agreements for all third-party service providers. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 12.1 | Removable media and BYOD policy | Set and apply a policy restricting and securing the use of removable media and BYOD across device types, including secure erasure of data on the media after use. |
| Annex 1 - 12.2 | Limit what can be copied | Limit the media types, and the information, that can be transferred to or from such devices. |
| Annex 1 - 12.3 | Scan media before use | Scan removable media for malware before giving read or write access. |
| Annex 1 - 12.4 | Central policy for removable media | Consider central policies, through Active Directory or endpoint management, to allow, block or restrict removable media. |
| Annex 1 - 12.5 | Default ban on removable media | As a default, do not permit removable devices and media in the banking environment unless authorised for a defined use and duration. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 13.1 | Defend against malicious code | Build a robust defence against malicious code being installed, spreading and executing, at several points across the enterprise. |
| Annex 1 - 13.2 | Anti-malware with behavioural detection | Deploy anti-malware and antivirus, including behavioural detection, on all device types, servers, web and email gateways, wireless networks and SMS servers, with central management and monitoring. |
| Annex 1 - 13.3 | Allow-list websites and systems | Consider allow-listing internet websites and systems. |
| Annex 1 - 13.4 | Secure web gateways | Consider secure web gateways that can deep-scan network packets, including encrypted HTTPS traffic, passing through the gateway. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 14.1 | Anti-phishing and rogue app services | Subscribe to external anti-phishing and anti-rogue-app services that identify and take down phishing websites and rogue applications. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 15.1 | Data loss prevention strategy | Develop a comprehensive strategy to prevent loss or leakage of sensitive, including confidential, business and customer data. |
| Annex 1 - 15.2 | Cover endpoints, transit and storage | Cover data processed on endpoint devices, data in transit, and data stored on servers and other digital stores, online or offline. |
| Annex 1 - 15.3 | Same arrangements at vendors | Make sure similar arrangements apply at vendor-managed facilities. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 16.1 | Consult stakeholders on log scope | Consult all stakeholders before settling the scope, frequency and storage of log collection. |
| Annex 1 - 16.2 | Analyse audit logs systematically | Manage and analyse audit logs in a systematic way, so you can detect, understand or recover from an attack. |
| Annex 1 - 16.3 | Capture user actions for forensics | Take care to capture logs of user actions in systems, in a way that can support forensic audit if needed. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 17.1 | Set and validate logging | Set up, and periodically validate, logging on every device, system and application, so entries carry enough detail to be identified uniquely, such as date, timestamp and source and destination addresses. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 18.1 | Periodic VA/PT of critical systems | Periodically run vulnerability assessment and penetration testing on all critical systems, particularly those facing the internet. |
| Annex 1 - 18.2 | Remedy vulnerabilities promptly | Fix the vulnerabilities found promptly, under the bank's risk management or treatment framework, so they cannot be exploited. |
| Annex 1 - 18.3 | Qualified penetration testers | Have professionally qualified teams penetration-test public-facing systems and other critical applications. |
| Annex 1 - 18.4 | Track VA/PT findings | Have the information security or IT audit team, and senior or top management, closely monitor VA/PT findings and the follow-up actions. |
| Annex 1 - 18.5 | Red team exercises | Consider red teams that simulate an attacker's aims and actions to find vulnerabilities and business risk, assess the defences and test existing mitigating controls. |
| Annex 1 - 18.6 | Take part in cyber drills | Periodically and actively take part in cyber drills run under CERT-In, IDRBT and similar bodies. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 19.1 | Incident response programme | Put in place a fully effective incident response programme approved by the Board or top management. |
| Annex 1 - 19.2 | Written response procedures | Write response procedures naming the roles of staff and outsourced staff. Plan responses for different scenarios from situational awareness and impact, with consistent communication and coordination with stakeholders. |
| Annex 1 - 19.3 | Learn from incidents | Have a way to bring lessons learnt into the response strategies continually. |
| Annex 1 - 19.4 | BCP/DR supports cyber resilience | Design BCP and DR so you can recover rapidly from cyber attacks and other incidents and safely resume critical operations within recovery time objectives, keeping processes and data secure. |
| Annex 1 - 19.5 | Resilience across partners and vendors | Ensure that capability across all interconnected systems and networks, including vendors' and partners', and show readiness through joint, coordinated resilience tests that meet your recovery time objectives. |
| Annex 1 - 19.6 | Test crisis communication | Include crisis communication to customers and other stakeholders, and reputation management, in that testing, and plan and keep adequate capacity for it. |
| Annex 1 - 19.6(a) | Define the response programme elements | Consider defining incidents, detection and reporting methods (by staff, vendors and customers), monitoring frequency, threat sharing, expected response by type, roles, specialist training, post-incident review and regular plan tests. |
| Annex 1 - 19.6(b) | Establish a SOC | Consider setting up and running a Security Operations Centre for central, coordinated monitoring and management of security incidents. |
| Annex 1 - 19.6(c) | Collect and share threat information | Consider systems to collect and share threat information from local, national and international sources, by lawful and defined means. |
| Annex 1 - 19.6(d) | Strategies for advanced attacks | Consider documenting and communicating strategies against advanced attacks such as ransomware, cyber extortion, data destruction and DDoS. |
| Annex 1 - 19.6(e) | Contain attacks | Consider containing an attack with shielding controls or by quarantining the affected devices and systems. |
| Annex 1 - 19.6(f) | Align SOC, response and forensics | Consider a policy and framework that aligns the SOC, incident response and digital forensics, to cut business downtime and return to normal sooner. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 20.1 | Risk-based transaction monitoring | Run risk-based transaction monitoring or surveillance as part of fraud risk management across all delivery channels. |
| Annex 1 - 20.2 | Alert customers to large payments | Tell customers, through another communication channel, about payments or fund transfers above a value the customer chooses. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 21.1 | Develop cyber metrics | Develop a full set of forward-looking and backward-looking metrics, such as key performance indicators and key risk indicators. |
| Annex 1 - 21.2 | Illustrative metrics | Examples to track include anti-malware coverage and how current it is, patch latency, the extent of user awareness training, and vulnerability measures. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 22.1 | Forensic and DDoS support on stand-by | Keep support or arrangements ready for network forensics, forensic investigation and DDoS mitigation services. |
| Annex 1 - 22.2 | Join cyber drills | Periodically and actively join cyber drills under the auspices of CERT-In, IDRBT and similar bodies. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 23.1 | Security policy for users, vendors and partners | Define and share a security policy with staff, vendors and partners on secure and acceptable use of the network and assets, customer data included, teaching them the cyber risks and protections at their level. |
| Annex 1 - 23.2 | Encourage reporting of suspicious behaviour | Encourage people to report suspicious behaviour and incidents to the incident management team. |
| Annex 1 - 23.3 | Targeted training for key roles | Run targeted awareness or training for key personnel in executive, operations, security administration and management roles. |
| Annex 1 - 23.4 | Evaluate awareness periodically | Evaluate the level of awareness periodically. |
| Annex 1 - 23.5 | Adaptive capacity building | Build a way to grow cyber capability continually: mandatory awareness programmes for new recruits, and an annual web-based quiz and training for junior, middle and senior management. |
| Annex 1 - 23.6 | Sensitise Board members | Sensitise Board members periodically to technology and cyber security developments. |
| Annex 1 - 23.7 | Train Board members yearly | Give Board members training on IT and cyber risk and evolving practice, reaching all members at least once a year. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 1 - 24.1 | Customer awareness of cyber risk | Improve and maintain customer awareness and education about cyber security risks. |
| Annex 1 - 24.2 | Customer reporting of phishing | Encourage customers to report phishing mails and sites, and take effective action when they do. |
| Annex 1 - 24.3 | Warn against sharing credentials | Educate customers on the risks and consequences of sharing login credentials or passwords with any third-party vendor. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 2 - Governance | Plan C-SOC governance | Plan governance when setting up the C-SOC: threat intelligence briefings for the Board and top management, dashboards and oversight, policy, metrics and reporting lines, and informing and involving stakeholders. |
| Annex 2 - Points 1-3 | Move to proactive monitoring | Go beyond preventive, reactive tools. Build proactive monitoring and management with sophisticated detection, quick response and data-backed analytics, so zero-day and signature-less attacks are covered too. |
| Annex 2 - Point 4 | Add investigation and analysis capabilities | Beyond log collection and SIEM watching, add root cause analysis and attack classification, investigation, forensics and deep packet analysis, dynamic behaviour analysis with IOCs, geo-location analytics, and counter-response and honeypots. |
| Annex 2 - Expectations | What the SOC should deliver | Aim for a SOC that protects data and shows compliance, gives a real-time view of security posture, manages operations, assesses threat intelligence, shows who did what and when with evidence kept, and feeds all log types into SIEM and case tools. |
| Annex 2 - Responsibilities | SOC responsibilities | Give the SOC the job of monitoring, analysing and escalating incidents, developing protect-detect-respond-recover responses, handling incident management and forensics, and coordinating with internal groups and outside agencies. |
| Annex 2 - Technology | Technology building blocks | Choose cost-effective technology: log sensors placed by service architecture, a security analytics engine, deep packet inspection, and malware analysis and imaging tools for forensics, built for performance, scalability and availability. |
| Annex 2 - Process | Process building blocks | Define how the root cause of a breach is found and future attacks mitigated, along with incident, problem, vulnerability and patch, risk, availability and forensics and response management. |
| Annex 2 - People | People and staffing | Staff the SOC round the clock in tiers: trained monitors, specialists in network, data and endpoint security, and expert analysts. Plan shifts, sourcing, training, retention, performance metrics and capacity. |
| Annex 2 - External integration | Use external threat information | Draw on threat feeds from vendors and technology players, security information from other banks and the wider financial ecosystem, and input from cyber response cells, CERT-In and telecom providers. |
| Annex 2 - Model | Choose the SOC model upfront | Decide early whether the SOC is in-house or outsourced, covers only the internet-facing estate or all IT, and stands alone or is shared in a consortium, in light of risk posture. This is hard to reverse later. |
| Ref | Control | What it requires |
|---|---|---|
| Annex 3 - Timing | First report within two to six hours | Send the first Security Incident Report to RBI within two to six hours, using the template. |
| Annex 3 - Updates | Send follow-up updates | Send updates to RBI when the earlier report was incomplete (investigation under way or new information found) or when RBI asks. |
| Annex 3 - Basic 1 | Particulars of reporting | State the bank, the date and time of reporting to RBI, CERT-In and other agencies (each separately), and the reporter's name, designation, department and contact details. |
| Annex 3 - Basic 2 | Details of the incident | Give the date and time of detection, the type of incident and systems affected (IT outage, cyber incident, loss of information, infrastructure outage, financial, staff or other), and the actions taken so far. |
| Annex 3 - Basic 3 | Impact assessment | Assess business impact and service availability, impact on stakeholders, financial and market impact, and regulatory and legal impact. |
| Annex 3 - Basic 4 | Chronology of events | Set out the date, start time and duration, escalations and approvals for interim measures with reasons, stakeholders involved, channels used, and the reasoning for activating BCP or DR. |
| Annex 3 - Basic 5 | Root cause analysis | Give the causes and effects, interim measures and why they were taken, and the longer-term fixes, covering both one-time corrections and corrective actions to prevent a repeat. |
| Annex 3 - Basic 6 | Resolution date | State the date, or target date, of resolution. |
| Annex 3 - CSIR 1-2 | Contact details and new or updated report | Give contact details if they differ from the basic information, and say whether the report is new or an update, with the report number and update number. |
| Annex 3 - CSIR 3 | Classify severity | Classify the incident as Severity 1 (critical or customer-facing systems affected, or the internal network crippled) or Severity 2 (the network or critical systems put at risk). |
| Annex 3 - CSIR 4 | Dates of reporting to RBI and agencies | Give the date and time the incident was reported to RBI, and separately to CERT-In, NCIIPC, law enforcement and other agencies, in Indian local time. |
| Annex 3 - CSIR 5 | Type of threat or incident | Select the threat types that apply, such as DoS, DDoS, malware, intrusion, defacement, misuse of systems, APT or zero-day, phishing and social engineering, or other. |
| Annex 3 - CSIR 6 | Link to earlier incidents | Say whether the incident relates to one reported before, how, and give the earlier reference number. |
| Annex 3 - CSIR 7 | How and when it was detected | Say when and how the incident was first observed, and by whom. |
| Annex 3 - CSIR 8 | Impacted critical systems | Describe the affected systems or networks: location, purpose, applications, hardware and software, installed security software, ports, IP addresses of the system and attacker if known, and operating system. |
| Annex 3 - CSIR 9 | Rate the impact | Rate the impact on customer delivery, loss of sensitive information, and public confidence and reputation, each on a five-step scale from none to severe. |
| Annex 3 - CSIR 10 | Knock-on risk to other critical assets | Say whether the affected systems could affect another critical system or asset of the bank, with details if so. |
| Annex 3 - CSIR 11-12 | Follow-up actions and status | Describe the follow-up actions taken, the current status or resolution, and the next course of action if unresolved. |
| Annex 3 - CSIR 13-14 | Earliest compromise date and cause | Give the earliest known date of attack or compromise (or mark it unknown), and the source or cause of the incident. |
| Annex 3 - CSIR 15 | Reported to CERT-In, NCIIPC, police or IB-CART | Say whether the incident was reported to CERT-In, NCIIPC, any law enforcement agency or IB-CART, and which. |
| Annex 3 - CSIR 16-18 | Chain of custody and evidence tools | Say whether chain of custody is kept and the form filled, and which tools were used to collect evidence. |
| Annex 3 - CSIR E1 | Attack vectors and indicators of compromise | Identify IP addresses, domains, email addresses and malicious files (names, sizes, hashes) tied to the incident and their role, and whether they were reported to IB-CART, CERT-In, NCIIPC or law enforcement. |
Alongside the list above, SecureXcel keeps a unified set of practical controls. For each control the workbook gives the risk it addresses, the objective, a description, whether it is preventive or detective, how often to run it, the design and operating test procedures, and the evidence to collect, with the references it covers in this framework. There is one workbook per framework, supplied as it is, with a Version History sheet for document control. Free account needed; you come straight back to the file.
The circular was addressed to all scheduled commercial banks except Regional Rural Banks. Other kinds of bank and institution should check which RBI cyber security rules apply to them.
The circular calls Annex 1 an indicative, but not exhaustive, minimum baseline that banks should implement. Many items use firm wording; others say a bank may or should consider a measure.
Yes. The circular says a SOC must be set up at the earliest if one is not in place, with continuous surveillance. Annex 2 gives an indicative outline of how to set one up.
The Annex 3 template calls for the first Security Incident Report within two to six hours, with updates as new information emerges. The circular also asks for unsuccessful attempts to be reported.
No. It is a plain-English summary in our own words, following the circular's paragraph and annex numbers. The circular and its annexes are the authority, and RBI may have updated them.