Ransomware at 02:14: Wipe, Notify, or Pay?
Trasker Freight moves 1.4 million consignments a year with 2,600 staff in the Netherlands, Germany, Poland and the UK. On a Tuesday at 02:14 the EDR console raised mass file-encryption alerts; by 06:00, 340 of 410 servers and 1,900 endpoints were encrypted. The ransom note demands payment within 96 hours. Backups are nightly Veeam jobs to a domain-joined NAS, with weekly tapes taken offsite; only the finance database has an immutable cloud copy outside the domain. Retention is 14 days on disk and 8 weeks on tape. The customer portal, which holds consignee names, addresses and phone numbers, is down, and the occupational health share contained employee medical certificates. The incident commander wants to wipe and rebuild the first available servers by 10:00 to get depot scanners working; the DPO has been asked whether the 72-hour clock has started; and the CEO has asked whether paying is faster than restoring. No external counsel has been engaged.
1. The incident commander wants to wipe and rebuild servers at 10:00. Do you agree? Set out what must happen before any rebuild.
Read the worked answer
Do not wipe at 10:00. Rebuilding hours after detection, before scope is known, is how organisations get reinfected twice and lose the evidence that determines notification and liability.
Before any rebuild: isolate by segment at the switch and firewall layer rather than mass powering-off, because shutting down loses volatile memory evidence and can leave files half-encrypted; revoke all privileged and service account credentials and disable the VPN; block known command-and-control at egress while keeping EDR management, logging and backup infrastructure reachable. Capture memory and disk images from at least one representative server and one endpoint, preserve the ransom note and its metadata, and preserve EDR telemetry. Engage external counsel now, both to direct the investigation and to establish privilege over the forensic report.
Separately, treat the backup estate as compromised: the NAS is domain-joined, so assume the attacker had the credentials. Check the catalogue for deleted or altered restore points before relying on it. Meanwhile the depot can run on a controlled manual fallback with paper manifests, which is a business continuity decision and should be made deliberately.
2. The DPO asks whether the 72-hour clock has started and what must be notified. How do you assess it?
Read the worked answer
The clock starts when the organisation becomes aware of a personal data breach with a reasonable degree of certainty, not when the root cause is fully understood. Encryption of the customer portal and the occupational health share is a personal data breach - encrypted data is unavailable and, given attacker access, confidentiality must be presumed affected. The occupational health data includes medical information, which is special category data and raises the likelihood of high risk to individuals, pushing towards notifying affected employees as well as the supervisory authority. Consignee names, addresses and phone numbers are ordinary personal data but at scale.
Under GDPR Article 33 the supervisory authority notification is due within 72 hours of awareness, and it may be made in phases: initial notification with what is known, followed by supplementary information, provided the delay is explained. Under Article 34, affected individuals are told without undue delay where high risk is likely. UK GDPR runs a parallel duty to the ICO for UK data subjects. If the entity is in scope of NIS2 as transposed nationally, expect a 24-hour early warning and a separate 72-hour incident notification. Customer contracts may impose 24- or 48-hour notice, which can be shorter than statute - read them today.
Do not let the 96-hour ransom deadline drive the notification timeline. Document every decision, including anything deferred on law-enforcement advice.
3. Set the restore sequence and the criteria for trusting backups. Advise the CEO on paying.
Read the worked answer
Restore in dependency order into a clean, isolated environment: identity first (rebuild domain controllers rather than restoring potentially backdoored ones, and reset every credential including service accounts and the krbtgt account twice), then network core and egress filtering, then tier-1 dispatch and warehouse management so depots can scan, then customer portal, then email and file services, then endpoints. Rebuild rather than restore any server that was domain-joined and reachable during the intrusion. Keep restored systems off the internet until egress filtering and MFA are back.
Trust criteria for backups: catalogue integrity confirmed, restore tested into isolation, malware-scanned, and offsite tapes verified as outside the blast radius. With 14-day disk retention, an intrusion that started more than two weeks ago means the disk copies may already be poisoned; confirm the earliest clean restore point before promising an RPO. Expect restore times measured in days for 340 servers.
On paying: there is no guarantee of decryption, it funds criminal operations, may raise sanctions issues, and the decryptor frequently fails on large estates. Technical advice to the CEO is restore and rebuild; the decision itself belongs to the board with counsel, recorded with reasons, and should not delay notification or recovery work.