Ransomware Attack on a Claims Platform Before a Catastrophe

Start by separating two questions that are being conflated: can we restore service, and is paying lawful and prudent?

The CEO is treating payment as the fastest route to protecting the flood response. That may be wrong on the facts, and the framework should test it first.

1. Does payment actually restore service? Ransomware actors frequently fail to deliver working decryption keys, and decryption at scale on a claims platform is slow and error-prone. Nine-day-old backups mean at most nine days of claims data is at risk; the restore is untested, which is the real problem. A parallel track - rebuilding from backup while negotiating - preserves the option and usually delivers service sooner than a decryption exercise. The CRO should insist that the restore is attempted in parallel before any payment is authorised.

2. Is payment lawful? Sanctions screening of the wallet is not an optional step. If the wallet or the group behind it is designated, payment is a criminal act regardless of commercial urgency, and the firm's directors are exposed personally as well as corporately. This must be completed and documented before any transfer, and legal advice obtained in writing.

3. Does payment increase future risk? Paying funds criminal infrastructure, may breach the firm's own conduct commitments, and marks the firm as a payer. It also does not remove the obligation to notify, remediate and report - the firm pays and still carries the regulatory consequences.

4. What does insurance actually cover? The insurer's position is unclear and unwritten. Do not assume recovery. Assume the ₹1 crore retention and no indemnity, and check whether the policy requires prior consent before payment - most do, and paying without consent can void cover.

5. What is the cost of the alternatives? Manual claims handling, extended loss adjustment, regulator tolerance, and reputational damage. Quantify them. The comparison is not ₹4 crore against zero.

Conclusion to put to the CEO: do not authorise payment in 24 hours. Authorise the parallel restore, complete sanctions screening, get the insurer's coverage position in writing, and set a 72-hour review point. The flood timetable argues for speed on restoration, not speed on ransom.

Materiality is a judgement about effect, not about confirmed facts. The firm cannot wait for forensic certainty; the clock runs from determination. The CRO should apply a set of tests and record the reasoning:

• Service effect: can claims be paid? For how long? 12,000 claims and a forecast flood is a service disruption with customer harm, which is material on its own.
• Data effect: personal data on claimants is almost certainly in the encrypted estate. Assume compromise until proven otherwise; the notification obligation may run on a lower threshold than the operational one.
• Financial effect: cost of restoration, business interruption, potential regulatory penalty, and the possibility that the incident affects the solvency position.
• Systemic or third-party effect: does the firm provide services to others, or rely on a shared provider affected by the same attack?

The determination should be documented with time stamps, because the six-hour clock will be examined afterwards.

Notification content. What is known, what is not known, the containment steps taken, the customer impact, the named accountable executive, and the next update time. Do not speculate about cause or attribute blame, and do not disclose ransom negotiation detail unless required. Commit to a further update rather than waiting for a complete picture.

Board communication. The Board needs four things: the operational position and expected restoration date; the legal and regulatory exposure, including sanctions risk if payment is contemplated; the financial range, with and without insurance recovery; and the decisions required of them. Boards handle uncertainty badly when they are given reassurance instead of ranges. Give them the range.

One point of discipline. The CEO's instinct to protect the flood response is right, but the way to protect it is to stand up a manual claims process and communicate to policyholders early, not to keep the incident quiet while a payment is negotiated. A late notification discovered later is a worse outcome than an early one that turns out to have been precautionary.

What the incident actually reveals. The precipitating event was ransomware, but the failures were mundane: backups nine days old, restore untested at scale, no pre-agreed sanctions screening procedure, an insurance position that was ambiguous when it mattered, and an escalation route that put a commercial decision in front of the CEO before the legal question had been answered. The register should record these as the risks, not just 'cyber attack'.

Risk register changes.

• Split the single cyber line into distinct risks: data confidentiality, service availability, third-party dependency, and payment-related legal risk. They have different owners and different controls.
• Add a concentration entry: how many critical processes depend on one platform, and what is the manual fallback?
• Add an emerging entry for extortion economics, owned by the CRO, reviewed quarterly.
• Re-rate likelihood and impact using this event as evidence. A nine-day backup gap is an observed control failure, not a hypothetical.

Capital assessment. Operational risk capital should be re-estimated with this as a scenario: direct response cost, business interruption, customer redress, regulatory penalty, and the cash-flow timing of the insurance recovery. The more important change may be to the liquidity assessment - a ₹4 crore demand in cryptocurrency within 48 hours is a liquidity event, and the firm's liquidity plan probably did not contemplate it. Test the plan against a simultaneous catastrophe, because that is exactly what nearly happened.

Controls.

1. Restore testing at full scale on a fixed cycle, reported to the Board, not to IT.
2. A written ransom decision protocol: sanctions screening, legal sign-off, insurer consent, CEO and Board Chair authorisation, all pre-agreed.
3. Insurance wording clarified - confirm the ransom exclusion and the prior-consent condition in writing.
4. A tested manual claims fallback, exercised annually.
5. Notification determination delegated to a named executive with a documented test, so the six-hour clock is not dependent on a meeting being convened.

The honest conclusion for the Board: the firm was lucky on timing. Had the flood landed during the outage, the operational loss would have been several times the ransom demand, and no payment would have changed that.