Cyber Security and Cyber Resilience Framework (CSCRF) for Stock Brokers and Depository Participants

The CSCRF was introduced by SEBI in its circular dated 30‑January‑2022 to address the rising incidence of cyber‑attacks on market participants. The framework mandates a systematic approach to protect client data, transaction integrity, and the continuity of trading operations.

It applies to two distinct categories: stock brokers who execute client orders on exchanges, and depository participants who maintain electronic records of securities holdings. While both must meet the same high‑level standards, the operational details differ because brokers deal with order flow and front‑office systems, whereas depositories manage custodial databases and settlement interfaces.

For the exam, remember that SEBI expects documented policies, periodic testing, and a clear escalation matrix. Questions frequently ask which entity is responsible for a particular control (e.g., encryption of client data vs. secure API access). Knowing the division of duties helps you eliminate wrong options quickly.

• CSCRF is a risk‑based, not a checklist‑only, approach.
• Compliance is verified through SEBI’s periodic audits and self‑assessment reports.

SEBI’s circular outlines four mandatory elements: (1) Governance, (2) Risk Management, (3) Controls, and (4) Monitoring & Reporting. Each element is supported by detailed guidelines that reference international standards such as ISO/IEC 27001 and NIST.

Governance requires a dedicated Chief Information Security Officer (CISO) or an equivalent senior function with board‑level reporting. For stock brokers, the CISO must be involved in order‑routing decisions; for depositories, the CISO oversees the integrity of the Central Depository System (CDS).

Failure to comply can attract penalties up to 5% of the annual turnover or suspension of the registration certificate. The exam may ask for the maximum monetary penalty – recall the 5% figure and the fact that it is applied on the aggregate turnover of the entity.

The framework breaks down into five inter‑related components: Policy Framework, Asset Identification, Threat & Vulnerability Management, Incident Response, and Continuous Monitoring. Each component has specific deliverables that must be documented and tested annually.

Policy Framework includes the cyber‑security policy, data‑privacy policy, and business‑continuity plan. Asset Identification requires a complete inventory of hardware, software, and network assets, classified by criticality to trading or settlement operations.

Threat & Vulnerability Management mandates regular penetration testing, vulnerability scanning, and a risk‑based remediation schedule. Incident Response defines the steps from detection to recovery, with predefined roles such as Incident Commander and Communication Officer.

Continuous Monitoring involves real‑time security information and event management (SIEM) tools, periodic log reviews, and key performance indicators (KPIs) like mean time to detect (MTTD) and mean time to recover (MTTR).

Step 1 – Establish a cyber‑security governance committee headed by the CISO and include senior members from the trading, compliance and IT teams. The committee must submit a quarterly risk‑assessment report to the board.

Step 2 – Create an inventory of all order‑entry gateways, market data feeds, and client‑facing APIs. Classify each asset as ‘critical’, ‘important’ or ‘supporting’ based on its impact on order execution latency and data confidentiality.

Step 3 – Conduct vulnerability scanning on all critical assets weekly and schedule a full penetration test twice a year. Remediate findings based on the risk‑score (see formula block).

Step 4 – Draft an incident response playbook that outlines detection, containment, eradication, recovery, and post‑incident review. Conduct tabletop exercises before each quarter‑end to ensure readiness.

Step 5 – Deploy a SIEM solution that aggregates logs from order management systems (OMS), execution gateways, and network devices. Set alerts for anomalous trade patterns, unauthorized access attempts, and data exfiltration indicators.

Depositories must first map the entire CDS architecture, including the central ledger, participant interfaces, and backup sites. Each node is assigned a criticality rating because any breach could affect millions of demat accounts.

Next, they perform a risk assessment using the same Likelihood × Impact formula (see formula block) but with higher weightage for data integrity risks. Findings are reported to the Board of Directors of the depository.

Mandatory controls include multi‑factor authentication for all privileged access, encryption of data at rest and in transit, and segregation of duties between database administrators and application developers.

Incident response for depositories emphasizes rapid restoration of the central ledger. A dedicated Recovery Team must be able to bring the CDS online within the SEBI‑prescribed MTTR of 4 hours for critical failures.

Continuous monitoring is achieved through a centralized security operations centre (SOC) that monitors transaction logs, access logs, and system health metrics 24×7. Weekly dashboards are submitted to SEBI’s cyber‑security oversight unit.

The Likelihood × Impact model is the standard risk‑scoring approach endorsed by SEBI in the CSCRF guidelines. A score of 15 or above (out of a maximum of 25) triggers mandatory remedial action within 30 days.

For stock brokers, a high‑impact scenario could be a breach of the order‑entry gateway that leads to market manipulation. For depositories, the same score may result from a data‑corruption incident affecting the central ledger.

Exam questions may present a table of likelihood and impact ratings and ask you to calculate the overall risk score or to identify which asset requires immediate remediation. Remember the simple multiplication and the 15‑point threshold.

The incident response lifecycle consists of five phases: Detection, Containment, Eradication, Recovery, and Post‑Incident Review. Each phase has defined responsibilities and time‑bound targets.

Detection relies on SIEM alerts, intrusion‑detection systems (IDS), and user‑reported anomalies. Once an alert is validated, the Containment team isolates the affected system to prevent lateral movement.

Eradication involves removing malicious code, patching vulnerabilities, and resetting compromised credentials. Recovery restores services to normal operation, verified by integrity checks and functional testing.

The final phase, Post‑Incident Review, documents lessons learned, updates the risk register, and refines the incident playbook. SEBI requires submission of the incident report within 72 hours of detection for high‑severity events.

SEBI expects participants to track quantitative resilience metrics. The two most important are Mean Time to Detect (MTTD) and Mean Time to Recover (MTTR). Lower values indicate a more resilient environment.

MTTD is calculated as the average time between the occurrence of a cyber event and its detection by security tools. MTTR measures the average time taken to restore normal operations after containment.

For the exam, remember the benchmark values suggested by SEBI: MTTD ≤ 30 minutes and MTTR ≤ 4 hours for critical systems. Any deviation must be justified with a remediation plan.