RBI’s 2026 cybersecurity Directions for Payments Banks: what the Board, the CISO and auditors have to show
Payments Banks now have their own cyber Directions, issued 31 July 2026. What they ask of the Board, CISO, CSOC and IS audit, and the evidence behind each duty.
Key takeaways
- Payments Banks have a text of their own, in force from 31 July 2026, with eight chapters, 31 baseline control areas, a CSOC and IS audit.
- Incidents go to RBI on DAKSH within six hours of detection, with CERT-In notified as well.
- Risk-based transaction monitoring and customer notification sit alongside the technology controls.
- The test is whether each recurring duty ran on schedule and can be shown with dated evidence.
On 31 July 2026 the Reserve Bank of India issued the Payments Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026. They apply to Payments Banks, came into force with immediate effect, and the version on the RBI website is updated as on 1 October 2026. They repeal the earlier Cybersecurity Framework and IT Governance instructions that applied to Payments Banks.
The commercial bank Directions are a separate text and have their own scope. For a Payments Bank, the practical change is that governance, risk, controls, the security operations centre and IS audit now sit in one document addressed to it, with frequencies that can be tested.
What do the Payments Banks Directions cover?
There are eight chapters:
- 1Preliminary: commencement, applicability and definitions, which are sourced from the FSB Cyber Lexicon unless stated otherwise
- 2Role of the Board: Board-approved policies and Board-level committees
- 3IT Governance and Oversight: the IT Strategy Committee, IT Steering Committee, Information Security Committee, Head of IT, CISO, project management, architecture and IT services
- 4IT and Information Security Risk Management: periodic review, risk framework, risk identification and documentation
- 5Baseline Cybersecurity and Resilience Requirements: sections A to EE, which is 31 control areas
- 6Cyber Security Operations Centre (CSOC): governance, capabilities and staff
- 7Information Systems Audit
- 8Repeal and Other Provisions
Who is accountable for what?
The Board approves strategies and policies for IT, information assets, business continuity, information security and cybersecurity, including incident response and cyber crisis management. It may delegate review to the Board-level IT Strategy Committee (ITSC). Material amendments need Board approval, and review happens at least annually. The cybersecurity policy is kept separate from the IT and information security policy.
| Role | What the Directions ask | Evidence a reviewer will want |
|---|---|---|
| Board | Approves IT, information security, cybersecurity and business continuity strategies and policies; review at least annually | Board minutes approving each policy, with review dates |
| IT Strategy Committee | At least three directors; the Chairperson is an independent director with a minimum of seven years’ experience in managing information systems or guiding technology or cybersecurity initiatives; meets at least quarterly | Composition record, the Chairperson’s experience note, quarterly minutes |
| IT Steering Committee | Senior management from IT and business; meets at least quarterly | Attendance and minutes |
| Information Security Committee | Under the oversight of the ITSC; its head comes from the risk management vertical | Constitution as decided by the ITSC, record of incident and IS audit reviews |
| CISO | No direct reporting line to the Head of IT and no business targets; reports to the Executive Director or equivalent overseeing risk management; places a review of cyber risks and preparedness before the Board, the Risk Management Committee of the Board or the ITSC at least quarterly | Organisation chart, dated quarterly review papers |
| Audit Committee of the Board | Approves the IS Audit Policy and reviews it at least annually | Approved policy and review minutes |
Watch for. A CISO review that is prepared but not tabled does not satisfy a quarterly duty. Keep the paper, the date it was placed before the Board, the Risk Management Committee or the ITSC, and the minute.
Baseline controls and the frequencies to track
Chapter V runs from inventory of information assets and data leak prevention through to forensics. It includes capacity management, secure configuration, network and application security, audit logs, patching, user access, customer authentication, secure mail, removable media, third-party arrangements, cryptography, straight through processing, continuous surveillance, anti-phishing, red teaming, business continuity, incident response, metrics, awareness, customer education and transaction monitoring.
| Requirement | What is asked | Evidence a reviewer will want |
|---|---|---|
| Vulnerability assessment and penetration test | For critical information systems and DMZ systems with a customer interface: VA at least once every six months, PT at least once in 12 months | Scope list, dated reports, tester details |
| Closure of findings | Closure status of VA and PT observations put to the ITSC and the Information Security Committee at least quarterly | Open and closed findings by date, committee papers |
| Disaster recovery drills | Critical information systems at least half-yearly; switch to the DR site and run it as primary for at least a full working day | Drill plan, run log, sign-off, issues raised |
| Security infrastructure and policies | Reviewed at least annually | Review record per policy |
| Capacity | Assessment of IT resources annually or more often | Capacity review with date and owner |
| Board and senior management training | Annual training | Attendance records |
Other controls are stated without a fixed frequency but are routinely asked about: multi-factor authentication for privileged users of critical systems, DMARC on email, removable media prohibited unless specifically authorised, and identical configuration and patch levels at the data centre and DR site.
What is specific to a payments business?
The text does not compare Payments Banks with other categories. Two parts matter most to a Payments Bank in practice.
Transaction monitoring. Section DD asks the bank to implement a risk-based transaction monitoring or surveillance process as part of its fraud risk management system across all delivery channels. The bank also notifies the customer, through alternate communication channels, of payment or fund transfer transactions above a specified value determined by the customer.
Payment-system service providers. Section Q on third-party arrangements applies where the arrangement is not already covered by the Payments Banks outsourcing Directions of 2025. A further group of paragraphs sets controls for application service providers for ATM switches, extended to providers of other payment-system services to the bank. These include the provider informing the bank of cyber incidents in a timely manner. See our third-party risk checklist for how to evidence this.
Incident reporting, the CSOC and the crisis plan
A bank must report cyber incidents within six hours of detection on the DAKSH platform, and proactively notify CERT-In. The incident response policy has to cover classification, roles, reporting, communication, containment, recovery, post-incident review and periodic testing, and the bank needs a Cyber Crisis Management Plan. The wider CERT-In duties are set out in our six-hour reporting guide.
The CSOC is governed with briefings to the Board or ITSC on threat intelligence, uses dashboards and metrics, and is staffed in levels: round-the-clock Level 1 monitoring, Level 2 specialists in network, data and endpoint security, and Level 3 analysts for forensics and malware reverse engineering.
Tip. Run one tabletop a year that starts the clock at detection and ends with a draft DAKSH report. It shows where the six hours go.
IS audit
The Audit Committee of the Board oversees IS audit and approves the IS Audit Policy, which covers mandate, purpose, authority, audit universe and periodicity. The bank has a separate IS audit function or resources within Internal Audit, planning is risk-based, and accountability for any external IS audit stays with Internal Audit.
A readiness checklist
Where the work usually gets stuck
Policies are approved once and the review slips. Findings from penetration tests stay open without tracked closure. Drills switch over for a test window, not a full working day. And when a supervisory review begins, evidence sits across email and shared drives.
How this runs as owned work in Netra
Treat each requirement as work with an owner and a due date, and let the evidence build as the work is done. Recurring duties, such as quarterly committee reviews and half-yearly drills, should reopen on their own so they do not lapse.
That is the approach Netra, the Compliance & Audit OS, takes. The Direction is loaded as requirements, tasks and policies. Evidence is attached once to the task and carries across to every requirement it supports. Status is derived from completed work and evidence, and the Audit Centre holds the record that a reviewer or internal audit can follow. A fuller breakdown is on the RBI CTRRAF 2026 for Payments Banks page.
This article is a summary for general information. It is not legal advice. Payments Banks should confirm how the Directions apply to them with their compliance and legal teams, and work from the text on the RBI website.
Frequently asked questions
Do the commercial bank Directions apply to a Payments Bank?
No. Payments Banks have their own Directions, issued on 31 July 2026, and the commercial bank text has its own scope. A Payments Bank works from the text titled for it.
How quickly must a Payments Bank report a cyber incident?
Within six hours of detection, on the DAKSH platform. The bank must also proactively notify CERT-In.
What does the text say about transaction monitoring?
The bank implements risk-based transaction monitoring or surveillance as part of its fraud risk management across all delivery channels. It also notifies the customer, through alternate communication channels, of payment or fund transfer transactions above a value the customer specifies.
How often must disaster recovery drills run?
For critical information systems, at least half-yearly. A drill switches to the DR site and uses it as the primary site for at least a full working day, from beginning of day to end of day.
Sources
The Direction for your entity, loaded as owned work
Requirements, tasks and policies with status derived from evidence.
See it in Netra
A demo on the frameworks that matter to you.
