Ransomware on a Pay Week: Nine-Day-Old Backups and a CFO Email That Is Not the CFO

The governing principle is that payment continuity and evidence preservation are separate workstreams that must not be allowed to compromise each other.

Hours 0–4: contain and separate. Declare a major incident, invoke the BCP formally so the clock and decision log start, and isolate affected systems without wiping them - a forensic image is taken before anything is rebuilt, because destroying logs destroys both the investigation and any insurance or regulatory position. In parallel, stand up the payment workstream with its own lead.

Hours 0–4 second track: decide what data is trustworthy. This is the hardest judgement. A nine-day-old backup is not a payroll input. Reconstruct from the most recent verified payroll register plus a manually validated exception list - starters, leavers, rate changes, absence - with each country confirming its own list in writing. Paying from unvalidated inputs is worse than paying late.

Hours 4–12: secure the payment authority. The single approver on a plane is itself a control failure. Activate a named alternate under a pre-agreed delegation, with dual control and a callback to a number on file. Do not route around the approval; add approvers by authority, not by convenience.

Hours 12–24: communicate and assess notification duties. Notify affected employees and managers with a script and a holding timeline; check statutory notice or late-payment consequences country by country. Payroll data is personal data, so legal must assess breach notification obligations and their deadlines immediately, not after the investigation.

Hours 24–48: stabilise. Bring up the DR environment explicitly as a degraded service, communicate known gaps, and set a decision point for the third country's Monday pay run. Then begin the reconciliation that proves what was actually paid.

Refuse to execute, and treat the email as a security incident in its own right.

The indicators stack up: an out-of-band instruction from a senior executive, manufactured urgency imposed on a team already in crisis, a change of payee to a newly onboarded wallet provider, a file that alters 40 employees' bank details at once, and timing during an outage when the normal verification control is by definition degraded. That is the classic business email compromise pattern, and the fact that the sender name is right proves nothing.

Verification must be through an independent channel: a callback to a number held on file or in the corporate directory, never a reply to the email and never a number supplied in the email. Secondary confirmation from a second executive in the group, through the same independent route, should corroborate the 'banking migration' story - a genuine migration would have a project record, a change ticket, and a communication trail.

Even if the request turned out to be genuine, executing it is the wrong decision today. The verification control is single-email confirmation, which is exactly the control an attacker defeats. A brief delay to 40 salaries is recoverable and can be communicated; paying 40 salaries into a wallet controlled by a fraudster is usually unrecoverable and creates a data breach as well.

So: do not action, preserve the email as evidence, notify information security and the bank, check whether other approvers or payroll staff received similar messages, and escalate to the CFO through the known number. Document the refusal and the escalation path taken - the audit trail of a refused fraudulent payment is as important as one of a detected error.

Split remediation into what protects the next pay run and what satisfies the auditor; they overlap but are not the same.

BCP. Define recovery objectives per process rather than one enterprise number: payroll calculation and payment might carry a 48-hour RTO with a 24-hour RPO for input data, while reporting can wait. Test annually, end to end, including the bank file and an unavailable approver - an untested plan is a document, which is why the 2022 test date is the auditor's central finding. Move to immutable or offline backups with a shorter interval, and write a manual payroll procedure with a printed or offline fallback data set so the process does not depend on the encrypted estate.

Controls. Bank-detail changes require two-channel verification with a mandatory cooling period before the next payment cycle, and segregation between master-data maintenance and payment release. Named alternate approvers, pre-authorised, with a documented delegation matrix. A payment file cannot be released by one person under any circumstances, including crisis.

Audit response. A remedial action plan with a named owner, a date and evidence of completion for each finding, internal audit validation before closure, and reporting to the audit committee - not a narrative explanation. The prior two reports said the same thing, so the credible message is that the issue is now closed with evidence, not that it is being looked at again.

Finally, add the scenario to the risk register with a quantified impact, because the ransomware event is a foreseeable risk that materialised, not a black swan.