Articles

You have backups – but can your business get back to work after a cyber attack?

Backed-up data alone is not enough: how organisations connect recovery priorities, protected backups and tested procedures to resume operations.

Monday morning, 7.30 am: staff cannot sign in, shared files are unavailable and order processing has stopped. IT is investigating a possible cyber attack. Management asks: “We have backups, don’t we – when can we get back to work?”

This fictional example highlights the gap between two different tasks: backing up data and restoring business operations. A successful backup notification does not tell you how quickly applications, access and working processes will become available again.

Backed-up data does not mean a functioning business

An organisation needs more than individual files. Applications depend on databases, user accounts, networks, certificates and external services, for example. If one of these prerequisites is missing, restored data may initially be unusable.

Every backup approach therefore needs to address this question: What do we need to be able to work with these data again?

Germany’s Federal Office for Information Security (BSI) identifies backups as a key preventive measure for maintaining data availability following ransomware. Recovery needs to be considered from the outset. Source: BSI – Data backup concept and centralised data storage

Two questions management should answer

How long can a business process remain unavailable? And how much recently created data could the business afford to lose?

Order processing may have different limits from an internal archive. The answers determine how often backups are needed and what recovery capabilities must be available.

Management, business departments and IT should agree these objectives together. IT can then assess whether existing resources can meet them. A target recovery time starts as a requirement – practical testing provides evidence that it is achievable.

Which systems need to come back first?

“Everything at once” rarely makes a useful recovery plan. A sequence based on important business processes and their technical dependencies is more helpful.

If an inventory management system requires user management and a database to be restored first, those prerequisites belong in the procedure. External support also needs consideration: who can help at the software supplier, and which credentials and contract details will be required?

A short, agreed list of priorities makes decisions easier under pressure. It should also identify activities that can temporarily continue using alternative procedures.

Backups need protection of their own

A backup is at risk if attackers can use the same compromised credentials to change or delete it as they can to access production data.

Organisations should therefore review how backup systems and administrative access are protected separately. Depending on the environment, suitable measures may include disconnected copies or backup versions with technical protection against subsequent alteration.

Retention periods matter too: if an attack is discovered late, a suitable older version must still be available. Encryption protects a backup’s confidentiality but does not, by itself, prevent deletion.

A recovery test provides the crucial answers

A manageable test can start with one selected application. In a suitable environment separate from production, the team checks whether the necessary data and settings can be restored.

Success means more than finishing the technical procedure without an error message. The responsible business department should confirm that the application works and that the data are sufficiently complete for the intended work.

The test record should include:

  • the time actually required;
  • missing access, information or components;
  • whether the restored data are usable for business purposes;
  • necessary improvements and who is responsible for them.

Following significant changes to applications or infrastructure, review whether the previous test still provides meaningful evidence.

Do not simply restore during a cyber incident

Before recovery, establish which systems and backup versions can be trusted. Otherwise, malware or unauthorised access could remain in place.

Investigation, containment and recovery therefore need to be coordinated. This includes clear decisions about who authorises systems to return to service and which checks must take place first.

Backups also cannot remove every consequence of an attack. Restoring data does not retrieve information that has already been stolen.

Five questions for your next internal review

  1. Do we know which business processes must resume first?
  2. Have we jointly agreed acceptable downtime and data loss?
  3. Are backups adequately protected even if administrator credentials are compromised?
  4. Have we tested recovery of an important application, including its suitability for business use?
  5. Are emergency contacts and recovery instructions available when our usual IT is unavailable?

Being able to answer these questions provides a stronger foundation than a daily green backup status indicator.

SITsolutions helps organisations connect information security and incident preparedness with their business processes. This includes clear priorities, defined responsibilities and recovery procedures that can be tested.

As at 13 October 2026. The opening scenario is fictional. These recommendations provide practical guidance and need to be adapted to the organisation’s IT environment and operational requirements.

← Latest articles