SEBI CSCRF, the Cybersecurity and Cyber Resilience Framework, is the Securities and Exchange Board of India’s mandatory cybersecurity framework for SEBI-regulated entities. Issued in August 2024, it replaces SEBI’s earlier cyber circulars with one framework, graded by entity size and type, and after two extensions its adoption deadline for most entities passed on 31 August 2025.
This guide does two things. It assembles the SEBI documents issued since August 2024 into one current timeline. And it covers what most CSCRF guides leave out: what the framework’s access control and logging requirements mean for the cloud identities your systems, and increasingly your AI tools, run on.
What the SEBI CSCRF is
SEBI issued the Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities by circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024. Before it, SEBI had issued separate cybersecurity circulars for different kinds of regulated entity over several years. The CSCRF supersedes those circulars, guidelines and advisories, which are listed in an annexure to the framework.
The SEBI CSCRF is a mandatory, category-based cybersecurity framework that sets standards for SEBI-regulated entities, from stock exchanges and depositories to brokers, mutual funds and registrars.
The framework is built around two ideas. The first is a set of five cyber resiliency goals: anticipate, withstand, contain, recover and evolve. The second is six cybersecurity functions, which will be familiar to anyone who knows the NIST Cybersecurity Framework: governance, identify, protect, detect, respond and recover. Requirements are then written as standards under each function, with guidelines on how to meet them.
The requirements are graded. A large market infrastructure institution has to meet far more of them, and more often, than a small entity. That grading is based on the category an entity falls into, which is the first thing any regulated entity needs to establish.
Unlike a committee report, the CSCRF is not advisory. It is a SEBI circular, and compliance is audited.
Who the CSCRF applies to
The CSCRF applies to SEBI-regulated entities (REs). It sorts them into five categories, with obligations scaled to each.
| Category | Who typically falls here | Examples of what the category brings |
| Market Infrastructure Institutions (MIIs) | Stock exchanges, clearing corporations, depositories | Their own SOC; ISO 27001 certification; half-yearly Cyber Capability Index (CCI) assessment by a third party |
| Qualified REs | Larger intermediaries by the thresholds SEBI sets for each RE type | Their own SOC; ISO 27001 certification; yearly CCI self-assessment |
| Mid-size REs | Intermediaries below the qualified thresholds | A reduced set of standards and less frequent reporting |
| Small-size REs | Smaller intermediaries | May onboard to the Market SOC (M-SOC) run by NSE and BSE, or use a group SOC |
| Self-certification REs | The smallest entities | May onboard to the M-SOC; submit compliance by self-certification |
The thresholds that decide the category differ by type of entity. According to SEBI’s June 2025 FAQs, brokers are categorised on measures such as clients and trading activity, funds and portfolio managers on assets under management, and registrars on folios serviced. The thresholds were revised by the clarifications circular of 30 April 2025, so a categorisation done before that date should be checked again against the current figures. Take the thresholds from that circular, not from a summary.
The FAQs also settle some edge cases. A depository participant that is also a stock broker is categorised under the stock broker criteria. A depository participant that is a bank, NBFC, mutual fund, registrar, financial institution, custodian or clearing corporation is treated as a Qualified RE.
The SEBI CSCRF timeline, including every extension and clarification
SEBI has issued at least eight documents on the CSCRF since August 2024. They are listed here in order, with what each changed.
| Date | Document | What it did |
| 20 Aug 2024 | Circular CIR/2024/113 | Issued the CSCRF. Compliance from 1 January 2025 for REs already covered by SEBI cyber circulars, and from 1 April 2025 for REs new to them |
| 31 Dec 2024 | Circular CIR/2024/184 | Clarifications. Regulatory forbearance until 31 March 2025 for REs showing meaningful progress; KYC registration agencies and depository participants moved to 1 April 2025; data localisation provisions kept in abeyance until further notice |
| 28 Mar 2025 | Circular CIR/2025/45 | Extended the deadline to 30 June 2025 for all REs except MIIs, KRAs and Qualified RTAs |
| 30 Apr 2025 | Circular CIR/2025/60 | Clarifications, including revised categorisation criteria |
| 11 Jun 2025 | FAQs on CSCRF | Answers on categorisation, SOC, audits, CCI, cloud and SBOM |
| 30 Jun 2025 | Circular CIR/2025/96 | Extended the deadline again, to 31 August 2025, with the same exclusions for MIIs, KRAs and Qualified RTAs |
| 28 Aug 2025 | Circular CIR/2025/119 | Technical clarifications to the framework’s standards |
| 5 May 2026 | Advisory on AI tools for vulnerability detection | An advisory to all REs on AI-accelerated threats, issued with reference to the CSCRF |
As at the date of this page, the position is as follows. The adoption deadline for most REs was 31 August 2025. MIIs, KRAs and Qualified RTAs were held to the earlier dates. The FAQs state that any cyber audit for the audit period from financial year 2025-26 onwards must be conducted under the CSCRF circular. So the first full-year CSCRF audits cover April 2025 to March 2026, and they begin after that period ends.
SEBI continues to issue clarifications, so check the SEBI circulars page for anything newer than this page.
What the framework actually requires
The CSCRF’s requirements are organised under its six functions. What follows is a summary of the main areas; the standards themselves, and which apply to your category, are in the framework document.
Governance. REs must have board-approved cybersecurity and cyber resilience policies, a designated CISO and defined responsibilities. The FAQs allow a group-level CISO across entities in the same group, and restrict part-time CISOs.
Identify. REs must identify and classify their critical systems and data, and manage third-party risk. The FAQs are explicit that REs remain solely accountable for all aspects of third-party services, including cloud services.
Protect. This is the largest group of standards. It includes identity management, authentication and access control, grouped under the standard labelled PR.AA; data security, including encryption; patch management, with the FAQs citing one week for high-severity vulnerabilities; and a software bill of materials for software supporting core and critical operations. For MIIs and Qualified REs, the framework calls for regular review of user access rights and privileged user activity.
Detect. REs must have security monitoring through a Security Operations Centre. MIIs and Qualified REs run their own; smaller REs may onboard to the M-SOC established by NSE and BSE, or use a group SOC, and submit SOC efficacy reports. The FAQs describe the logs to collect as including system, application, network, database, security, audit trail and event logs, under an effective log collection and retention policy.
Respond and recover. REs need incident response and recovery plans, with the FAQs citing a recovery time objective of two hours and a recovery point objective of 15 minutes for critical systems.
Assurance. Cyber audits are conducted at a frequency set by category, with vulnerability assessment and penetration testing findings to be closed within three months of the report, and MIIs and Qualified REs submit a Cyber Capability Index score.
Cloud. The framework includes a cloud services section. The FAQs describe due diligence on cloud service providers, MeitY empanelment, and data centre standards. Note that the December 2024 circular put the data localisation provisions in abeyance; check the current status of the cloud and localisation requirements against the latest circular before relying on either.
Where cloud identity fits into CSCRF obligations
Most of a broker’s or fund’s systems now run in AWS, Azure or Google Cloud, and most of the activity in those accounts is not performed by people. It is performed by service accounts, IAM roles, managed identities and API keys: the identities that systems and automation authenticate as [/blog/non-human-identity/]. The CSCRF’s identity, logging and monitoring standards apply to those identities just as they do to user accounts. Five areas deserve attention.
Access governance for non-human identities
The requirement to review user access rights and privileged activity is usually implemented for people, through an identity governance tool or an HR-driven process. Machine identities are often left out. An auditor asking for evidence of access review should get it for IAM roles, service principals and service accounts too. In each cloud, the raw data exists: GetAccountAuthorizationDetails and the IAM credential report on AWS; service principals, managed identities and role assignments through Microsoft Graph and Azure Resource Graph on Azure; Cloud Asset Inventory on Google Cloud.
Audit logging that is actually switched on
Several important cloud logs are off by default. On AWS, CloudTrail data events, which record reads of S3 objects and DynamoDB items, must be enabled separately and cost extra. On Azure, Microsoft Graph activity logs and most resource logs need a diagnostic setting, and Entra sign-in logs are kept in the portal for only 7 to 30 days depending on licence. On Google Cloud, Data Access audit logs are off by default except for BigQuery. An RE can believe its logging meets the CSCRF when, for data access in particular, it does not. Our guide to CloudTrail data events [/blog/cloudtrail-data-events/] covers the AWS side.
Identities created outside the deployment pipeline
An identity or access key created by hand in the console, rather than by the approved infrastructure-as-code pipeline, bypasses the change and approval process the CSCRF expects. These creation events are recorded by default: CreateUser, CreateAccessKey and CreateRole in CloudTrail; application and credential changes in Entra audit logs; CreateServiceAccount and CreateServiceAccountKey in Google Cloud Admin Activity logs. A simple control is to alert when the caller is not a known pipeline identity.
Identities left behind by ended projects and vendors
Projects end, vendor contracts lapse and pilots close, but the identities they created often remain, with no owner and standing access. A role that still trusts a former vendor’s cloud account, or a service principal with a client secret that nobody has used in six months, is exactly the kind of finding an auditor understands immediately. Last-used data is available natively: role and access key last-used on AWS, service principal sign-in logs on Azure, and Activity Analyzer on Google Cloud.
Granted versus used permissions as evidence of least privilege
The strongest evidence of least privilege is not a policy document. It is a comparison of what each identity is allowed to do with what it has actually done over 30 to 90 days, and a record of the excess being removed. AWS IAM Access Analyzer and Google IAM Recommender produce this natively. Azure is harder, because Microsoft retired Entra Permissions Management, so usage has to be reconstructed from activity and resource logs.
A SEBI CSCRF checklist for cloud teams
This is not a substitute for the framework’s own standards, which vary by category. It is a list of the cloud identity and logging items that most often turn out to be missing when an audit arrives.
- Confirm your category against the April 2025 thresholds, and record the calculation.
- List every cloud account, subscription and project in scope, including development and test environments that hold copies of production data.
- Inventory every machine identity in each one: IAM roles and users, service principals and managed identities, service accounts, and every long-lived key or secret.
- Record an owner for each identity in a tag, label or owner field that a script can read.
- Remove or disable identities with no owner and no use for 90 days, after checking with the teams that might depend on them.
- Review external trust: roles that trust other AWS accounts, multi-tenant apps with consent in your Entra tenant, and federation rules that accept tokens from outside providers.
- Confirm which audit logs are actually on, where they go, and how long they are kept. Check data access logging specifically.
- Make sure identity and audit logs reach your SOC, whether your own, a group SOC or the M-SOC.
- Include machine identities in the periodic access review, with the evidence kept for the auditor.
- Keep a granted-versus-used report for privileged identities, and a record of what was removed.
Most of these items are one-off work followed by a light recurring check. The expensive ones are items 7 and 8, because a gap there cannot be fixed after the fact.
AI systems under CSCRF
The CSCRF itself does not contain AI-specific requirements. It predates the current wave of AI agents, and its standards are written for systems generally.
SEBI has since addressed AI directly. Its advisory of 5 May 2026 on emerging AI tools for vulnerability detection asks REs, among other things, to patch known vulnerabilities immediately, keep an inventory of APIs with strong authentication and authorisation, expedite M-SOC onboarding where applicable, and prepare plans on the use of AI in detection and mitigation. Read the advisory itself for the full text.
The practical point for an RE running AI tools is simpler. Every AI system in production runs on a cloud identity: a role, a service principal, a service account or an API key. Every existing CSCRF obligation on access control, logging and monitoring already applies to that identity. For banks and NBFCs, the RBI’s committee has made similar recommendations; see our guide to the RBI’s framework for AI in financial services.
Common questions about SEBI CSCRF
Cybersecurity and Cyber Resilience Framework. SEBI issued it for SEBI-regulated entities by circular dated 20 August 2024.
Yes. It is a SEBI circular that applies to SEBI-regulated entities, with requirements graded by category and compliance assessed through cyber audits.
For most REs, the deadline after two extensions was 31 August 2025. Market infrastructure institutions, KYC registration agencies and Qualified RTAs were excluded from those extensions and held to earlier dates.
All REs needs SOC coverage. MIIs and Qualified REs maintain their own SOC; smaller REs can onboard to the Market SOC run by NSE and BSE or use a group SOC and submit SOC efficacy reports.
The earlier circulars were issued separately for different types of entity. The CSCRF replaces them with one framework, grades requirements by category, and organises them around five resiliency goals and six cybersecurity functions.
Where a platform helps with evidence
The CSCRF’s identity and logging obligations generate a steady demand for evidence: an inventory of identities, proof of access review, and proof of least privilege. Producing that by hand across several cloud accounts, every audit cycle, is slow.
Cy5’s ion platform keeps a live inventory of human and machine identities across AWS, Azure and GCP in its entity graph, with what each can reach. Its CIEM view compares granted with used permissions for every identity, which is the least-privilege evidence an auditor asks for, and its India compliance mapping ties those records to SEBI CSCRF alongside RBI, CERT-In and DPDP requirements. More detail is on the Cy5 India compliance page.
A note on evidence you cannot produce later
This page summarises the SEBI circulars, and the circulars are the authority. Check sebi.gov.in for anything issued after the verification date above.
One limitation is worth planning for now. Logs that were never enabled cannot be produced retrospectively. If an audit or an incident asks which records a particular identity read last quarter, and data access logging was off, there is no way to answer. That is the most expensive thing to discover during an audit, and the cheapest to fix before one. For how the Digital Personal Data Protection Act adds to these obligations, see our note on the DPDP Act’s phased rollout.
