Skip to content
BankPulseBETARegulatory intelligence for Indian banking
Directions · Reserve Bank of India

Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026

UR

The four dates on this rule

At a glanceThis paper sets the cyber and technology risk rules for commercial banks. These Directions apply to every commercial bank. The IT Strategy Committee must meet at least once every three months.

Official RBI page

Numbers to remember

seven yearsReal IT skill here means at least seven years of running or guiding IT work. RBI Para 17(2)
three monthsThe IT Strategy Committee must meet at least once every three months. RBI Para 18
six monthsCritical systems need a scan every six months and an attack test every 12 months. RBI Para 151
six hoursA cyber incident must be reported on the DAKSH platform within six hours of detection. RBI Para 182

What it says

Chapter I. Preliminary

1. Cyber rules for banks

This paper sets the cyber and technology risk rules for commercial banks.

2. Start date

These Directions took effect at once.

BankPulse example. There is no gap here between issue and effect. The Directions come into effect immediately upon issuance. A bank cannot wait for a separate start date, because there is none.

3. Who is covered

These Directions apply to every commercial bank.

Chapter II. Role of the Board

1. Board sees them yearly

These plans and policies must go to the Board for review at least once a year.

2. Set up the IT committee

The bank must set up a Board level IT Strategy Committee.

3. Audit committee oversees IS

The audit committee of the Board oversees the audit of information systems.

Chapter III. Information Technology Governance and Oversight

Must know

1. Seven years of skill

Real IT skill here means at least seven years of running or guiding IT work.

2. Committee meets each quarter

The IT Strategy Committee must meet at least once every three months.

3. A steering committee too

A steering group of senior staff must also meet at least once every three months.

4. Keep the two apart

The security officer must not report to the head of IT and gets no business target.

5. Quarterly cyber review

The security officer must place a cyber risk review before the Board every three months.

6. No unsupported software

The bank must not run outdated hardware or software that the maker no longer backs.

Do it

7. IT risk sits inside

The wider risk policy must also test IT risk from time to time.

8. Have a security policy

The bank must have an information security policy that sets scope, owner and penalty.

9. A separate cyber policy

The cyber security policy must be kept apart from the wider IT policy.

10. Three directors at least

The IT Strategy Committee must have at least three directors as members.

11. Chair must be independent

The chair of that committee must be an independent director with real IT skill.

12. Security committee under it

An information security committee must sit under the IT Strategy Committee.

13. Risk side heads it

The head of that security committee must come from the risk side of the bank.

14. Name a head of IT

The bank must name a senior officer with real IT skill as head of the IT work.

15. Head of IT duties

The head of IT must keep projects in line with policy and set up the backup site.

16. Name a security officer

A senior officer, best of general manager rank, must be named security officer.

17. Staff and budget for security

The security office must be well staffed and its budget set by the threats seen.

18. Review architecture yearly

The IT Strategy Committee must review the IT design at least once a year.

Background

19. First line of defence

The head of IT is the first line of defence for IT controls and IT risk.

20. Always invited

The security officer is a standing invitee to both the IT committees.

21. Reports to the top

The security officer reports to the executive director who looks after risk.

22. Plan the technology refresh

The bank must plan to replace hardware and software before support runs out.

Chapter IV. IT and Information Security Risk Management

1. Risk committee reviews yearly

The risk committee must review and update the risk policy at least once a year.

2. Security check each year

The bank must review its security set up and policies at least once a year.

3. Grade your own risk

The bank must grade its own risk as low, moderate, high or very high.

Chapter V. Baseline Cybersecurity and Resilience Requirements

Must know

1. Go beyond the top ten

Application security testing must not stop at the OWASP top 10 list.

2. Put the code in escrow

Where the source code cannot be had, the bank must place it in escrow.

3. No admin rights

Staff must not hold admin rights on their own desktop or laptop.

4. Removable media is barred

As a rule, pen drives and like media are barred unless allowed for a set use.

5. No manual data changes

Data moving between critical systems must not be changed by hand on the way.

6. Six months, then a year

Critical systems need a scan every six months and an attack test every 12 months.

BankPulse example. Suppose a scan is run in January and the next in July, six months later. The attack test run in January is next due the following January, 12 months later.

7. Report closure each quarter

The closing of test findings must go to both IT committees every three months.

8. Drill every six months

Recovery drills for critical systems must be held at least once every six months.

9. Six hours to report

A cyber incident must be reported on the DAKSH platform within six hours of detection.

10. Warn customers on passwords

The bank must teach customers never to share a password, a one time code or a PIN.

Do it

11. Keep an asset list

The bank must keep an up to date list of all its information assets.

12. Keep a data dictionary

The bank must keep a data dictionary so that systems share one meaning of data.

13. Stop data leaks

The bank must have a full plan to stop the loss or leak of sensitive data.

14. Wipe a lost device

The bank must be able to lock or wipe a mobile or a laptop from far away.

15. Data migration policy

The bank must have a data migration policy that keeps data whole and correct.

16. List the allowed software

The bank must keep one central list of software that is allowed and not allowed.

17. Control what gets installed

The bank must control what software can be put on its systems and devices.

18. Watch for new patches

The bank must watch patch notices from makers and CERT-In and apply them fast.

19. Guard the data centre

Physical controls must protect the data centre and the backup site from harm.

20. Watch heat and water

The bank must watch for breaks in heat, water, smoke, power and access alarms.

21. Keep the sites apart

The data centre and the backup site must be far apart in place.

22. Check capacity each year

The bank must check how much IT capacity it needs at least once a year.

23. Set a security baseline

The bank must set and apply a base security setting for every kind of device.

24. Review firewalls often

The bank must review firewalls, switches and security kit and their patch levels.

25. Keep a network map

The bank must keep an up to date map of its wired and wireless networks.

26. List every allowed device

The bank must keep one central list of the devices allowed on its network.

27. Secure the wireless

The bank must secure wireless networks, access points and client systems.

28. Block strange devices

The bank must spot devices that are not allowed on the network and block them.

29. Layer the boundary

Boundary defence must be layered, with firewalls, proxies and intrusion systems.

30. Support IPv6 traffic

Public facing systems of the bank must be able to carry IPv6 traffic.

31. Write secure code

The bank must use secure coding when it builds software on its own or with others.

32. Keep environments apart

The build, test and live systems must be kept apart from each other.

33. Vendors must support it

The bank must tie down software support from its vendors by formal agreement.

34. Get the source code

The bank must get the source code for every critical application from the vendor.

35. Written word from the vendor

The vendor must confirm in writing that the software carries no known flaw or malware.

36. Log every critical system

Every system that touches critical or sensitive data must keep an audit trail.

37. Trails must stand as proof

Audit trails must be full enough to serve as proof and to settle a dispute.

38. Watch the audit trails

The bank must watch audit trails and system logs to find any attack or misuse.

39. Find the root cause

The bank must find the root cause of any incident and patch the weak point.

40. Watch the privileged user

Staff with high system rights must be watched and all their work logged.

41. One place to sign in

Sign in and rights must run from one central system with strong password rules.

42. Close dormant accounts

The bank must limit failed sign in tries and switch off accounts nobody uses.

43. Prove who the customer is

The bank must be able to prove who a customer is on every channel it runs.

44. Secure the mail system

The bank must guard its mail against spoofing, look alike names and bad files.

45. Use DMARC on email

The bank must put DMARC in place on its email names to stop spoofing.

46. Scan media first

Removable media must be scanned for malware before read or write access is given.

47. Assess vendor risk

The bank must assess vendor risk and hold controls that match that risk.

48. Right to audit the vendor

The vendor agreement must give the bank a right to audit and RBI a right to inspect.

49. RBI can see everything

RBI must be able to reach every information resource the bank uses.

50. Where the data may sit

The bank must follow the law on where systems sit and where data may travel.

51. Switch provider must comply

The ATM switch provider must meet the cyber controls the bank writes into the contract.

52. Change default passwords

Default passwords on network devices and systems must be changed after they go in.

53. Provider needs its own centre

The ATM switch provider must set up its own cyber security operations centre.

54. Card standards apply

The switch provider must meet the payment card industry data security standard.

55. Use strong encryption

Key length, methods and protocols used to send and hold data must be strong.

56. Run a security centre

The bank must set up a cyber security operations centre for a constant watch.

57. Whitelist internet sites

The bank must whitelist the internet sites and systems that staff may reach.

58. Buy anti phishing help

The bank must buy a service that takes down fake sites and rogue apps.

59. Scan and attack tests

The bank must run scans and attack tests on all critical and internet facing systems.

60. Independent testers only

Scans and attack tests must be run by trained and independent security experts.

61. Follow the ISO standard

The continuity and recovery policy must follow best practice such as ISO 22301.

62. Run on the backup site

A recovery test must run the backup site as the main site for a full working day.

63. Test your backups

The bank must back data up and restore it now and then to prove it works.

64. Near zero data loss

The bank must aim for the least recovery time and near zero data loss.

65. Both sites must match

The settings and security patches at the main and backup sites must be the same.

66. Have a response policy

The bank must have a written policy on how it answers and recovers from an incident.

67. Train the incident staff

Staff who handle cyber incidents must be given special training.

68. Plan for ransomware

The bank must write down how it answers ransomware, data wiping and denial of service.

69. Shut the attack in

The bank must hold an attack in by shielding or cutting off the hit systems.

70. Tell CERT-In as well

The bank must also tell CERT-In about a cyber incident without being asked.

71. Share threat news

The bank must set up ways to gather and share threat news at home and abroad.

72. Join the cyber drills

The bank must take part in cyber drills run by CERT-In and IDRBT.

73. Write a crisis plan

The bank must write a cyber crisis management plan under the Board approved framework.

74. Four steps in a crisis

The crisis plan must cover four steps: detection, containment, response and recovery.

75. Measure with real numbers

The bank must build measures such as patch delay, malware cover and training reach.

76. Teach the staff

The bank must set out safe use rules for staff, vendors and partners.

77. Train every new recruit

Cyber awareness training is a must for all new recruits.

78. Board training each year

The Board and senior staff must be trained on IT and cyber risk once a year.

79. Take down fake sites

The bank must ask customers to report phishing mail and then act on it.

80. Watch risky transactions

The bank must watch transactions on a risk basis across every channel it runs.

81. Alert on large payments

The bank must alert the customer about payments above a value the customer sets.

82. Keep forensics on standby

The bank must keep network forensic and denial of service help on standby.

Background

83. The data stays yours

The bank owns the duty to keep customer data safe, even at a vendor site.

84. Access on business need

Access to information assets is allowed only where there is a real business need.

85. Two factor for privilege

A second factor is needed to sign in for privileged users of critical systems.

86. Rules for remote work

Remote work needs safe systems, a second sign in factor and a list of remote devices.

87. Bank is the identity source

The bank stands as the identity source when a customer reaches a partner system.

88. The bank stays answerable

The bank stays answerable for security risk in work it has given out.

89. Check vendor staff

Background checks and secrecy agreements are needed for all vendor staff.

90. Red team exercises

The bank may run red team drills that copy how a real attacker works.

Chapter VI. Cyber Security Operations Centre

1. Framework for the centre

The bank must have a framework to set up and run its security operations centre.

2. What the centre must do

The centre must watch, study and escalate incidents and work with outside agencies.

3. Watch round the clock

The bank must work out the staff it needs to watch systems 24x7.

4. Level three analysts

Level three analysts need deep packet study, forensic skill and malware knowledge.

Chapter VII. Information Systems Audit

1. Have an IS audit policy

The bank must have an information systems audit policy.

2. Audit policy reviewed yearly

The audit committee must approve that policy and review it at least once a year.

3. Separate IS audit function

The bank must have a separate information systems audit function with the right skill.

4. Plan audits by risk

Audit planning must follow a risk based approach.

Chapter VIII. Repeal and Other Provisions

1. Old cyber rules go

These Directions repeal the earlier cyber framework and IT governance instructions.

2. Other laws still apply

These Directions add to other laws and rules and do not replace them.

BankPulse example. A bank follows these Directions and thinks the matter is closed. It is not. Any other laws, rules, regulations or directions in force still apply on top. Where another one asks for more, the bank does the more.

3. RBI has the last word

RBI may issue clarifications, and its reading of these Directions is final.

BankPulse example. Two banks read the same clause differently. Neither reading settles it. RBI may issue clarifications, and its interpretation of any provision is final and binding on all concerned entities.

The same subject for other kinds of institution

The same subject for other kinds of institution.

Other RBI rules for commercial banks

Every rule page on BankPulse  ·  Questions bankers ask, answered