SEBI CSCRF in practice: a working guide for market intermediaries

SEBI’s Cybersecurity and Cyber Resilience Framework, with compliance timelines already in force, replaced a patchwork of circulars with a single graded framework for the entities Indian capital markets run on: exchanges, depositories, brokers, mutual funds, and other intermediaries. Grading by entity category adjusts the depth of requirements, but the software-side core reaches everyone.

The software duties inside CSCRF

Strip the framework to what engineering and security teams must actually operate, and three duties stand out.

Inventory, at bill-of-materials depth. The framework expects regulated entities to know their systems and software, and Indian regulatory practice increasingly points to CERT-In’s technical guidelines on bills of materials as the reference for what “knowing your software” means: machine-readable inventories with defined fields, covering components, not just applications. A spreadsheet of application names does not meet the bar that examiners are converging on.

Vulnerability management on defined cycles. Identification, prioritization, and remediation with records that survive audit. The framework’s cadence expectations make this a continuous operational function, and the audit expectations make the record-keeping as important as the fixing.

Evidence appropriate to your category. CSCRF’s grading means a large exchange and a small intermediary carry different depths of obligation, but both must demonstrate the framework operating: reports, logs, and periodic audits. The demonstration burden is where manual programs fail.

The environment constraint nobody writes down

Indian market infrastructure runs some of the most restricted networks in the country. Core settlement and trading segments are isolated by design, and data-sovereignty expectations discourage sending code or findings to foreign SaaS platforms. Any tooling strategy for CSCRF that assumes cloud scanning meets an immovable object here. The practical requirement is tooling that operates fully inside the perimeter, with offline update paths for vulnerability data.

A working implementation pattern

Entities that handle CSCRF well tend to converge on the same architecture:

1. BOM generation in the build pipeline. Every release produces a machine-readable SBOM automatically; BOMNexa extends this to the additional BOM dimensions Indian guidance describes, including the cryptographic inventory that forward-looking examiners have begun asking about.
2. Continuous scanning across the estate. Applications, dependencies, secrets, containers, and network segments, feeding one queue rather than five consoles.
3. A findings lifecycle with memory. Prioritization by real-world risk, SLA tracking against your defined cycles, and an immutable audit log, so the periodic audit samples a running system instead of reconstructing history.
4. Continuous re-evaluation of shipped systems. When a new CVE lands, the question “are we affected, where” is answered from stored inventories in minutes, which is also exactly the capability that makes incident-reporting timelines survivable.
5. Offline everything. Signed vulnerability-data bundles imported on your schedule, so the isolated segments get the same currency of data as the connected ones.

Treating CSCRF as an asset

The intermediaries that implemented this properly report an unexpected benefit: CSCRF evidence doubles as client-facing assurance. Institutional clients ask the same questions examiners do, and an entity that can produce component inventories and remediation histories on demand closes those conversations faster than one that produces attestations.

Our CSCRF guide maps the framework’s software expectations to specific platform evidence, and a demo on your own environment is the fastest way to see the reporting side. For entities also answering to RBI on the banking side, the RBI guide covers the overlap.