Under SEBI's Cyber Security and Cyber Resilience Framework (CSCRF), detection is a function in its own right, and it rests on two things: comprehensive logging and a Security Operations Centre (SOC) watching those logs. For many regulated entities this is the most operationally demanding part of the framework, because it is not a document you write once but a capability you have to run continuously and evidence on demand. This guide explains what CSCRF expects for logging and SOC coverage, how those expectations scale with your entity category, and the Market SOC option that lets smaller entities meet them without building a 24x7 operation from scratch.
Why logging and a SOC sit at the centre of CSCRF
CSCRF is built around six functions (govern, identify, protect, detect, respond and recover), and detection is the hinge between prevention and response. You cannot respond to, report on, or recover from an incident you never saw. That is why CSCRF is prescriptive about capturing the right logs, retaining them, and having a SOC that turns raw events into detected incidents. It is also why logging and SOC gaps are among the most common findings at audit time.
SEBI CSCRF logging requirements
The logging expectation is about coverage, integrity and retention, not just switching logs on. In practice, a CSCRF-aligned logging solution covers:
- Comprehensive sources: authentication and access, critical applications and databases, network and security devices, cloud services and administrative activity.
- Centralised collection: logs aggregated into a central store (typically feeding a SIEM) rather than scattered on individual systems.
- Integrity and tamper-evidence: logs protected from alteration, so they stand up as evidence.
- Time synchronisation: a common, accurate clock across systems so events can be correlated.
- Retention: logs kept for the period SEBI specifies for your category, both readily searchable and in longer-term archive.
SEBI CSCRF SOC requirements
Logging without someone watching is just storage. CSCRF expects a SOC capability that monitors, detects and triages, with the depth scaling to your category. A CSCRF-aligned SOC provides:
- Monitoring coverage appropriate to your category, up to 24x7 for larger and more critical entities.
- A SIEM or equivalent that correlates events across sources into meaningful alerts.
- Defined detection use-cases and alert thresholds, tuned to reduce noise.
- A triage and escalation process that turns alerts into tracked incidents.
- Evidence of it working: alert records, triage notes and escalation trails an auditor can inspect.
Market SOC (M-SOC): the shared option for smaller entities
Not every regulated entity can justify a full in-house SOC, and CSCRF does not assume they can. SEBI's framework provides for a Market SOC (M-SOC): a shared security operations facility, offered through market infrastructure institutions, that smaller entities can subscribe to instead of building their own. For a small or mid-size RE, subscribing to an M-SOC is often the practical route to meeting the detection obligation. This is exactly what people are looking for when they search for CSCRF-compliant SOC services: you have options beyond a costly build.
| Option | Best suited to | What to weigh |
|---|---|---|
| In-house SOC | Larger entities and MIIs with scale and budget | Full control, but 24x7 staffing, tooling and tuning are significant ongoing costs |
| Market SOC (M-SOC) | Smaller and mid-size REs | A CSCRF-oriented shared facility via market infrastructure; confirm scope and your own responsibilities |
| Managed SOC (MSSP) | Entities wanting outside expertise without building | Faster to stand up; you remain accountable, so oversight and evidence still sit with you |
Log sources
Apps, access, network, cloud
Central store
Aggregated & tamper-evident
SIEM
Correlate into alerts
SOC triage
Alert to incident
Escalate
Respond & report
How logging and SOC connect to VAPT and reporting
Detection does not stand alone. Vulnerability Assessment and Penetration Testing (VAPT) validates that your controls and detection actually catch what they should, while your incident-reporting obligations depend on the SOC spotting an incident in time to report it to SEBI and CERT-In within their timelines. A weak detection layer quietly undermines both: you cannot test what you cannot see, and you cannot report what you never detected.
Common logging and SOC gaps at audit time
- Logs retained for less than the required period, or archived in a form that cannot be searched.
- Coverage holes: a critical application or cloud service that never sends logs to the central store.
- Alerts generated but no evidence of triage, so there is no proof anyone acted on them.
- A SOC in name only: tooling in place but no tuned use-cases, so real incidents are lost in noise.
- No time synchronisation, making cross-system correlation unreliable.
Putting it together
For CSCRF, logging and a SOC are where the framework becomes an operational reality rather than a policy. Capture the right logs, keep them for the required period with their integrity intact, watch them with a SOC sized to your category (your own, a Market SOC, or a managed provider), and keep evidence that the whole pipeline works. Get detection right and response, recovery and reporting all become achievable, because they finally have something to act on.
Frequently asked questions
Does SEBI CSCRF require a SOC?+
CSCRF expects security-operations coverage appropriate to your entity category, up to 24x7 monitoring for larger and more critical entities. It does not force every entity to build its own SOC: smaller entities can subscribe to a Market SOC (M-SOC) or use a managed provider, but the monitoring capability itself is expected.
What is a Market SOC (M-SOC) under SEBI CSCRF?+
A Market SOC is a shared security operations facility offered through market infrastructure institutions that smaller regulated entities can subscribe to instead of building their own SOC. It is SEBI's way of making the detection obligation achievable for entities without the scale to run 24x7 operations in-house.
What are the logging requirements under SEBI CSCRF?+
CSCRF expects comprehensive log coverage across critical systems, access, network, security devices and cloud; centralised collection into a store or SIEM; tamper-evidence and time synchronisation; and retention for the period SEBI specifies. Confirm the exact fields and retention duration for your category against the current circular.
How long must logs be retained under SEBI CSCRF?+
SEBI specifies retention periods for CSCRF, typically with a readily searchable window plus longer-term archive, and the exact duration depends on your category and the current circular. Design your logging solution to keep logs both searchable and archived for at least the period that applies to you, and confirm the specific number.
Can a smaller entity use a shared SOC for CSCRF?+
Yes. A smaller or mid-size regulated entity can meet the SOC expectation through a Market SOC (M-SOC) or a managed security service provider rather than building its own. You remain accountable for the outcome, so keep oversight and evidence of the monitoring even when the operation is outsourced.
About the author
Nilesh Wagh
Co-Founder, Pelta Technologies
Former CISO · 10+ years in information security & GRC
Nilesh Wagh is Co-Founder of Pelta Technologies, where he leads its information security, privacy, AI governance and GRC advisory. With over a decade in cyber and information security (including years as a Chief Information Security Officer) he helps regulated organisations move from fragmented compliance to connected, evidence-driven assurance.
Connect on LinkedIn →