SEBI CSCRF, explained for vendor risk teams

SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) consolidated a decade of scattered circulars into a single, outcome-based standard for Regulated Entities (REs). For third-party risk teams the important shift is structural: CSCRF makes the RE accountable for the cyber posture of its vendors, and it organises that accountability around six functions in the spirit of the NIST Cybersecurity Framework: Govern, Identify, Protect, Detect, Respond and Recover.

If you run vendor assessments for a SEBI-regulated entity, CSCRF is the lens your questionnaire and evidence process now have to satisfy. This article walks each function and translates it into concrete questions and evidence requests.

Why CSCRF raised the bar

Before CSCRF, a Regulated Entity could point to a signed contract and a SOC 2 report and consider a vendor covered. CSCRF closes that gap in three ways. First, it expects a documented, risk-based reason for how much assurance you demand from each vendor. Second, it expects evidence, not assertions: a claimed control that has no supporting artefact is treated as unproven. Third, it extends explicitly into detection and recovery, so the assessment cannot stop at 'do they have policies'.

Govern (GV): who owns the outsourced risk

The Govern function asks a single hard question: for each vendor relationship, can you name the accountable owner inside your organisation, and does the board have a view of aggregate third-party risk? A CSCRF-aligned questionnaire captures the vendor's own governance structure (board oversight of cyber risk, a named security leader, a risk committee) and ties it back to your internal owner.

This is precisely why criticality is rated before any control question is asked. The criticality tier decides how much governance evidence you demand: a critical vendor needs a documented oversight structure and a named executive sponsor on both sides; a low-criticality supplier needs far less. Rating first, then questioning, is what makes the depth defensible to an inspector.

Identify (ID): know what the vendor touches

Identify is about scoping. Which of your systems and data does this vendor access, and how sensitive is it? A questionnaire covers data classification, the data flows between you and the vendor, sub-processor and fourth-party usage, and asset inventories on the vendor side. The answers here should feed straight back into the criticality rating: a vendor that turns out to process cardholder data or customer PII is materially more critical than the intake form assumed.

Protect (PR): the bulk of control maturity

Most of a CSCRF questionnaire lives in Protect: access control, authentication and cryptography, data protection, secure development, cloud configuration, and network security. The mistake teams make is to send every Protect question to every vendor. CSCRF does not want 1,764 questions sent to a small advisory firm; it wants the right questions, calibrated to the vendor's risk, and evidenced.

Three practices make Protect assessments defensible:

• Rate control maturity 0 to 5 per control, not pass or fail. A maturity scale distinguishes 'a policy exists on paper' from 'the control is implemented, measured and independently assured'.
• Weight higher-assurance tiers more. An answer at the Evidence or Effectiveness tier should count for more than a Policy-tier answer, so a vendor cannot score well by writing policies it never operates.
• Require evidence for every claimed control. A 'Yes' with no artefact is a red flag, not a pass, and CSCRF inspections will treat it that way.

Detect (DE): the part teams forget

Detect asks whether the vendor can see an incident when it happens, and whether you would find out. Cover logging and monitoring scope, alerting, the use of a SOC or managed detection service, and, critically, the breach-notification timelines written into your contract. A vendor with excellent preventive controls but no detection capability is a blind spot in your own incident response.

Respond and Recover (RS, RC): assume it will happen

Respond and Recover extend the assessment past prevention into what happens after a compromise at the vendor. Cover the incident-response runbook, the roles and escalation paths, business-continuity and disaster-recovery plans, and the date of the last BCP/DR test. These map to control themes that a certification report often does not fully cover, which is why the evidence locker should request BCP/DR plans and incident-response documentation as criticality rises, rather than accepting a certificate as a proxy for them.

What a CSCRF-ready vendor file contains

An inspector should be able to open one vendor file and find three things without asking:

• A documented criticality rating with its rationale, so the depth of the assessment is justified.
• A completed questionnaire whose answers map to CSCRF control references, each with a confidence signal so auto-accepted answers are distinguishable from reviewed ones.
• An evidence trail where each claimed control is backed by a current, in-scope document that has actually been reviewed, not merely uploaded.

Get those three right and CSCRF stops being a compliance tax. It becomes what it was designed to be: a continuously updated, defensible picture of the cyber risk your vendors introduce into your regulated business.