Ransomware Attack on Settlement Day: Reporting, Pay-In and Governance
At 01:40 on Wednesday, Sundaram Broking's primary settlement server is encrypted by ransomware. It hosts the clearing application that maps client positions to the clearing corporation's obligation (OB) files. The OB files for 1,850 client codes - net funds pay-in of ₹38.60 crore and 2.40 lakh shares - were downloaded at 23:00 on Tuesday but had not been processed when the attack hit. Pay-in closes at 11:00.
The disaster-recovery site was last synchronised 36 hours ago. The IT head wants to restore from a tape backup; the compliance officer wants to wait for the exchange to "clarify the situation" before doing anything. A client's funds statement is stuck, and two employees have already posted about the outage on social media.
Sundaram is a SEBI-registered stock broker and a clearing member.
1. Set out the first six hours: what must be done, in what order, and what must be reported to whom.
Read the worked answer
Run parallel tracks with named owners, because the 11:00 deadline does not move while the investigation proceeds.
Track 1 - contain and report (owner: CISO/compliance). Isolate the affected server and network segment without destroying evidence, preserve logs and disk images, and report the cyber incident to the exchanges and SEBI within the six-hour window required under SEBI's cybersecurity and cyber-resilience framework. Notify the clearing corporation immediately so that alternative pay-in arrangements and manual obligation reports can be arranged.
Track 2 - reconstruct the obligation (owner: operations head). Re-download the OB and position files from the clearing corporation's secured portal on a clean machine, or obtain them through the CC's backup channel, and reconcile the net funds and securities figures with the CC over a recorded line before initiating payment.
Track 3 - pay-in (owner: treasury). Complete the ₹38.60 crore funds pay-in and the 2.40 lakh share delivery through an alternate, uncompromised channel - the DR site, a standby application, or manual files verified by two officers. Do not wait for the exchange to respond before starting this.
Track 4 - communication (owner: compliance). Issue a factual holding statement to clients through registered channels, tell staff to stop posting, and log every client query. The compliance officer's instinct to wait is the single most damaging response available.
2. Is the ransomware attack a valid defence against a pay-in failure? Who bears the close-out and the penalties?
Read the worked answer
No, it is not a defence towards the clearing corporation. A member's obligation to pay in by the deadline is strict. The by-laws and the risk-management framework do not carve out an exception for an attack on the member's own infrastructure; the counterparty that is expecting delivery should not bear the consequence of another member's systems failure. Unless the clearing corporation itself declares a market-wide disruption and reschedules settlement, the deadline stands.
If Sundaram fails to deliver, the shortfall will be closed out at the highest price of the scrip on the day, with the difference and default charges debited to the member, plus any penalty for the funds shortfall. Those amounts are the broker's loss, not the clients'.
Two follow-ons matter. First, the broker should check whether its cyber-insurance policy responds to business interruption and to the cost of restoring systems and meeting client claims - insurance can reimburse, but it does not defer the obligation. Second, failure to report the incident within the prescribed six hours, or an inability to demonstrate an adequate business-continuity plan, is a separate regulatory breach actionable under SEBI's cybersecurity framework, independent of the settlement outcome. Clients whose positions were affected must be told what happened and what was done.
3. Which governance weaknesses does this incident expose, and what should the Board ask for?
Read the worked answer
Weaknesses visible on the facts: (i) a DR site synchronised 36 hours ago is not a DR site for a settlement-critical system - a 36-hour recovery point may mean reconstructing the entire obligation manually; (ii) no tested incident-response plan, since the compliance officer's first thought was to wait; (iii) no social-media or external-communication protocol, allowing employees to disclose the incident; (iv) apparent single-server dependency for a regulated clearing function; and (v) no clear decision rights over the pay-in, which delayed action.
What the Board should demand: a forensic auditor's report with a dated timeline, root cause and confirmation of whether client data or funds were exfiltrated; a client-impact assessment and a remediation plan with owners and dates; a re-test of the DR with a recovery-point objective close to zero for settlement data and a documented DR drill calendar; an incident-response playbook with pre-agreed reporting templates and a named crisis team; a review of privileged access and patch management on the compromised server; a fresh CSCRF self-assessment; confirmation of cyber-insurance adequacy and coverage of third-party claims; and a standing quarterly reporting line to the audit committee on cyber incidents and near-misses.