SEBI CSCRF Clarifications: What the April 2025 Clarification and FAQ Cycle Means in Practice

SEBI CSCRF Clarifications: What the April 2025 Clarification and FAQ Cycle Means in Practice

The biggest mistake a regulated entity can make with CSCRF is to treat the clarifications as “extra reading.”

They are not.

They are the difference between a cyber compliance plan that looks correct on paper and one that can actually survive an audit, management review, or regulator query.

SEBI issued the main Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities on August 20, 2024. The April 30, 2025 circular then clarified important implementation aspects, and SEBI’s June 11, 2025 FAQs further explained practical issues around CSCRF and cloud adoption. So, strictly speaking, the FAQ was released in June, but it forms part of the same 2025 clarification cycle that regulated entities need to read together.

For compliance and IT teams, the message is clear: CSCRF implementation is not only about buying tools, appointing vendors, or updating policies. It is about getting three planning decisions right.

First, what category are we in?
Second, what audit cycle applies to us?
Third, what evidence will prove implementation?

If these three are weak, the rest of the project becomes unstable.

The first practical issue is category determination.

The April 2025 clarification cycle matters because CSCRF obligations vary by category. A regulated entity cannot sensibly plan cyber audit, SOC arrangements, reporting, VAPT, or evidence collection unless it knows which category applies. Mondaq’s coverage of the April 30 circular notes that the category is decided at the beginning of the financial year based on previous financial-year data, and once decided, it remains the category for that financial year even if parameters change mid-year.

That sounds simple, but it creates a real operating requirement.

Every regulated entity should maintain a category determination file. This file should not be a casual email. It should show the previous-year data used, the registration category considered, the threshold logic applied, who reviewed it, and who approved the conclusion.

This is especially important for entities with multiple SEBI registrations. SEBI’s FAQ states that where a regulated entity is registered under more than one category, the provisions of the highest category under which it falls will apply.

That one clarification can change the compliance burden. A firm cannot pick the lighter category because one business line is smaller or less active. The correct question is: across our registrations and activities, what is the highest applicable CSCRF category?

The second issue is audit timing.

Many teams confuse implementation deadlines with audit periods. That can create poor planning. The FAQ clarifies that CSCRF periodicities are based on the financial year and that cyber audit is to be conducted after the end of the audit period. It gives the example that where an entity is required to conduct cyber audit once a year, the audit for April 2025 to March 2026 would start after March 2026.

This does not mean firms can relax until audit season.

It means the evidence clock starts earlier.

If the audit period is April to March, then the entity should be able to show that controls operated during that period. Waiting until the audit begins to build the file is too late. Access reviews, VAPT closure, incident response testing, asset inventory updates, vendor checks, SOC monitoring, policy approvals, and management review evidence should be created as the year progresses.

The third issue is transition planning.

For audit periods before FY 2025-26, the FAQ refers to flexibility to undertake cyber audit in accordance with CSCRF or previously issued SEBI cybersecurity-related circulars, as applicable. But for FY 2025-26 onwards, the audit is to be as per the August 20, 2024 CSCRF circular read with clarifications.

This matters because teams should not maintain two confused control files. They should clearly label what applies to the older period and what applies from FY 2025-26 onward. Otherwise, audit discussions can become messy: old circular expectations, new CSCRF controls, transition extensions, and clarification notes all get mixed together.

A clean CSCRF plan should therefore have a timeline page.

It should show the applicable implementation date, the audit period, the expected audit start window, the reporting authority, key internal milestones, and evidence owners. If the entity benefited from any extension or clarification, that should be recorded with the circular reference.

The fourth issue is system scope.

CSCRF is not only a policy requirement. It applies to actual systems, infrastructure, applications, vendors, data flows, monitoring arrangements, and response capabilities. SEBI’s FAQ clarifies that audit coverage for entities with business in other sectors is limited to IT infrastructure, software, and applications under SEBI’s purview, but only where those systems are properly segregated; ancillary or connected systems used to access or communicate with SEBI-purview systems should also be covered.

This is a practical warning.

If your systems are not clearly segregated, your audit scope may expand. If your back-office system connects to client records, reporting utilities, cloud infrastructure, vendor tools, or internal applications, the firm needs a proper system map. Without that map, teams may under-scope the audit or miss connected risks.

The fifth issue is closure evidence.

CSCRF implementation will produce findings: VAPT findings, audit observations, patch gaps, access issues, vendor gaps, incident-response weaknesses, documentation gaps, and cloud responsibility issues. SEBI’s FAQ clarifies that certain VAPT observations are validated against closure timelines, with other vulnerability observations apart from patch implementation validated against the VAPT observation closure timeline of three months, subject to the graded approach based on criticality.

The lesson is direct: closure needs proof.

A finding should not be closed because IT says it is fixed. The file should contain the finding, severity, owner, target date, action taken, retest result where required, closure evidence, and reviewer sign-off. If closure depends on a vendor or cloud provider, the responsibility split should be documented.

The sixth issue is cloud accountability.

The FAQ states that responsibilities between the cloud service provider and regulated entity for vulnerability closure and patch deployment should be clearly demarcated in the contractual agreement. This is implementable advice, not theory.

Regulated entities should review whether their cloud and technology contracts actually support CSCRF compliance. Who applies patches? Who provides logs? Who owns encryption-key controls? Who supports audit evidence? Who reports incidents? Who signs off remediation?

If the contract is vague, the compliance file will also be vague.

The practical output of the clarification cycle should be a CSCRF implementation binder with seven sections:

Category determination.
System and application inventory.
Audit-period calendar.
Control implementation tracker.
VAPT and audit finding closure.
Vendor and cloud responsibility matrix.
Management review and evidence file.

That is the operating version of CSCRF compliance.

The point is not to create more paperwork. The point is to avoid last-minute cyber compliance theatre. When audit time arrives, the entity should not be asking which category applies, which systems are in scope, which period is being audited, which vendor owns what, or where closure evidence is stored.

Those answers should already exist.

SEBI’s clarification and FAQ cycle gives regulated entities a more practical map. But a map is useful only if someone converts it into internal ownership, timelines, and evidence.

For market participants, the next step is simple: do not read the CSCRF clarifications as legal updates. Convert them into an implementation plan.