Ransomware: Test backup restoration and business recovery

Start with a business process

Choose a process your organisation would need first after an outage: handling orders, checking appointments or dispatching goods. Define the minimum functions it requires. Restoring a file alone does not establish that employees can perform that work.

The NIST ransomware profile published in June 2026 connects technical protection with responsibilities and recovery planning. A practical starting point is a joint decision by the business owner and IT: which process takes priority, and how will both sides establish that it is usable again? [1]

Set two separate targets

Tolerable downtime determines when the selected process must work again. Tolerable data loss determines how far back in time the recovered data may be. These decisions set the recovery target and backup requirement. Initially they are requirements, rather than measured properties of your systems.

Also record how long a fallback process can remain useful and how much work would need repeating. Assess lost output, manual rework and additional operating effort without counting the same cost twice. Your own business information is more useful here than a general average for cyberattack losses.

Preserve both the backup and access to it

The NCSC warns that attackers can deliberately destroy backups. Neither cloud storage nor a local backup device is automatically protected. Ask about separate access, protected retention periods and copies that remain available. [2]

• Which copy remains usable if normal administration is unavailable?
• Who can delete backups or shorten their retention?
• Can recovery credentials and decryption keys be accessed during an incident?
• Which applications, configurations and licences are also needed?

Restore a complete workflow

Arrange a controlled test with the responsible IT team in a separate environment. Agree the data scope, owners and stopping conditions beforehand. Use suitable test data or protect any necessary real data appropriately. Do not turn live operations into an unplanned experiment.

Measure total downtime from the simulated disruption until the business owner confirms the workflow is usable, and record the technical restore duration separately. This includes detection, decisions and arranging the people and access needed. Test the agreed workflow, including sign-in and required connections. Record the recovered data point and missing changes. NIST recommends testing recovery strategies and verifying backup integrity before restoration. [1]

Turn the result into a decision

A test record should support acceptance or a specific correction. We suggest one row for each process: agreed target, measured time, recovered data point, missing dependencies, responsible person and next test date.

Separate data transfer time from the time needed to make work possible. If missing access stops the test, keep that delay in the measurement. Review the outcome after significant changes to applications, permissions or backup procedures. Keep previous results so that improvements and recurring obstacles can be distinguished.

An active incident needs a different procedure

During an attack, the responsible incident response team coordinates containment and recovery. The NCSC recommends connecting backups only to known clean devices and checking them for malware before restoration. A successful restore does not reverse an earlier data theft. [3]

How an external assessment complements this

Cyberkern Level 1 examines the agreed external attack surface and visible configurations, helping prioritise technical measures for publicly reachable systems. Internal backup usability and operational recovery require separate access and practical tests by the responsible teams. These results answer different questions and can inform the same improvement plan.

Related reading

• External attack surface: inventory your domains and services
• Testing and documenting security controls