Reserve Bank of India (Payments Banks - Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026
UR
- Applies toPayments banks
- StatusIn force
- RBI text changedRBI updated this document on October 01, 2026. BankPulse is re-reading it. BankPulse checked 130 points against RBI's new text on 2 October 2026. 129 stand. 1 are marked below and are being re-read.
- IssuedJul 31, 2026
- Amendmentsnone tracked
- Length130 points in 5 sections · 12 min read
The four dates on this rule
- PublishedJul 31, 2026The day RBI put this document out. This is the same day as the Issued date on this rule.
- Starts to applyJul 31, 2026The day this rule starts to apply, as RBI's own text states it.
- Time to get readyNoneIt starts to apply on the day it was published.
- Last date to actNot statedNo date to act by was found in this document. Other dates may sit inside single paragraphs.
Kept in your browser only. Your desk
Show me the points for
Nothing is removed from the page.
Numbers to remember
| seven years | Real IT skill here means at least seven years of running or guiding IT work. RBI Para 16(2) |
| three months | The IT Strategy Committee must meet at least once every three months. RBI Para 17 |
| six months | Critical systems need a scan every six months and an attack test every 12 months. RBI Para 150 |
| six hours | A cyber incident must be reported on the DAKSH platform within six hours of detection. RBI Para 181 |
What it says
How firm is each point
Stated by RBI — RBI’s own paragraph says this. We have only made it plainer.
Our reading — BankPulse read RBI’s paragraph and shortened it. The paragraph is the authority, not this line.
Needs judgement — RBI leaves this to the bank to settle, so nobody can give you a fixed number here.
Can be read two ways
A point marked this way sits on an RBI paragraph that can honestly be read two ways. Our own sentence takes one of the two. BankPulse does not choose for you: read RBI’s own paragraph, at the number printed on the point, before you act on it.
Two ways — both, or either one. RBI’s paragraph joins two things in the and-or form. One reading: Both of them apply, together. The other: Either one of them, on its own, is enough.
Chapter I. Preliminary
1. Cyber rules, payments banks
This paper sets the cyber and technology risk rules for payments banks.
2. Start date
These Directions took effect at once.
3. Who is covered
These Directions apply to every payments 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. Always invited
The security officer is a standing invitee to both the IT committees.
20. Reports to the top
The security officer reports to the executive director who looks after risk.
21. 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. Right to audit the vendor
The vendor agreement must give the bank a right to audit and RBI a right to inspect.
48. RBI can see everything
RBI must be able to reach every information resource the bank uses.
49. Where the data may sit
The bank must follow the law on where systems sit and where data may travel.
50. Switch provider must comply
The ATM switch provider must meet the cyber controls the bank writes into the contract.
51. Change default passwords
Default passwords on network devices and systems must be changed after they go in.
52. Provider needs its own centre
The ATM switch provider must set up its own cyber security operations centre.
53. Card standards apply
The switch provider must meet the payment card industry data security standard.
54. Use strong encryption
Key length, methods and protocols used to send and hold data must be strong.
55. Run a security centre
The bank must set up a cyber security operations centre for a constant watch.
56. Whitelist internet sites
The bank must whitelist the internet sites and systems that staff may reach.
57. Buy anti phishing help
The bank must buy a service that takes down fake sites and rogue apps.
58. Scan and attack tests
The bank must run scans and attack tests on all critical and internet facing systems.
59. Independent testers only
Scans and attack tests must be run by trained and independent security experts.
60. Follow the ISO standard
The continuity and recovery policy must follow best practice such as ISO 22301.
61. Run on the backup site
A recovery test must run the backup site as the main site for a full working day.
62. Test your backups
The bank must back data up and restore it now and then to prove it works.
63. Near zero data loss
The bank must aim for the least recovery time and near zero data loss.
64. Both sites must match
The settings and security patches at the main and backup sites must be the same.
65. Have a response policy
The bank must have a written policy on how it answers and recovers from an incident.
66. Train the incident staff
Staff who handle cyber incidents must be given special training.
67. Plan for ransomware
The bank must write down how it answers ransomware, data wiping and denial of service.
68. Shut the attack in
The bank must hold an attack in by shielding or cutting off the hit systems.
69. Tell CERT-In as well
The bank must also tell CERT-In about a cyber incident without being asked.
70. Share threat news
The bank must set up ways to gather and share threat news at home and abroad.
71. Join the cyber drills
The bank must take part in cyber drills run by CERT-In and IDRBT.
72. Write a crisis plan
The bank must write a cyber crisis management plan under the Board approved framework.
73. Four steps in a crisis
The crisis plan must cover four steps: detection, containment, response and recovery.
74. Measure with real numbers
The bank must build measures such as patch delay, malware cover and training reach.
75. Teach the staff
The bank must set out safe use rules for staff, vendors and partners.
76. Train every new recruit
Cyber awareness training is a must for all new recruits.
77. Board training each year
The Board and senior staff must be trained on IT and cyber risk once a year.
78. Take down fake sites
The bank must ask customers to report phishing mail and then act on it.
79. Watch risky transactions
The bank must watch transactions on a risk basis across every channel it runs.
80. Alert on large payments
The bank must alert the customer about payments above a value the customer sets.
81. Keep forensics on standby
The bank must keep network forensic and denial of service help on standby.
Background
82. The data stays yours
The bank owns the duty to keep customer data safe, even at a vendor site.
83. Access on business need
Access to information assets is allowed only where there is a real business need.
84. Two factor for privilege
A second factor is needed to sign in for privileged users of critical systems.
85. Rules for remote work
Remote work needs safe systems, a second sign in factor and a list of remote devices.
86. Bank is the identity source
The bank stands as the identity source when a customer reaches a partner system.
87. The bank stays answerable
The bank stays answerable for security risk in work it has given out.
88. Check vendor staff
Background checks and secrecy agreements are needed for all vendor staff.
89. 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 payments banks
RBI compliance officer and compliance function rules for payments banks 2026
RBI customer service and fair conduct rules for payments banks 2025
Every rule page on BankPulse · Questions bankers ask, answered