Trent Logistics: ransomware three days before a payment run

1. Contain, do not clean. Isolate affected servers and the finance network segment from the rest of the estate, disable the contractor's remote account, force credential resets and preserve logs and disk images before anything is rebuilt. Reasoning: the priority is stopping spread, and destroying evidence forecloses both recovery and any insurance or legal process.

2. Notify the bank and payment counterparties immediately - before planning the payment run. Reasoning: ransomware is frequently followed by fraudulent payment instructions or altered supplier bank details. A £6.2m run executed while controls are degraded is the largest single financial exposure here, larger than the ransom. Ask the bank to watch for unusual instructions and to hold changes to beneficiary details pending call-back.

3. Establish whether backups are recoverable. Attempt a restore into a clean, isolated environment. The tapes are in the same room as the servers, so physical loss is a live possibility, and a 14-month-old test proves nothing.

4. Run the payment run on a manually controlled basis. Use stand-alone devices off the compromised network, dual authorisation by two people who did not prepare the file, call-back verification to suppliers and a clean copy of the supplier master reconstructed from purchase ledger and bank statements. If the file cannot be verified, delay a defined set of payments and tell affected suppliers why - a day's delay is cheaper than a fraudulent payment.

5. Escalate formally. Insurer and incident-response specialists engaged, law enforcement notified, and the regulator notified within 72 hours if personal data is likely to have been compromised. Single point of contact, one message, no speculation to staff or customers.

6. Convene the board. Log every decision with time, owner and rationale - the audit committee will need it.

Recommendation: do not pay.

The reasoning against

• It does not solve the problem. Payment buys a decryption key that may not work, may be incomplete, or may be accompanied by a second extortion. The actual constraint on Tuesday is trustworthy payment data and clean infrastructure, and neither is reliably restored by paying.
• It funds and incentivises crime, and creates sanctions and AML exposure. Wallets must be screened, and paying a sanctioned entity is a legal problem, not a commercial one. Insurers may decline to cover a ransom payment.
• It marks Trent as a payer. Repeat targeting of a £340m haulier with weak controls is a realistic consequence.
• The workaround exists. Payments can be reconstructed and run under manual control with call-backs. Payroll can be run from a clean environment. The ransom deadline is artificial; the board's deadline is real and can be met another way.

What the board should do instead

1. Authorise spend on incident response and recovery, not extortion - the same £900k buys far more durable protection.
2. Record the decision and its rationale formally. If the board overrides this advice, require insurer and legal sign-off, sanctions screening of the wallet, and full documentation.
3. Communicate to staff and key customers with facts, not assurances.

What the CEO is really asking is 'will we pay suppliers on Tuesday?' Answer that question directly and separately from the ransom question - conflating them is what pushes boards into paying.

Finance's role: not just funding IT

Finance owns the payment process, so it owns the control that the attackers were targeting. It should also quantify the risk in business language - maximum tolerable downtime, financial impact per day of a closed payment function, the £6.2m and £1.4m exposures, insurance cover versus gap - and include cyber in the internal control statement and going-concern assessment. The board should see cyber as an operational risk with a number attached, not a technology topic.

Fund first, in order

1. Backups on a 3-2-1 basis with at least one offline or immutable copy, and a tested restore each quarter with a documented recovery time objective. The cheapest control here and the one that decides whether an incident is survivable.
2. Multi-factor authentication on remote access, elimination of shared administrator accounts, privileged access management and a joiner-mover-leaver process that closes contractor accounts on the day. The contractor's live account and the shared login were the likely doors.
3. Payment controls independent of IT: mandatory call-back to a known number for any change of bank details, dual authorisation, and reconciliation of the payment file to the approved list before release.
4. Network segmentation so that the finance shared drive is not reachable from an ordinary desktop.
5. Detection and response: endpoint detection, email filtering, a retained incident-response firm and an annual board-level tabletop exercise testing exactly this scenario.

Cheapest of all: stop the next incident happening the same way. The shared login and the stale contractor account cost nothing to fix and were worth more than the ransom.