Ransomware at a EU Subsidiary: Containment, Notification, and the Demand

Sequence

1. Preserve and scope before you clean. Isolate affected segments, disable the VPN appliance, revoke credentials, but image affected servers and capture volatile memory before reimaging anything. The instinct to 'rebuild fast' destroys the evidence that determines whether the exfiltration claim is true - and that claim drives every notification decision that follows.
2. Verify the recovery lifeline before you promise anything. The immutable cloud copies are the company's only credible path back. Confirm the credentials and keys to that environment were not resident on compromised infrastructure, and run a restore of one non-critical server to prove it works. A 14-month-old restore test means restore capability is assumed, not known. Do not announce a recovery timeline until step 2 succeeds.
3. Sequence restoration by business impact, not by server criticality lists. Three plants are down; perishable or safety-critical lines and order-to-cash come first. The business, not IT, should set that order, and someone must own the customer commitments being broken in the meantime.
4. Run forensics in parallel, not afterwards. Patient zero, dwell time (five months), and lateral movement determine whether other subsidiaries are already compromised. The parent network should be treated as suspect until proven otherwise - the subsidiary may be the first victim, not the only one.
5. Engage the cyber insurer and outside counsel early. Counsel directs the investigation to protect privilege over the forensic report; the insurer's panel may constrain who does the work. Both take time to mobilise.

The action I would delay: reinstalling or reimaging to 'get back up' on day one. Speed of restoration is real business value, but reimaging before imaging converts an insurable, notifiable, defensible incident into an unexplained one.

Second delay worth naming: do not issue any customer or employee statement until the exfiltration is verified or the notification deadline compels it. Premature reassurance is the mistake that turns a breach into a credibility problem.

The statement would be unsupported. The actors claim 300 GB left the network. That is a claim, not a finding, but its absence of verification is not the same as disproof - and the company currently cannot tell the difference because EDR was unmonitored and logs may be incomplete. The honest position is 'under investigation,' not 'nothing taken.'

Facts that drive the decision

• What data, verified. HR records of EU employees are personal data; customer contact lists are personal data of individuals in whatever jurisdictions they reside; contract pricing is confidential commercial information, not personal data, but breach of the confidentiality clause is a separate contractual problem.
• Who is affected and where. EU employees trigger GDPR; the US parent's customers in California trigger state breach law; other states may follow. Each regime has its own trigger, its own content requirements, and its own clock - a single generic notice will not satisfy all of them.
• Whether risk is 'likely' or 'high.' GDPR requires supervisory-authority notification within 72 hours of awareness unless the breach is unlikely to result in a risk to rights and freedoms; individual notification follows where risk is high. Awareness arguably began at 2:14 a.m. Saturday - the clock is not waiting for the forensic report to be finished.
• Contractual notice. Customer contracts include confidentiality clauses; those clauses usually carry notice obligations with their own (often shorter) timelines and may require notice regardless of legal threshold.
• SEC. If the incident is material, disclosure obligations attach on the parent's own timeline after a materiality determination. Materiality here includes three halted plants, not just the data.

First 72 hours, concretely

• Stand up a decision log: who decided what, when, on what information. It is the single most useful artefact after the fact.
• Brief counsel; direct the forensic firm's scope to answer three questions - was data exfiltrated, what categories, whose.
• Notify the lead supervisory authority within 72 hours with what is known and what is not; a phased notification is acceptable, silence is not.
• Notify the cyber insurer; notify law enforcement.
• Prepare internal holding statements and a single spokesperson; instruct staff not to speculate.
• Do not notify all customers with a technical narrative - notify those with a contractual right first, with facts and a contact.

Judgement point: the pressure to say nothing until the picture is complete is understandable and wrong where a statutory clock is running. Notify with stated uncertainty; update as facts firm up.

The decision belongs to the board and CEO with counsel's advice - not to IT, and not to the incident commander under a countdown. The 72-hour clock is a pressure tactic; recovery should be planned against the immutable backups, and the ransom decision made on its own merits.

What should determine the answer

1. Can the company recover without paying, and how fast? This is the dominant factor and it is currently unknown because restore has not been tested in 14 months. Run the restore test first; it may make the question moot, or it may reveal that the ransom is the only path. Deciding before knowing is guessing.
2. Sanctions exposure. Paying a sanctioned actor can be a legal violation regardless of intent; the wallet and actor must be screened. This is a legal determination, not a commercial one.
3. Whether payment changes anything. Decryptors from criminal actors are frequently slow or defective, and payment does not reliably prevent publication of the exfiltrated data. The company may pay and still face disclosure - which removes most of the rationale.
4. Insurance coverage and policy conditions. Some policies cover ransom, some require prior approval, and unauthorised payment can void coverage.
5. Downstream effects. Payment funds criminal operations and, for a regulated or public company, may be disclosable.

What to document regardless of outcome

• The decision, the decision-maker, the date and time, and the information available at that moment.
• The recovery timeline that was achievable without payment, with evidence from the restore test.
• The sanctions screening result.
• Counsel's advice and the insurer's position.
• If payment is made, the sanctions diligence, the payment trail, and law enforcement engagement.

My recommendation in this fact pattern: test the immutable restore immediately and treat it as the primary recovery path. The existence of an untested but immutable copy is the strongest argument against paying, and if it works, the ransom demand becomes a data-disclosure problem rather than a recovery problem - which is a better problem, because it is managed with notification and legal process rather than with bitcoin.