Risk Registers Are Snapshots That Go Stale
Every risk register in every Indian BFSI organisation shares the same fundamental flaw: it is a snapshot that begins decaying the moment it is written. A risk register captures what was known at the time of the last assessment — which controls were in place, which systems were in scope, which regulatory obligations applied. But systems change daily. New applications are deployed. Vendors are onboarded. Cloud configurations are modified. And most critically, regulators issue new circulars that alter obligations without warning.
The risk register doesn't know any of this happened. It sits in a spreadsheet or a GRC tool, showing the same risk ratings, the same control mappings, and the same residual risk scores that were entered during the last quarterly review. When IRDAI tightened the incident reporting window from 24 hours to 6 hours in March 2025, how many risk registers were updated the same week? When SEBI issued the CSCRF framework mandating continuous audit, how many risk registers reflected the new obligation within 30 days? The answer, for most organisations, is that the risk register was updated at the next scheduled review — which may have been months later.
A Risk Graph Connects Every Entity
A risk graph is a fundamentally different data structure. Instead of rows in a spreadsheet, it represents every entity in the compliance ecosystem as a node and every relationship as an edge: systems connect to controls, controls connect to obligations, obligations connect to regulators, systems connect to vendors, vendors connect to sub-processors, evidence connects to controls, risks connect to systems and controls simultaneously. When any node changes, every connected node is automatically flagged for review.
Consider what happens when a new IRDAI circular is published. In a risk register world, someone reads the circular, determines which controls are affected, manually updates the register, and hopes they didn't miss anything. In a risk graph, the new circular is added as an obligation node. The graph automatically identifies every control that maps to IRDAI obligations, every system that those controls protect, every vendor that those systems depend on, and every evidence artifact that demonstrates compliance. The affected surface is computed, not guessed.
SEBI CSCRF and the Continuous Audit Mandate
SEBI's Cyber Security and Cyber Resilience Framework (CSCRF) made the risk graph argument architectural rather than philosophical. CSCRF mandates continuous audit — not annual, not quarterly, but continuous monitoring of cybersecurity controls and their effectiveness. You cannot implement continuous compliance monitoring on top of a data structure that is updated quarterly. The spreadsheet is the wrong foundation.
Continuous audit requires a system that knows, in real-time, which controls are in place, which evidence is current, which obligations apply, and which gaps exist. When a firewall rule changes, the system must know which controls that rule supports, whether those controls are still effective, and whether the change creates a new gap. When a new SEBI circular adds a requirement, the system must immediately identify which controls are affected and which evidence needs to be collected. This is graph traversal, not spreadsheet lookup.
What a Risk Graph Looks Like in Practice
Consider a concrete scenario: IRDAI publishes a new circular requiring board attestation of cybersecurity posture. In a risk graph implementation, this triggers a specific cascade. The circular is ingested as a new obligation node. The graph identifies that this obligation affects the "Board Governance" control family. Those controls are linked to specific evidence requirements: board meeting minutes, CISO presentation, attestation document. The graph checks whether current evidence satisfies the new requirement. If not, it creates evidence collection tasks, assigns them to the responsible parties, sets deadlines based on the circular's effective date, and updates the board dashboard to show the new obligation and its compliance status.
Every step in this cascade is automatic. No analyst reads the circular and manually determines what is affected. No compliance manager creates tasks in a project management tool. No one updates a spreadsheet. The graph's structure — the connections between obligations, controls, evidence, systems, and people — encodes the organisational knowledge that would otherwise exist only in people's heads or in disconnected documents.
From Periodic Assessment to Continuous Monitoring
The shift from "assess periodically" to "monitor continuously" is not a process improvement that can be layered on top of existing tools. It is an architecture decision. A risk register is a flat data structure designed for periodic snapshots. A risk graph is a connected data structure designed for continuous state management. You cannot make a spreadsheet behave like a graph by adding more columns or more frequent updates. The data model is fundamentally different.
For Indian BFSI organisations facing simultaneous obligations from RBI, IRDAI, SEBI, CERT-In, and DPDP, the risk graph is not a theoretical nicety — it is an operational necessity. When five regulators can change your obligations independently and simultaneously, and when SEBI requires continuous proof that you are compliant, the only viable architecture is one where every regulatory change automatically propagates to every affected control, system, vendor, and evidence requirement. That architecture is a graph.
Request access to RiskSage →