Could your business recover from a ransomware attack?

WebParam perspective | October 2026

A business can have a backup dashboard full of green ticks and still be unable to take an order on Monday morning. The files may be intact, but nobody knows which system to restore first, who holds the credentials, or how to work while the network is offline.

That is the question worth asking during Cybersecurity Awareness Month: if a ransomware attack stopped a critical workflow today, how would the business recover it? Recovery is a business process as much as a technical one. The exercise below gives a leadership team a practical place to start.

Choose one essential service, such as taking orders, paying suppliers or responding to customer enquiries. Trace what it needs to work: people, devices, applications, data, identity and internet connections, external providers, and approvals. Write down which dependency would stop the service if it disappeared.

This exercise often changes the recovery order. Restoring a document folder may be less urgent than restoring the identity system that lets staff sign in. A database may be available, but the team may still need an application, a configuration file and a trusted way to verify that its records are current.

Decide two limits with the business owner. How long can this service be unavailable before the harm becomes unacceptable? How much recent data could be reconstructed if the last usable backup is older than the incident? These answers guide backup frequency and restoration priorities; there is no single schedule that fits every business.

A backup is useful only if it can be found, trusted and restored. The UK National Cyber Security Centre advises organisations to back up the data needed to operate and to know how to restore it. It also cautions that a cloud service's file history or deleted-item recovery should not be the sole plan for critical data. [1]

Ask the owner of each critical system to show:

• What is copied, how often, and where the copy is kept.
• Whether the copy includes the settings, licences and credentials needed to rebuild the service.
• Who can alter or delete the backup, and how that access is protected.
• How the business would reach the backup if its usual accounts or network were unavailable.
• The date and result of the last successful restoration test.

Ransomware operators may try to destroy accessible backups. CISA recommends offline, encrypted copies of critical data and regular tests of backup availability and integrity. A backup product or an “immutable” setting can help, but it still needs the right configuration, access controls and a tested recovery route. [2]

Do not begin by taking a live service offline. In a safe test environment, restore a representative copy of the data and the application or configuration it depends on. Have the person who would respond during an incident perform the steps while another person records the time and obstacles.

Then check more than whether a file opens. Can an authorised user sign in? Are the records complete enough to resume the workflow? Do integrations and permissions work? Can the team identify which transactions arrived after the backup and reconcile them without inventing data?

A useful drill ends with an observed result: what was restored, how long it took, what was missing and who owns each fix. Repeat after meaningful changes to the system, provider or backup process. A written plan that has never been exercised gives little evidence about recovery time.

Write a short response card that staff can reach without the affected network. Name the person who can declare an incident, the technical lead, a business decision-maker, the backup contact and the communications owner. Keep trusted supplier and emergency contact details with the plan.

If ransomware is suspected, staff should report it promptly and avoid improvising a restoration on the potentially compromised network. The response lead should isolate affected systems, establish what is involved, preserve relevant evidence and prioritise critical services before reconnecting or restoring. CISA's response checklist provides a fuller sequence; the exact actions should follow the organisation's incident plan and the advice of qualified responders. [2]

Communications need a route too. Who tells staff which systems to stop using? Who speaks to customers and service providers? Who assesses whether personal information was affected and obtains appropriate legal or regulatory advice? These decisions are harder when every contact list is locked inside the same system.

Recovery may take longer than the technical estimate. Agree in advance on a limited manual process for the selected service: which orders can be accepted, who records them, how approvals are verified and when those records will be entered into restored systems. The workaround must not create a second incident by exposing customer data or bypassing payment controls.

An exercise should test the handover back to normal operations. If staff capture work on paper or in a separate approved tool, who checks duplicates and missing transactions before the main system resumes? That final reconciliation is part of recovery.

At WebParam, we would use the drill to map the workflow, its system dependencies and the people responsible for each decision. The next step might be a better backup configuration, a missing integration, a clearer approval route or a simpler manual fallback. Each should have an owner and a retest date.

A business does not need to predict the exact attack to prepare. It needs to know which service matters most, which copy can restore it and what the team will do when normal tools are unavailable. A successful recovery drill turns “we have backups” into evidence that the business can resume work.

1. UK National Cyber Security Centre, Backing up your data and Back up your organisation's critical data.
2. CISA, #StopRansomware Guide, backup recommendations and response checklist.