If you work in compliance at an Indian bank or NBFC, 31 July 2026 was not a normal Friday.
The Reserve Bank repealed several hundred circulars in one go and replaced the supervisory rulebook with 64 consolidated Directions, sorted by type of regulated entity. The cybersecurity and technology risk framework came out as a set, one version per entity class, all issued the same day. Commercial banks, small finance banks, payments banks, urban co-operative banks, all India financial institutions, NBFCs and credit information companies each got their own.
They came into force immediately. No transition window, no phase-in.
Two familiar documents went in the process. The 2016 Cyber Security Framework for Banks, which had been the baseline for a decade, was repealed. So was the 2023 Master Direction on IT Governance, Risk, Controls and Assurance Practices, which many institutions had only finished implementing the year before.
Plenty has been written since about what the new requirements say. Law firms and security vendors covered that ground quickly and covered it well. I want to talk about something they have mostly skipped, which is what this shift does to your control library, and why a job that used to be genuinely miserable has become a lot more manageable.
First, the short version of what changed
If you have not read the Directions yet, here is the shape of them.
They are prescriptive. That word matters. The old approach often told institutions what outcome to achieve and left the method open. These Directions tell you what to do, who is accountable, and how often. They are organised into chapters covering governance, technology management, cyber resilience, incident response, business continuity and audit.
Board accountability is the headline change. Cybersecurity is no longer something the board notes in a quarterly update. It is expected to be owned the way credit risk and market risk are owned, with a dedicated committee structure, defined CISO independence, and ongoing board training.
The control coverage is wider than the old framework. Data governance, cryptography, secure software development, vendor risk management, source code escrow, cloud security, teleworking, business continuity and disaster recovery all now carry named requirements.
Testing and reporting have fixed cadences. Vulnerability assessments and penetration testing on defined intervals, disaster recovery drills at a stated frequency, and cyber incident reporting to the RBI through the DAKSH platform within a set window, alongside CERT-In reporting where it applies.
And some obligations flow down to your service providers. Several of the Directions require banks to impose named cybersecurity controls on providers by contract, including the ones running your ATM switch and core banking systems.
That is the substance. Now the part I actually want to write about.
Two regulators, the same blueprint
The RBI is not doing this alone.
SEBI’s Cybersecurity and Cyber Resilience Framework, out in August 2024, did the same thing on the securities side. It replaced the earlier broad guidelines from 2015 and 2018 with one structured document, applied it to 22 categories of regulated entity, sorted them into five tiers with different obligations by tier, and took its control catalogue and governance structure from NIST Cybersecurity Framework 2.0.
Put the two side by side and the design is almost the same. One consolidated instrument replacing a decade of accumulated circulars. Obligations organised by chapter and paragraph instead of scattered by date. Requirements that scale by entity class or tier rather than applying flat to everyone. Accountability moved up to the board.
Two regulators, working independently, arriving at the same architecture. That is worth noticing, because it changes what you can build in a GRC system.
Why the old way was so hard to model
Anyone who has built a compliance control library in India will know this problem.
Your obligations lived across dozens of documents issued over many years. Some superseded others partly. Some applied to you and some did not, and working out which was a project in itself. A requirement introduced in one circular might be amended by a second and clarified by a third.
So before you could model anything, you had to construct a picture of what your obligations actually were, and then keep that picture current. That picture was an interpretation. Give the same set of circulars to two competent compliance teams at similar institutions and you get two different answers.
Which meant the control library underneath was an interpretation too. When an inspection came round, you were not only demonstrating that your controls worked. You were first defending your reading of what the rules asked for.
What consolidation actually changes
A prescriptive, consolidated, paragraph-numbered Direction is a much easier thing to model.
Requirements now have addresses. Chapter and paragraph. You can map a control to a specific paragraph, and that reference stays stable and checkable. An auditor asking what covers a given requirement gets a straight answer instead of a story.
Scope is settled by the instrument. The Directions were issued per entity class, so which requirements apply to you is answered by which Direction binds you, and inside the NBFC Directions, by your layer under the scale-based framework. On the SEBI side, the CSCRF tier does the same job.
And because they are prescriptive, the requirement usually names the control, the frequency and the accountable role. That is more or less the shape a control needs to take in a system anyway. The translation work shrinks.
This is the opportunity. Building a regulatory library that maps cleanly onto the source document is more achievable now than it was two years ago, because the source document is finally shaped like a library.
The difficulty does not vanish, it moves
Four places it lands.
Evidence, not documentation. These frameworks attach frequencies to requirements. Once a requirement says how often, a policy document cannot satisfy it. You need a dated record of each occurrence with evidence attached. Systems that capture control design nicely and control operation poorly are going to get found out.
Third-party obligations that flow down. If you have to impose named controls on your core banking provider by contract, your vendor records now need to carry control obligations rather than just risk ratings, and someone has to evidence that those controls are operating over there. Most third-party risk implementations were not built for this. They assess vendors. They do not track controls that live at vendors.
One control, two regulators. An institution regulated by both the RBI and SEBI, or one running an NBFC alongside a broking arm, will find the same underlying control appearing in both frameworks under different paragraph references. Build a separate control for each reference and you are now maintaining two versions of the same access review, two owners, two evidence trails. They will drift apart. One control mapped to every obligation it satisfies is the only version of this that survives a second regulator.
Board reporting that stands up. Both frameworks put accountability at board level. A board that owns cyber risk the way it owns credit risk will want reporting of the same quality, which means aggregation across entities and functions. That is a data model question, not a dashboard question.
What I would do this quarter
Four things, in this order.
Confirm which Direction binds each of your entities, then check the repeal position on everything your current control library references. If your library points at the 2016 Cyber Security Framework or the 2023 IT Governance Master Direction, those references are now pointing at repealed instruments.
Map your existing controls to the new paragraph references before you write a single new control. In my experience most of what is required is already being done somewhere in the organisation. What is missing is the traceability, not the control.
Check whether your system can attach one control to several regulatory requirements without duplicating it. If it cannot, that limitation will set your maintenance cost for the next several years.
Then look properly at how each control’s operation is evidenced. Not whether it is documented. Whether there is a dated record for every time it ran.
Where the platform fits, honestly
IBM OpenPages ships with standard object types for Risk, Control, Test, Regulatory Requirement and Policy, and a Library that holds reusable master records which map to operational records across the platform. That structure fits what these frameworks now ask for. One control statement, held once, related to every paragraph across every Direction and circular it satisfies, with test and evaluation records attached to each cycle.
But having the structure available is not the same as having the mapping done. Someone still has to read the Directions, work out which requirements collapse into shared controls, and get that model agreed across the business before anyone configures anything.
That is where most of our time goes at Timus, and I will say plainly that it is not quick. What has changed is that the July 2026 consolidation makes it a more tractable exercise than it was under the old rulebook. Institutions that do the mapping properly now will not be redoing it at the next inspection.
Timus Consulting Services is an IBM Silver Business Partner specialising in IBM OpenPages implementations across India, the GCC and international markets. If you are working through what the 2026 Directions mean for your control library, get in touch.
This article reflects the position as at 31-08-2026. Regulatory instruments change; please refer to the primary sources below.
References
-
Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026. RBI/DoS/2026-27/410, DoS.CO.CSITEG.4/31.01.015/2026-27, dated 31 July 2026. https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13643
-
Reserve Bank of India (Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026. RBI/DoS/2026-27/461, DoS.CO.CSITEG.55/31.01.015/2026-27, dated 31 July 2026. https://www.rbi.org.in
-
Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF), circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024. https://www.sebi.gov.in
-
National Institute of Standards and Technology, Cybersecurity Framework 2.0, February 2024. https://www.nist.gov/cyberframework
-
IBM, OpenPages object type descriptions, IBM Documentation. https://www.ibm.com/docs/en/openpages/9.0.0?topic=types-object-type-descriptions
