SEBI CSCRF compliance checklist

1. Establish your RE category first

CSCRF does not apply uniformly, and this is the most common early mistake. SEBI graded regulated entities into five categories, and the depth of obligation scales with the grade. Your category is not a choice — SEBI defines the thresholds, typically on number of clients, trading volume or assets under management, and your exchange or depository will confirm where you sit.

• Obtain your category in writing from your designated Stock Exchange or Depository, and keep it — it determines everything below.
• Re-check it after growth. Crossing a threshold changes your obligations before anyone sends a reminder.
• Map each CSCRF requirement to your category before budgeting, so you are not funding a Qualified RE programme on a mid-size obligation, or the reverse.

2. Governance and the Cyber Capability Index

The CCI is where CSCRF stops being a checklist and becomes an audit instrument. SEBI publishes a scoring methodology across roughly two dozen parameters, and Market Infrastructure Institutions must achieve and maintain a defined level.

• Board-approved cyber security and cyber resilience policy, with named accountability rather than a committee in the abstract.
• A CCI self-assessment you can reproduce — with the working, not just the score.
• Evidence that the board actually saw the result and made decisions on it.
• Do not self-certify a higher CCI than you can defend line by line. It is the fastest route to an observation.

3. SOC coverage — decide the model early

CSCRF requires larger REs to have Security Operations Centre coverage. There is more than one legitimate route, and the choice drives both cost and audit evidence:

• Your own SOC, or
• a shared C-SOC provided by an MII or an approved market SOC, or
• a managed SOC from an empanelled provider.
• Whichever you choose, be able to show alert triage in practice — an auditor asking to watch a live alert being worked is a routine request, and a dashboard is not an answer.

4. The two reporting clocks — do not conflate them

CSCRF’s teeth are in its timelines, and confusing the two obligations is a classic error. Incident reporting to SEBI and to CERT-In are separate, with separate clocks.

• The CERT-In six-hour window is the one that ruins weekends. Detection starts the clock, not confirmation. Teams routinely lose hours deciding whether an anomaly is real, and by then the window has gone.
• Write down, in advance, who is authorised to declare an incident and start reporting. That single decision causes most of the delay.
• Keep the SEBI and CERT-In paths on one page, with contacts, formats and deadlines side by side.
• Rehearse it. A reporting obligation that has never been exercised is a plan, not a capability.

5. The gaps that sink CSCRF audits

Across CSCRF assessments a small number of gaps account for most non-compliances. Close these before your auditor arrives and you have handled the bulk of your exposure:

• Recovery that has never been proven. The classic audit-room moment: a clean, board-approved policy pack, then a request for a live restoration of a non-production dataset that is still running ninety minutes later because backups are full-image and storage is throttled. Your RTO claim does not survive that.
• SOC alerts nobody works. Coverage on paper, no evidence of triage, escalation or closure.
• Access reviews performed but not evidenced — no record of who reviewed what, or what was removed as a result.
• VAPT findings without retest. An open finding with no closure evidence reads as an unmanaged risk.
• API security treated as out of scope. Brokers and depository participants expose trading and account APIs, and the Protect and Detect goals apply to them directly — rate limiting, authorisation between accounts, and logging.

6. Evidence pack to assemble before the audit

• Category confirmation, CCI working, board minutes showing the result was considered.
• SOC model documentation plus worked alert examples end to end.
• Latest VAPT report and the retest confirming closure.
• A dated restoration test with timings against your stated RTO — not a backup success log.
• Access review records with outcomes, and the incident-reporting runbook covering both clocks.
• Data localisation position: where regulated data is stored and processed, and what leaves India.

Where this fits

CSCRF borrowed heavily from NIST and wrapped it in SEBI’s own maturity model, so most of the underlying work is reusable. If you already hold ISO 27001 you have much of the control evidence; the gap is usually the SEBI-specific reporting, the CCI and the proof that recovery works. Firms handling personal data alongside this should read the DPDP compliance checklist, since the breach clocks are different again.