CSCRF Comes Into Force: What Market Participants Should Not Miss

The wrong way to read CSCRF is to ask, “Do we have a cybersecurity policy?”

That question is too small.

The better question is: if SEBI, an exchange, a depository, an auditor, or senior management asks tomorrow how cyber controls actually operate in your organisation, can you show it?

That is the shift market participants should understand as the Cybersecurity and Cyber Resilience Framework moves into active implementation. SEBI issued the CSCRF circular on August 20, 2024, with the stated framework applying to SEBI-regulated entities. Mondaq’s later coverage specifically noted merchant bankers entering active CSCRF compliance from June 30, 2025, and described the framework as strengthening cybersecurity and cyber resilience across the capital market ecosystem.

This is not only an IT department issue. It is a regulated-entity control issue.

The first thing market participants should not miss is categorisation.

CSCRF obligations depend significantly on the category into which the regulated entity falls. The level of implementation expected from a large market participant will not be identical to that expected from a smaller one. SEBI’s June 2025 FAQs and later commentary clarified several categorisation points, including stock broker computation logic, proprietary broker thresholds, and the principle that the category is fixed at the beginning of the financial year based on the previous year’s data.

This means the first internal file should not be a policy file. It should be a categorisation file.

Which RE category are we in?
What data was used to decide that category?
Who approved the classification?
Does the entity hold more than one SEBI registration?
Are we following the highest applicable category where required?

A wrong or undocumented categorisation can weaken the entire compliance position because every later decision depends on that starting point.

The second thing to get right is the system inventory.

Cyber readiness starts with knowing what needs protection. A market participant cannot properly implement controls if it does not know its critical systems, non-critical systems, applications, databases, endpoints, APIs, cloud services, vendors, and data flows.

This is where many firms will struggle. Their cyber documentation may describe controls in broad language, but their actual inventory may be incomplete, outdated, or maintained by only the IT vendor. SEBI-related clarifications also indicate that smaller REs may maintain manual IT asset inventories where IT setups are limited, but the inventory still has to be accurate and periodically updated.

That is the practical point: Excel is not the problem. Inaccuracy is the problem.

The third point is audit scope.

CSCRF compliance will be tested through audits, reviews, and closure of findings. Mondaq’s merchant banker commentary notes that cyber audits cover 100 percent of critical systems and 25 percent of non-critical systems on a sample basis, with CERT-In empanelled IS auditing organisations conducting such audits. It also notes audit report submission, closure of findings, and follow-on audit timelines.

Market participants should not wait for the audit to discover control gaps. Before audit time, they should already know:

Which systems are critical?
Which systems are in audit scope?
Which controls are fully implemented?
Which controls are partially implemented?
Which findings are open?
Who owns closure?
What evidence proves remediation?

A cyber audit should not become a surprise inspection inside the organisation.

The fourth point is implementation evidence.

This is where most compliance teams should be careful. A cybersecurity policy, board note, or vendor certificate may be useful, but it is not enough by itself. CSCRF is about functioning controls. That means evidence should show that controls are operating, not merely that they were approved.

For example, if the entity claims it has access control, it should have user access review records. If it claims VAPT is performed, it should have reports, findings, closure evidence, and retest status. If it claims incident response readiness, it should have an incident response plan, escalation matrix, test records, and reporting discipline. If it uses a SOC, it should have monitoring arrangements and reports. If it uses cloud or outsourced providers, it should have contracts, risk assessment, and vendor compliance evidence.

Evidence is not paperwork after the event. It is proof that the control exists in real life.

The fifth point is vendor and cloud risk.

Many market participants do not run everything in-house. Trading support systems, back-office applications, DP systems, reporting utilities, client portals, cloud infrastructure, SOC services, cybersecurity tools, and software vendors may all sit inside the control environment.

But outsourcing does not outsource accountability. SEBI-related clarifications discussed third-party accountability, cloud hosting, cloud risk evaluation, regulatory assessment, contractual requirements, audits, and the need for regulated entities to ensure compliance by service providers.

So the practical checklist should ask:

Which vendors touch regulated systems or data?
Which vendors support critical applications?
Do contracts include cybersecurity obligations?
Are logs, access, data location, and audit rights clear?
Is there an exit plan if the vendor fails compliance expectations?

Vendor risk should not be discovered during a breach.

The sixth point is incident response.

Cybersecurity compliance cannot be built only around prevention. Incidents may still happen. The test is whether the entity can detect, contain, report, recover, and document properly.

For merchant bankers, Mondaq’s coverage notes requirements around incident reporting, including reporting to SEBI and CERT-In within six hours in cases falling under CERT-In cybersecurity directions, with further reporting on SEBI’s incident portal. Market participants should verify the exact incident reporting obligations applicable to their category and activity, but the operational lesson is clear: the response clock starts before people are comfortable.

That means the incident response plan should not sit unread in a folder. Teams should know who decides, who reports, who talks to vendors, who preserves logs, who informs management, and who maintains the evidence trail.

The seventh point is management oversight.

CSCRF is technical, but the risk is not only technical. A cyber failure can affect clients, market access, investor data, regulatory standing, business continuity, and reputation. Senior management should therefore not treat CSCRF as a vendor-led checklist.

They should ask for a control dashboard that shows categorisation, critical systems, audit status, open findings, VAPT closure, incident readiness, vendor risks, policy approvals, and implementation evidence.

Not once a year. Regularly.

The practical takeaway is simple: CSCRF compliance should be built like an operating file, not a policy bundle.

The file should contain categorisation rationale, system inventory, applicable controls, implementation status, audit scope, VAPT reports, closure records, vendor evidence, incident response records, management review notes, and regulator-facing submissions wherever applicable.

That is what market participants should not miss.

CSCRF is not asking firms to merely say they are cyber-ready. It is pushing them to prove it.