SEBI CSCRF Compliance: Requirements, Implementation and Audit Guide

Understanding SEBI’s Cybersecurity Framework: What Compliance Leaders Need to Know

The SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), introduced in August 2024, represents one of the most comprehensive regulatory mandates for India’s capital markets ecosystem. For compliance officers at brokerages, asset management companies, depositories, and clearing corporations, SEBI cybersecurity framework compliance is no longer a future consideration. It is an immediate operational requirement with hard deadlines and specific evidence expectations.

This guide breaks down what the framework actually requires, who falls under its scope, the timelines you need to track, and how to build a compliance program that satisfies both the letter and spirit of the regulation.

What the SEBI CSCRF Actually Covers

The CSCRF is not simply another cybersecurity guideline. It establishes a mandatory baseline for cyber governance, risk management, security operations, and incident response across all SEBI-regulated entities. The framework draws from global standards like ISO 27001, NIST, and COBIT while incorporating India-specific requirements around data localization, CERT-In reporting, and board-level accountability.

At its core, the CSCRF is built around five cyber-resilience goals: Anticipate, Withstand, Contain, Recover, and Evolve. These goals are mapped to cybersecurity functions covering areas such as governance, identification, protection, detection, response, and recovery.

The framework brings together cybersecurity and cyber-resilience requirements for SEBI-regulated entities, with requirements that vary based on the category of regulated entity and the systems, processes, and risks involved.

The Governance Structure Requirement

SEBI mandates a formal cyber governance structure with clearly defined roles. This includes a designated Chief Information Security Officer (CISO) or equivalent, a Cyber Security Committee at the board level, and documented escalation procedures. For smaller entities, the framework allows some flexibility in how these roles are structured, but the accountability requirements remain non-negotiable.

The framework also requires entities to maintain a comprehensive cybersecurity policy that addresses asset classification, access controls, vendor risk, incident response, and business continuity. This policy must be reviewed annually at minimum and updated whenever material changes occur in the threat landscape or business operations.

Who Falls Under the CSCRF’s Scope

The CSCRF applies to all SEBI-regulated entities, but it introduces a tiered classification system that determines the depth and rigor of compliance requirements. Understanding which category your organization falls into is essential for resource planning and timeline management.

Entity Classification Under CSCRF

The classification criteria include factors like trading volume, client base size, assets under management, and systemic importance. Entities should self-assess their classification and seek clarification from SEBI if there is ambiguity. Getting the classification wrong can result in either over-investment in controls or, more problematically, under-compliance that triggers regulatory action.

Core Requirements: Breaking Down the Five Pillars

Governance Requirements

The governance pillar establishes accountability structures that extend from the board level to operational teams. SEBI expects documented evidence of board oversight, including meeting minutes that demonstrate cybersecurity discussions, risk appetite statements approved at the highest level, and clear lines of responsibility for cyber incidents.

Consider a mid-sized brokerage with operations across 15 branches and 200 employees. Under the CSCRF, this entity needs to demonstrate that its board receives quarterly cybersecurity updates, that there is a named individual responsible for cyber risk (even if not a full-time CISO), and that policies exist for all major security domains. The documentation burden alone requires a structured approach to policy management and evidence collection.

Identify: Asset and Risk Management

The Identify pillar requires entities to maintain comprehensive inventories of hardware, software, data assets, and third-party connections. Beyond simple asset lists, SEBI expects risk assessments that map threats to specific assets and quantify potential impacts. This risk assessment must feed into treatment plans with documented remediation timelines.

Asset inventory: REs are expected to maintain a comprehensive and accurate inventory of their IT assets. Changes to existing assets, including additions, deletions, or modifications, should be reflected in the inventory within three working days. SEBI’s FAQs also clarify that smaller REs with lean IT environments may maintain inventories manually, provided they are periodically updated and meet the CSCRF’s asset-management requirements.

Protect: Security Controls Implementation

The Protect pillar covers the technical and administrative controls that prevent cyber incidents. This includes access management (principle of least privilege, multi-factor authentication for privileged access), network security (segmentation, firewalls, intrusion prevention), data protection (encryption at rest and in transit), and endpoint security.

SEBI has specified minimum standards for several control areas. For instance, MIIs must implement network segmentation that isolates critical trading systems from corporate networks.

All entities must enforce password policies that meet complexity requirements and mandate regular rotation.

Data classification schemes must distinguish between public, internal, confidential, and restricted data, with corresponding protection measures for each level.

Password controls: REs are required to implement strong password controls covering password complexity, minimum length and history, change of password upon first login, and a maximum validity period. Credential data must also be stored using strong hashing algorithms. These requirements apply to all REs except small-size and self-certification REs.

Log management: REs should maintain appropriate system, application, network, security, and other relevant logs for monitoring, investigation, and audit purposes. Records of user access to critical systems should, wherever possible, be uniquely identified and maintained securely for a period of not less than two years.

Detect: Security Operations and Monitoring

Detection requirements scale with entity classification. MIIs must operate or contract with a 24×7 Security Operations Center (SOC) capable of real-time monitoring and threat detection. Qualified Regulated Entities need SOC capabilities that may be partially outsourced but must maintain in-house expertise for incident triage. Smaller entities can rely on managed security services but must still demonstrate active monitoring.

The framework mandates specific log retention periods (minimum 2 years for critical systems), correlation capabilities that can identify attack patterns across multiple data sources, and regular reviews of detection rule effectiveness. Auditors will look for evidence that detection capabilities are not merely deployed but actively maintained and tested.

Incident Response and Reporting

SEBI-regulated entities must maintain documented procedures for detecting, responding to, and reporting cybersecurity incidents.

For cyberattacks, cybersecurity incidents, and breaches covered by the CERT-In cybersecurity directions, the CSCRF requires notification to SEBI and CERT-In within 6 hours of noticing or detecting the incident, or being informed of it. The incident must also be reported through SEBI’s Incident Reporting Portal within 24 hours. Other cybersecurity incidents are subject to a 24-hour reporting requirement to the applicable authorities.

The reporting process has also evolved beyond the original 2024 framework. SEBI’s August 2026 circular aligned its Cyber Incident Reporting Portal with the FIRE format, so regulated entities should follow the latest reporting process and formats rather than relying solely on the original CSCRF reporting procedure.

Recovery Time Objective (RTO) and Recovery Point Objective (RPO): For disruption of one or more critical systems, the RE should declare the incident as a disaster within 30 minutes based on its business impact analysis. The CSCRF specifies an RTO of two hours for resumption of critical operations and an RPO of 15 minutes for all REs.

Compliance Timelines: What’s Due When

The CSCRF was introduced with phased implementation requirements based on the category of the SEBI-regulated entity. The original framework specified implementation milestones for governance, cybersecurity controls, Security Operations Centre (SOC), VAPT, and cyber audits.

SEBI subsequently issued extensions and clarifications to the implementation timelines. For regulated entities other than Market Infrastructure Institutions (MIIs), KYC Registration Agencies (KRAs), and Qualified Registrars to an Issue and Share Transfer Agents (QRTAs), the final extended implementation date was August 31, 2025.

MIIs, KRAs, and QRTAs were excluded from these extensions and remained subject to the original implementation timeline.

The dates below should therefore be read in conjunction with the latest SEBI circulars and FAQs rather than as standalone current deadlines.

These dates relate to adoption and implementation of the CSCRF.

They should not be confused with the recurring timelines for VAPT, cyber audits, reporting, and closure of observations, which continue to operate according to the requirements applicable to each category.

SEBI’s June 2025 FAQ also clarifies that the periodicities specified in the CSCRF are based on the financial year.

Evidence and Audit Expectations

SEBI-empaneled auditors conducting CSCRF assessments expect more than policy documents. They look for evidence that controls are implemented, operating effectively, and producing measurable outcomes. Understanding what constitutes acceptable evidence can mean the difference between a clean audit and extended remediation cycles.

Documentation That Auditors Expect

Policy documents must be version-controlled with clear approval trails. Auditors will verify that policies have been formally approved by appropriate authorities (board for overarching policies, CISO for operational procedures), that review dates are current, and that employees have attested to reading and understanding relevant policies.

For technical controls, auditors expect configuration evidence, not just statements that controls exist. This includes firewall rule exports, access control lists from critical systems, encryption configuration screenshots, and vulnerability scan reports. The evidence must be dated and attributable, showing when controls were implemented and who verified them.

Incident response evidence includes logs from past incidents (even minor ones), post-incident review documentation, and records of tabletop exercises. Auditors assess whether the organization learns from incidents and whether improvements are tracked to completion.

Common Audit Findings to Avoid

Several findings recur across CSCRF audits. Incomplete asset inventories rank high, particularly for cloud assets and third-party integrations that fall outside traditional IT management. Stale access rights, where former employees or role changes haven’t been reflected in system access, appear frequently. Lack of evidence for periodic reviews, even when reviews occur informally, creates compliance gaps that are easily avoided with proper documentation practices.

The gap between having controls and proving controls often catches organizations off guard. A brokerage might have robust network segmentation, but without documented network diagrams, firewall rule reviews, and penetration test results validating the segmentation, auditors cannot credit the control as compliant.

What a CSCRF Audit Actually Looks For

A CSCRF audit is not simply a review of whether cybersecurity policies exist. The audit process is designed to establish whether the applicable controls are implemented, whether they operate as intended, and whether the regulated entity can demonstrate compliance with documentary and technical evidence.

SEBI’s audit framework requires findings to be documented with details such as the affected system, nature and risk rating of the finding, relevant CSCRF clause, impact analysis, root-cause analysis, corrective action, management response, and supporting evidence reviewed by the auditor.

This means that a compliance gap needs to be traceable from the requirement being assessed through the finding and the evidence supporting the assessment.

In practice, this makes evidence traceability an important part of CSCRF readiness.

An organization may have a cybersecurity policy, conduct VAPT, maintain asset inventories, and perform periodic audits, but still face difficulty during an audit if it cannot connect those activities to the specific CSCRF requirements they address and produce the underlying evidence when required.

SEBI also requires the closure of audit observations to be tracked. Open observations remaining three months after completion of a cyber audit must be approved by the relevant IT Committee and closed before the next audit exercise.

For compliance teams, the practical implication is straightforward: CSCRF readiness should be managed as an ongoing control and evidence process, rather than as a preparation exercise immediately before the annual cyber audit.

Operationalizing SEBI Cybersecurity Framework Compliance

Moving from understanding requirements to implementing a sustainable compliance program requires systematic approaches to policy management, evidence collection, and ongoing monitoring.

Building the Policy Foundation

CSCRF implementation should begin by mapping the applicable requirements to the policies, procedures, and controls already operating within the organization.

Many regulated entities will already have cybersecurity policies, information-security standards, access-control procedures, incident-response plans, and business-continuity processes in place.

The first question is therefore not what policies need to be written, but which existing controls already address the CSCRF and where gaps remain.

This mapping should establish a clear relationship between the regulatory requirement, the organization’s policy or procedure, the control implemented to address it, and the evidence that demonstrates the control is operating.

Where an existing policy only partially addresses a CSCRF requirement, the gap should result in a defined action rather than another standalone document.

The framework itself distinguishes between documented information such as policies and procedures and the operational controls and compliance activities that sit beneath them.

For larger REs, SEBI also expects documented compliance management processes covering assessment of applicable requirements, development of policies and procedures, implementation of controls, employee training, monitoring and review, and regular audits and reporting.

This creates a more useful policy structure: policies establish the organization’s principles and accountability, procedures translate those principles into operational activity, and controls provide the mechanism through which compliance is actually performed and evidenced.

The objective is not to create a larger library of cybersecurity documents. It is to establish a traceable structure in which every applicable CSCRF requirement has an owner, an operational response, and evidence that can be produced when the organization needs to demonstrate compliance.

Establishing Evidence Collection Workflows

A control is only useful for compliance purposes if the organization can demonstrate that it was implemented and operated. This makes evidence collection an important part of CSCRF compliance rather than an activity reserved for the cyber audit.

For each applicable CSCRF requirement, the organization should be able to identify the control responsible for addressing it, the person or team responsible for operating that control, the activity that needs to be performed, and the evidence generated by that activity. This creates a traceable path from the regulatory requirement to the control and ultimately to the evidence that demonstrates compliance.

The evidence itself will vary depending on the requirement. It may include policies and procedures, asset inventories, configuration records, vulnerability assessments, incident records, access reviews, training records, audit reports, or records demonstrating that corrective actions were completed.

SEBI’s audit format reinforces this relationship. The consolidated CSCRF audit report requires auditors to identify the applicable control, the documentary evidence or physical inspection used to assess it, the resulting finding and compliance status, and any corrective action required.

For compliance teams, this means evidence should be collected and maintained as part of the normal operation of the control. Waiting until the annual audit to reconstruct evidence creates a separate compliance exercise and makes it harder to establish whether a control was consistently operating throughout the audit period.

A well-structured evidence workflow therefore connects each requirement to its control, owner, activity, and supporting evidence, while maintaining enough history to demonstrate what was performed and when. This turns audit preparation from a document-gathering exercise into an ongoing compliance process.

Integrating Cyber Risk With Compliance

CSCRF compliance should not operate separately from the organization’s broader risk-management process. The framework requires applicable REs to identify, analyze, evaluate, prioritize, respond to, and continuously monitor cybersecurity risks. For MIIs, Qualified REs, and mid-size REs, this is explicitly part of the required cyber risk management framework.

This creates an important connection between a regulatory requirement and the organization’s actual risk posture. A vulnerability, an unresolved audit observation, an unsupported software component, a third-party dependency, or an incident should not exist only as a technical issue. Where it creates a compliance exposure, the organization should be able to identify the relevant CSCRF requirement, assess the risk, assign ownership, and track the remediation through to closure.

The same principle extends to third parties. SEBI’s framework places accountability on the RE for cybersecurity risks associated with third-party services, while its 2026 guidance calls for periodic risk assessment of third-party service providers and scenario-based testing of cybersecurity risks.

For compliance teams, this means CSCRF readiness is not simply a question of whether individual controls exist. It is also about whether the organization can identify which requirements are exposed, understand the associated risk, track remediation, and demonstrate that material issues are being addressed.

A useful CSCRF compliance process therefore connects requirements, controls, risks, owners, remediation actions, and evidence rather than maintaining each as a separate record.

Preparing for Continuous Compliance

The CSCRF is not a one-time certification exercise. SEBI has established ongoing reporting requirements, periodic assessments, and expectations for continuous improvement. Organizations should build compliance programs that accommodate evolving requirements without major restructuring.

This means investing in scalable processes rather than point-in-time fixes. Policy management systems that track versions, approvals, and attestations. Risk assessment methodologies that can incorporate new threat categories as they emerge. Evidence repositories that maintain audit trails and support rapid retrieval. Reporting capabilities that can generate board presentations, regulatory submissions, and audit documentation from the same underlying data.

What a CSCRF Compliance Management System Should Track

Once CSCRF requirements have been mapped to an organization, the challenge becomes keeping that compliance structure operational. A CSCRF compliance management system can provide the structure needed to manage requirements, controls, ownership, activities, and evidence.

A compliance management system should allow the team to map each applicable CSCRF requirement to the control that addresses it, assign ownership, define the activity or review that needs to be performed, and retain the evidence generated by that activity. It should also provide visibility into open gaps, remediation actions, audit observations, and changes that could affect the organization’s compliance position.

This becomes particularly important when cybersecurity requirements overlap with other regulatory obligations. The same policy, control, risk assessment, vendor review, or evidence record may support requirements under multiple frameworks. Maintaining these relationships in separate spreadsheets or audit folders makes it difficult to understand the organization’s actual compliance position.

The objective is therefore not simply to maintain a CSCRF checklist. It is to maintain a traceable compliance record from requirement to control, control to activity, and activity to evidence, with ownership and status visible throughout the lifecycle.

For organizations managing CSCRF alongside other regulatory frameworks, this approach also provides a foundation for consolidating compliance operations rather than creating another standalone cybersecurity compliance process.

Moving Forward with CSCRF Compliance

CSCRF compliance should be treated as an ongoing process rather than a project completed once the initial implementation or cyber audit is finished.

Controls change, risks change, systems and vendors change, and SEBI continues to issue clarifications and technical guidance. The organization therefore needs a way to keep requirements, controls, ownership, evidence, risks, and remediation actions aligned as those changes occur. SEBI’s own CSCRF materials have continued to evolve through FAQs, clarifications, technical clarifications, and subsequent cybersecurity guidance. (sebi.gov.in)

For compliance teams, the practical objective is simple: know which requirements apply, know who owns them, know whether the associated controls are operating, and be able to produce the evidence when required.

That makes CSCRF compliance less about preparing for a point-in-time audit and more about maintaining a reliable compliance record throughout the year.