Ransomware, a 48-Hour Leak Threat, and Three Regulatory Clocks
A software-as-a-service provider with 900 enterprise customers suffers a ransomware intrusion. Backups restore about 70% of workloads; the remaining 30% sat on a network appliance that was encrypted along with production. The attacker has exfiltrated roughly 4 TB including HR records and customer configuration data, and threatens publication in 48 hours unless paid 90 BTC. The service has been down for nine hours; contractual SLA credits begin accruing at 24 hours. The company is listed in the US via ADR and has EU customers, so counsel has flagged a 72-hour GDPR notification and a four-business-day US material-incident disclosure once materiality is determined. The attacker has provided a working sample of the stolen data. The internal crisis team is split: the CTO wants to negotiate to buy time and possibly recover the encrypted appliance; the general counsel wants to notify regulators immediately; commercial leads want customer notification held until restoration is complete.
1. Should the company pay or negotiate, and how should that decision be made and recorded?
Read the worked answer
Recommendation: do not pay, and do not negotiate a payment. Engage the attacker only through counsel and incident responders for the narrow purpose of establishing proof of data deletion capability, and treat any engagement as evidence-generating rather than trust-building.
Reasoning:
- Payment does not buy the outcome being purchased. The data is already exfiltrated and a sample is in hand; payment buys a promise, and the track record of promises is poor. The 30% of workloads on the encrypted appliance is a recovery problem, not a negotiation problem.
- Legal exposure is asymmetric. Payment can trigger sanctions exposure depending on the actor's location, and it creates a disclosure question of its own that will be asked later by regulators and the board. The cost of a payment made under pressure exceeds the cost of an honest statement that we did not pay.
- The decision must be documented contemporaneously, because it will be reviewed after the fact: the options considered, the harm model for each, who decided, and the information available at the time. Record that the decision was made with counsel and, where possible, law enforcement input.
Process: one named decision-maker (CEO) with a written decision memo at the time, not reconstructed later. Revisit only if new facts materially change the harm calculus, such as evidence of imminent harm to individuals from the data. The CTO's desire to buy time is legitimate; buy it through technical containment and a realistic recovery sequence, not through the attacker.
2. Sequence the notifications. What goes to whom, in what order, and how do you handle the fact that facts are still moving?
Read the worked answer
Three clocks are running and they are not the same clock. The sequencing has to satisfy the earliest legal deadline without locking the company into a narrative it will have to retract.
Hour by hour:
- Counsel and forensics first, to establish the materiality determination on a documented basis. The four-business-day clock runs from that determination, not from discovery, so the determination itself must be minuted with its reasoning.
- GDPR notification within 72 hours, in phases. The regulation anticipates incomplete information: notify with what is known, state what is not yet known, and commit to a supplementary notification. Waiting for a complete picture is the common and expensive error.
- Law enforcement engagement in parallel, which in many jurisdictions can support a delay in broader notification - but only where counsel confirms the legal basis, and the delay decision must be recorded.
- Customers, and here the commercial team's instinct is wrong. Customers are experiencing the outage already; they will learn the data dimension from the attacker's leak site if not from us. Notify affected customers with facts, the data categories involved, and the support offered, in tranches by exposure rather than all at once. Enterprise customers will forgive an outage faster than they will forgive being surprised.
- Board and insurers at each material step, not as an afterthought.
- Public statement and, if required, the securities disclosure, coordinated so that customers and investors are not reading contradictory accounts.
Handling moving facts: use a fixed structure - what we know, what we do not know, what we are doing, when we will next update - and never speculate on attribution or on the number of affected records until it is confirmed. Give a specific next-update time and meet it, even if the update is that nothing has changed.
3. How do you prioritise restoration across the 70% restorable and 30% unrestorable estate, and what do you tell customers about timing?
Read the worked answer
Prioritise by dependency order and contractual harm, not by who shouts loudest - and rebuild the 30% rather than restoring it.
Sequence:
- Identity and access management first. Restoring applications before identity produces a second outage and, worse, a second exposure. Verify integrity of identity data before anything else connects.
- Then by customer harm, ranked on two axes: revenue at risk through SLA credits, and operational criticality to the customer (a payments customer down for a day is not the same as an analytics customer). Segment the 900 customers into three tiers and publish the sequence internally so that commercial pressure does not reorder it by volume of complaint.
- Rebuild the 30% clean rather than recover it. The appliance was encrypted; restoring from an untrusted source risks reintroducing the intrusion. Rebuild from known-good configuration, which means accepting a longer time to full service for those workloads and saying so early.
- Verify before restore. Integrity checks and a clean-room validation on a sample before each tranche goes live; the credibility cost of a second incident exceeds the cost of a slower restoration.
What to tell customers about timing: give tranche-based commitments with a stated confidence level and a named contact, not a single headline date. Publishing a date and missing it costs more trust than publishing a sequence and hitting it. State explicitly which workloads are in the rebuild track and that they will take longer, and offer the workaround where one exists.
Measure the response on two things: time to restore tier-one customers, and the number of customers who learn something material from a third party. The second is the one the board will remember.