SEBI CSCRF — A Compliance Checklist for Regulated Entities

Published May 3, 2026 · 14 min read

The Securities and Exchange Board of India consolidated decades of fragmented cybersecurity circulars into a single Cyber Security and Cyber Resilience Framework (CSCRF) issued in 2024. The framework standardises requirements that previously sat in eleven separate circulars covering stock exchanges, depositories, clearing corporations, brokers, mutual funds, and other regulated entities. Compliance is graded — the most systemic entities have the deepest obligations — but the five outcome principles apply to every entity in scope. This article walks through what the CSCRF requires, who falls under each tier, what cadence applies to VAPT and audits, and what your board must see to satisfy the framework.

What CSCRF replaces

Before CSCRF, a SEBI-regulated entity navigated overlapping circulars dating back to the 2015 stock-broker cybersecurity circular and the 2018 mutual fund cyber-resilience circular. CSCRF folds these into one document with a unified control taxonomy mapped to NIST CSF and ISO 27001:2022. The official text and supporting circulars are published by SEBI at sebi.gov.in; entities should always reference the latest version of the framework and any amendments published after the original 2024 issuance.

Scope — who CSCRF applies to

CSCRF applies to all SEBI-regulated entities (REs). The framework explicitly enumerates the categories and assigns each a tier under the graded approach. Coverage is comprehensive:

• Market Infrastructure Institutions (MIIs) — stock exchanges, clearing corporations, depositories.
• Qualified REs — large stock brokers, depository participants, asset management companies, mutual funds, KYC registration agencies.
• Mid-size REs — small to mid-size stock brokers, portfolio managers, alternative investment funds, investment advisers above a turnover threshold.
• Self-certification REs — small intermediaries below the threshold for full-tier obligations.

The exact thresholds — number of clients served, average daily turnover, custody value — are specified in the framework itself. Most entities know their tier from a SEBI circular sent directly; if you are unsure, your compliance officer should confirm with the relevant SEBI department in writing before designing the controls programme.

The five principles — Anticipate, Withstand, Contain, Recover, Evolve

CSCRF organises its outcome objectives around five principles that map cleanly to the NIST Cybersecurity Framework functions but are renamed to emphasise resilience over pure security posture.

1. Anticipate

Identify the assets, threats, and dependencies that matter. Maintain an asset inventory keyed to criticality. Run a continuous threat-intelligence subscription and consume sectoral feeds — at a minimum, CERT-In advisories, NCIIPC alerts where applicable, and the relevant exchange-issued advisories. The asset inventory feeds every other principle, so the data quality bar here is the most consequential investment in the entire programme.

2. Withstand

Implement preventive controls — secure configuration baselines, patch management, network segmentation, identity controls, and application security testing. CSCRF prescribes minimum control depth per tier; MIIs and Qualified REs must implement the full suite, mid-size REs a documented subset, self-certification REs a baseline aligned with their turnover.

3. Contain

Detect, triage, and contain incidents. Requires a Security Operations Centre — in-house for MIIs and Qualified REs, optionally outsourced under a documented model for mid-size REs. The SOC must cover 24x7 monitoring of designated critical systems with documented playbooks, detection engineering, and integration with the entity's incident response team.

4. Recover

Restore operations after disruption. Defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) per critical service. Tested DR drills — minimum once per financial year for MIIs and Qualified REs — with documented evidence of switchover, validation of trading or settlement continuity, and switchback. Backup integrity verification on a rolling schedule, with at least one offline copy resilient to ransomware encryption.

5. Evolve

Learn and improve. Post-incident reviews, lessons-learned, control updates, threat-model refreshes, and a documented annual review of the cybersecurity programme by senior management. The CSCRF treats Evolve as a programme-level requirement, not an after-the-fact activity — under- performing controls must be retired or upgraded, not perpetuated by exception.

Graded approach — MIIs vs Qualified REs vs mid-size vs self-certification

The cadence shown here is the framework baseline. SEBI may direct any RE to test more frequently following a sectoral incident, regulatory finding, or material change in the entity's architecture. Build the programme around the baseline but design the procurement contract to allow additional engagements at short notice.

VAPT obligations in detail

CSCRF requires VAPT — Vulnerability Assessment and Penetration Testing — performed by a CERT-In empanelled assessor for in-scope systems. The systems list includes: customer-facing trading platforms, order management systems, surveillance systems, public websites, mobile applications, third-party APIs in the trading or settlement path, and any system with cardholder data or PII at volume.

• VAPT report retained for at least five years and produced to SEBI on request.
• All Critical and High findings remediated within timelines defined in the framework — typically 30 days for Critical, 60 days for High, 90 days for Medium, with extensions only on documented compensating controls.
• Retest after remediation; the original report must be updated with retest evidence.
• VAPT triggered on every significant change — new application, new infrastructure, new third-party integration, major version upgrade.

For market-facing applications, MIIs additionally run a half-yearly external network and web application VAPT, plus an internal network VAPT covering the trading floor and core production networks. A scoped VAPT engagement with retest output and CSCRF-mapped reporting templates makes the SEBI submission clean.

Audit cycle and the auditor pool

CSCRF audits run annually for most regulated entities and half-yearly for MIIs. The auditor must be independent — a CERT-In empanelled cybersecurity audit firm, not the entity's internal audit function alone. The audit covers control design, operating effectiveness, and gap remediation from the previous cycle. Findings are categorised and reported to the entity's board with a management action plan.

The framework explicitly requires the audit report to be submitted to SEBI within timelines that track the entity's tier. MIIs typically submit to SEBI directly with simultaneous filing to their oversight department; smaller entities submit through the standard SEBI intermediary portals. The submission includes the executive summary, findings, management response, and the remediation timeline.

Board reporting requirements

Board oversight is the part of CSCRF that gets entities into trouble most often, because the obligations are organisational, not technical. The framework requires:

• A board-level cybersecurity committee or, where the entity's size makes a dedicated committee impractical, a documented sub-committee of the audit committee with a written charter.
• Quarterly briefings to the committee covering cyber risk posture, top findings, threat-intelligence highlights, and incident summaries.
• Annual board approval of the cybersecurity policy, the cybersecurity strategy, and the cybersecurity budget.
• Documented sign-off by the board on every cyber incident classified as material under the framework's severity matrix.
• Annual board-attested confirmation of CSCRF compliance, filed with SEBI.

The minute book of the cybersecurity committee is the single most-frequently-requested artefact in a SEBI inspection. Maintain it as if every entry will be reviewed by a regulator — because under CSCRF, eventually it will be.

Incident reporting under CSCRF

Cyber incident reporting under CSCRF runs in parallel with the CERT-In six-hour reporting obligation under the April 2022 directive. SEBI requires entities to report cyber incidents to their relevant exchange or SEBI department within prescribed timelines (typically the same calendar day for severe incidents, with full root-cause analysis filed within thirty days). Significant incidents trigger additional reporting to NCIIPC where the entity is also designated under the Information Technology Act's Critical Information Infrastructure provisions.

Build the incident-reporting matrix into your runbook so the IR commander does not have to reconstruct it under pressure: who is notified, in what form, on what timeline, with what content. The runbook should map every notification destination to a named contact, escalation path, and a template message.

Mapping CSCRF to your existing programmes

Entities that already maintain an ISO 27001 ISMS or operate under NIST CSF can usually evidence CSCRF compliance by reusing existing artefacts plus a CSCRF-specific overlay document showing the mapping. A net-new programme is rarely required; what is required is the framework-specific naming, reporting cadence, and board-level governance overlay.

Common gaps SEBI inspections find

• Asset inventory missing third-party SaaS used by trading or settlement workflows.
• VAPT scope excludes mobile applications or omits the underlying API.
• Critical findings remediated but no retest evidence on file — auditors cannot close the loop.
• Board minutes record cybersecurity discussions at the level of "noted" without documented decisions.
• Incident response playbooks not exercised in the past twelve months — tabletop or live drill required.
• Outsourced SOC contracts missing data residency, breach notification, and audit-rights clauses.

A 90-day action plan

1. Days 0-30 — confirm tier, refresh asset inventory, run a CSCRF gap assessment against the five principles.
2. Days 30-60 — close documentation gaps (policy, charter, runbook), schedule the VAPT and audit, ratify board committee charter.
3. Days 60-90 — execute VAPT, remediate critical findings, prepare the first quarterly board pack, file the annual board-attested compliance confirmation.

The fastest route through this plan is to treat CSCRF as a delivery programme with weekly stand- ups, a single named owner reporting to the CISO or equivalent, and a fixed end-date for the gap closure phase. Programmes that drift do so because no individual was made accountable for the framework compliance artefact set.

See AxVeil's VAPT service and compliance servicefor CSCRF-aligned engagement design and reporting — and read the "Where AxVeil Fits" section below for the honest framing on empanelment.

Where AxVeil Fits

Plain language up front. AxVeil LLP is not currently CERT-In empanelled. The SEBI CSCRF audit submission for MIIs and Qualified REs requires a CERT-In empanelled cybersecurity audit firm on the signed report — that is the legal floor for the formal compliance submission to SEBI. AxVeil is a 2026-registered LLP. Empanelment requires three years of audited financials, ISO 27001 firm-level certification, a 5+ qualified- auditor headcount and a turnover floor — we are on track to file in the 2027 cycle and expect empanelment in 2028. Until then we say so.

That does not lock SEBI-regulated entities out of working with AxVeil today. The value AxVeil actually delivers against CSCRF, framed against the five principles:

• Pre-audit readiness sweep against the five principles (Anticipate / Withstand / Contain / Recover / Evolve).Find the CSCRF-mappable gaps before the empanelled audit walks in. Asset inventory completeness, preventive control depth, SOC content gaps, RTO / RPO drift, post-incident review cadence — all surfaced and fixed in AxVeil's window so the formal CSCRF audit submission is clean.
• Operator-led VAPT outside the regulator-facing submission. The half-yearly MII external network and web application VAPT, change-trigger VAPT on new trading platforms and order management systems, internal AD red team exercises against named threat actors targeting the capital-markets sector — AxVeil contracts directly because none of this is the formal CSCRF audit submission.
• Advisory on findings.Translation between the CSCRF principle taxonomy, the NIST CSF function language your engineering team thinks in, and the ISO 27001:2022 controls that already underpin most regulated entities' ISMS. The CSCRF mapping table earlier in this article exists for exactly that reason — most of the actual programme work is the bridge between the framework, the engineering tickets and the board pack.
• Partner referral to a vetted CERT-In empanelled firm we work with for the formal piece. When the annual (or half-yearly, for MIIs) CSCRF audit submission is due, we refer the regulator-facing engagement to one of our CERT-In empanelled partner primes — see /partnersfor the partner roster and the subcontract-economics breakdown — or, where the prime accepts, AxVeil delivers under sub-contract on the prime's letterhead. The buyer gets a compliant signed CSCRF audit and AxVeil's operator depth, with no pretence about the empanelment list.

Honesty is the differentiator. SEBI compliance officers and audit-committee chairs have heard every flavour of empanelment fudge — "our parent is empanelled", "we apply CERT-In methodology", "we are in the application pipeline" — and the credibility tax is real. Saying out loud that AxVeil is not on the list, then explaining the two paths available today, is the trust play. Most of the work that improves a regulated entity's actual cyber posture happens outside the formal CSCRF audit submission window; AxVeil is built for that work, and the partner network handles the submission window.

FAQ