Backups Are Hope. Restore Tests Are Resilience.

Many organizations have backups. What matters is whether critical systems can be restored reliably and demonstrably when an incident happens.

Dark technical diagram showing a tested restore path from backup storage to recovered business systems.

Executive Summary

Many organizations have backups. Far fewer can prove, under pressure, that those backups can be restored quickly, completely, and cleanly. In a ransomware incident, this is often the difference between a security event and a longer business outage.

The Sophos Ransomware Report Germany 2026 shows that 61% of affected German organizations restored encrypted data using backups. At the same time, the average recovery cost after a ransomware attack was USD 1.42 million. The gap between ‘backup exists’ and ‘restore works’ is therefore not a technical detail, but a business risk.

For Endline, this is a core element of cyber resilience: resilience instead of hope, evidence instead of screenshots.

What Happened?

Ransomware attacks remain a relevant risk for German organizations. According to Sophos, 45% of the ransomware attacks examined in Germany resulted in data encryption. In 24% of the cases involving encrypted data, data was also stolen. Phishing, compromised credentials, and malicious emails were among the key technical root causes.

Backups play a central role in recovery: according to Sophos, 97% of German organizations whose data was encrypted were able to recover their data; 61% used backups to do so. The report explicitly recommends strengthening backup and recovery infrastructure, testing backups regularly, storing them offline or immutably, and integrating them into a documented incident response plan.

The HDI Cyber Study 2026 also describes cyberattacks as an ongoing business challenge for small and mid-sized organizations. 60% of respondents classify cyber damage as a relevant risk; one in three organizations even sees its own existence threatened in the event of a major cyber incident.

Why This Matters for Organizations

A backup is only a real security anchor if it answers three questions during an incident:

  1. Can the data be restored at all?
  2. How long does it take to restore critical systems?
  3. Is there auditable evidence that restore processes are tested regularly?

Especially in small and mid-sized organizations, the problem is often not that no backup exists. The problem is uncertainty: unclear responsibilities, undocumented recovery paths, missing tests, insufficiently protected backup accounts, or backups that can be encrypted or deleted in the same attack.

That turns backup management into a management topic. Leadership and IT do not need to know every technical setting, but they do need a clear operational picture: which systems are critical, which recovery times apply, when the last successful test took place, and which gaps remain open.

For Decision-Makers

The most important metric is not ‘backup available’, but ‘provably restorable’.

Decision-makers should regularly ask for four things:

  • Critical systems: Which applications must come back first?
  • RTO/RPO: How much downtime and data loss is acceptable for the business?
  • Restore evidence: When was the last successful restore test?
  • Responsibility: Who decides priorities, communication, and external support during an emergency?

A proper restore test does more than improve technical confidence. It also provides evidence for management, insurers, auditors, and customer communication.

For IT

For IT teams, the question is operational capability under pressure. A reliable backup concept should cover at least the following points:

  • 3-2-1-1-0 principle: multiple copies, different media, one external or immutable copy, and no unresolved backup errors.
  • Immutable or offline backups: protection against manipulation by compromised admin accounts or ransomware.
  • MFA and role model for backup consoles: backup administration must not blur with normal domain admin routines.
  • Isolated restore tests: recovery in a test environment instead of only ‘backup job successful’.
  • Documented order of recovery: identity services, network, core applications, business systems, file shares, endpoints.
  • Monitoring and logging: failed jobs, unusual deletion activity, new admin logins, and retention policy changes must be visible.

Important: a green backup job is not a restore test. Only when an application has been started from backup, data integrity has been checked, and the process has been documented does reliable evidence exist.

What to Do Now

1. This week: Prioritize critical systems and data sets.
Management and IT should jointly define which systems must be restored first after an outage.

2. Within 30 days: Run a real restore test.
Do not just restore a single file. Restore at least one business-critical system in an isolated environment and document the result.

3. Within 60 days: Harden backup access.
Review MFA, separate admin accounts, least privilege, and logging for backup systems.

4. Within 90 days: Connect backup and incident response.
The recovery plan belongs in the incident response plan: who decides, who communicates, who documents, and who calls external help?

5. Continuously: Collect restore evidence.
For management, cyber insurance, audits, and customer communication, ‘it should work’ is not enough. What is needed is date, scope, result, deviations, and next actions.

Conclusion

Backups are important. But without regular restore tests, they remain an assumption. For small and mid-sized organizations, that assumption is dangerous: during an incident, screenshots from the backup console do not matter — working recovery processes do.

Endline therefore does not treat backup in isolation, but as part of continuous security operations: operational visibility, prioritization, resilience, and evidence.

Sources