Treasury ransomware continuity: keep critical payments possible when normal systems are unavailable

A ransomware incident can disable ERP, email, shared drives or identity systems at the same time treasury still needs to fund payroll, tax, debt and essential suppliers. This guide explains the mechanics, evidence, risks and controls a UK business should understand before relying on the process.

What this means in practice

A ransomware incident can disable ERP, email, shared drives or identity systems at the same time treasury still needs to fund payroll, tax, debt and essential suppliers. The important issue for a UK business is not the label but the point at which the rule changes cash, authority, timing or exposure.

Continuity planning should define minimum viable treasury operations, trusted payment data, independent bank access, alternative communication and restoration priorities before the incident occurs. Management should separate the contractual or scheme rule from internal policy because a transaction can be externally possible but still outside delegated authority.

How the process works

The operating sequence should start with the trigger, move through validation and approval, and end only when the external result is confirmed. For this topic, the critical mechanics are: Continuity planning should define minimum viable treasury operations, trusted payment data, independent bank access, alternative communication and restoration priorities before the incident occurs.

Planning should work backwards from the required result rather than from the internal submission date. A correct instruction can still fail operationally if the company misses a notice period, scheme window, bank cut-off or response deadline.

The data and evidence that matter

At minimum, retain critical payment calendar, clean beneficiary data, offline or protected procedures, alternate bank contacts, authorised emergency users, backup status and recovery test results. Each material field should have a source and timestamp so a reviewer can distinguish current evidence from an old assumption copied forward.

Timing evidence belongs with the financial data. Cut-offs, value dates, consent windows and report timestamps can decide whether an otherwise correct action works, so the reviewer should see both the amount and the last safe time to intervene.

Where the process can fail

A company can have resilient bank portals but still be unable to pay because all approved beneficiary details and payment-support documents are locked inside compromised systems. The exposure usually becomes more expensive to fix as the company gets closer to payment, settlement, testing or maturity.

Automation changes the shape of the risk rather than removing it. A system can transmit an incorrect instruction quickly and consistently, which makes source validation and independent exception reporting more important as straight-through processing increases.

Worked example: test the mechanics

The ERP and corporate email are unavailable two days before payroll. Treasury can access the bank portal, but it needs a trusted payroll total, validated beneficiary file and authorised approvers. A continuity plan that protects only login credentials is therefore incomplete.

The figures are illustrative, not universal terms. In a live case the company should replace every amount, date and threshold with the current bank, scheme or contractual evidence, then rerun the decision before cash is committed.

Governance and control design

Define and test a minimum viable payment process using protected data, separate communications and ransomware-resistant backups. The control should specify both the primary owner and the independent reviewer so the process does not fail when one experienced person is absent.

A practical dashboard should monitor time to restore minimum viable treasury operations and percentage of critical payment data available through tested recovery paths. Trends in the exception population can reveal a deteriorating process even while most individual transactions still complete successfully.

Training should use the company's own transaction examples. Staff are more likely to follow a control when they understand how one incorrect date, threshold, account or status can create a real cash consequence.

Ownership should also survive absence and staff turnover. The procedure should say who acts, who reviews, where evidence is stored and what happens if the normal owner cannot complete the step. For treasury ransomware continuity, undocumented expert knowledge is itself an operational dependency.

A separate review should test whether time to restore minimum viable treasury operations and percentage of critical payment data available through tested recovery paths is still the right indicator after changes in volume, structure or banking arrangements. If the measure no longer predicts operational risk, management can receive a clean dashboard while the real exposure moves somewhere else.

A good control also reduces unnecessary conservatism. Once critical payment calendar, clean beneficiary data, offline or protected procedures, alternate bank contacts, authorised emergency users, backup status and recovery test results is reliable and current, treasury can distinguish genuine restrictions from assumptions and may be able to release excess buffers, shorten manual review or use available funding more efficiently.