Safeguard
Compliance•

How does a software company support SEBI CSCRF compliance?

SEBI's CSCRF binds regulated entities, but its supply chain and SBOM standards reach vendors. A step by step plan for a software company in Indian markets.

Safeguard Security Team
4 min read

SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) applies to SEBI regulated entities such as depositories, custodians and brokers, not to software vendors directly. It still reaches vendors through supply chain standards: customers must assess you, put security terms in contracts, and obtain SBOMs for critical software. Prepare to answer those asks.

Who does CSCRF apply to?

The circular dated 20 August 2024 lists the regulated entities it covers: alternative investment funds, clearing corporations, credit rating agencies, custodians, depositories, depository participants, stock brokers, stock exchanges, mutual funds and others. A software company is not on that list, unless it is itself regulated.

Where the framework applies for the first time, the circular set an application date of 1 April 2025. SEBI may have issued later circulars or revisions, so check the current text on SEBI's site before you quote a deadline to a customer.

What does it say about suppliers?

The supply chain standard, labelled GV.SC, says regulated entities must identify, prioritise and assess suppliers and third-party service providers through a cyber supply chain risk assessment. Contracts must include measures that meet the entity's cybersecurity program. Third-party providers performing critical activities are monitored periodically, and are to be mandated to follow similar standards of information security.

Two items stand out for engineers. Response and recovery planning and testing is to be done together with third-party providers. And the entity must assess concentration risk when one provider serves several critical services.

What does it say about SBOMs?

The circular defines an SBOM as a formal record of the components used to build software. It asks entities to obtain an SBOM for all new software procurements of core and critical activities and keep it updated with every upgrade or change. If an SBOM cannot be obtained for a legacy or proprietary system, the board or partners must approve that exception with a stated rationale and risk approach.

A further guideline lists what an SBOM should include, among other things: license information, supplier name, top level components with transitive dependencies and relationships, cryptographic hashes, update frequency, and a note on where the dependency graph is incomplete. Market infrastructure institutions are told to include an SBOM in empanelment criteria for application software vendors.

Step by step for a vendor

  1. Identify which customers are SEBI regulated and which of your products they use for critical activities.
  2. Produce an SBOM for each such product, with transitive dependencies, versions, licenses and hashes. Generate it in CI so it updates with every release.
  3. Decide the format and delivery route. SPDX and CycloneDX are the common formats, and the circular does not name one, so ask the customer.
  4. Write a supplier security statement covering your secure development process, patching and incident notification. Keep it factual.
  5. Prepare contract language for security measures and incident cooperation.
  6. Plan joint response testing. Know who at your company answers, and how fast.
  7. Review concentration risk from your side. If many customers depend on one hosted service of yours, document your resilience and recovery design.
  8. Keep a written exception process for older components you cannot easily replace.

Constructed example: a registrar's vendor ships a settlement reconciliation app. Each release builds an SBOM, the pipeline fails on a new critical vulnerability with a reachable path, and the SBOM goes into the customer's portal beside the release notes.

Safeguard's CLI generates SBOMs and scans dependencies, and its reachability analysis helps separate vulnerable code that runs from code that does not. Mapping to CSCRF remains the customer's compliance decision.

What should you avoid saying?

Avoid calling a product CSCRF compliant or certified. The framework sets duties for regulated entities, and each entity decides how to meet them. Say instead which artifacts you provide, such as SBOMs, patch timelines and incident contacts, and let the customer map those to its own obligations. If an entity asks for something you cannot provide, say so early.

Quick check

Is a vendor CSCRF certified?

The circular describes obligations for regulated entities, and this post found no vendor certificate in it. Customers assess vendors themselves.

Does the circular require a specific SBOM format?

The text we read lists required content but does not name SPDX or CycloneDX. Confirm with each customer.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.