Ransomware backup strategy: immutable, tested, recoverable

This page covers the backup and recovery strategy against ransomware. The operational response during a crisis including forensics and regulatory notification is on Incident response within 72 hours. The framework for roles and notification chains sits on Create incident response plan. Technical prevention and recovery at endpoint level is on Halcyon Anti-Ransomware. Insurance warranties and claim logic are on SOC and cyber insurance. The operational picture is in the pillar SOC as a Service Switzerland.

The most frequent causes of failed recovery are not technical defects but attack vectors against the backup layer itself. Ransomware groups deliberately target backup consoles, domain-joined backup servers and snapshot stores to delete or encrypt them before the main encryption event. A backup reachable with the same domain credentials as production is not a backup during a ransomware case.

• Backup accounts share the same Active Directory domain as production. Attackers with domain admin rights delete backups first.
• Snapshots and replicas live on the same storage system as the production volumes and are encrypted together.
• Restore tests only cover single files, never full systems or application stacks. The real crisis becomes the first full restore.
• The immutability window is shorter than the typical dwell time of attackers (currently 5 to 21 days). Attackers wait the window out.
• Recovery teams lack a documented recovery order. They improvise the sequence: database before application, identity before database, and network before identity.

The established pattern for ransomware-resilient backups is 3-2-1-1-0. It requires at least three data copies on two different media, including one off-site copy and one immutable or air-gapped copy. Restore tests must produce zero errors. The last two digits are the ransomware-critical part and appear explicitly on insurer proposal forms.

• Use object lock in compliance mode. Administrators can override governance mode, leaving backups vulnerable once attackers compromise backup admin rights.
• Retention window at least 30 days, better 60 to 90, given the dwell time of modern ransomware campaigns.
• Separate identity system for the backup console (separate tenant, separate MFA, no shared privilege inheritance with production).
• Monitoring on configuration changes to immutability policies. Any shortening of the window is an alert signal for the SOC.
• Air-gap option (tape, offline volumes) for the most critical datasets, where compliance requires it (FINMA, critical infrastructure).

• Restore tests at least quarterly, documented with date, system selection, duration, result, sign-off.
• Rotation principle: across twelve months every business-critical system is covered at least once in a restore test.
• One major recovery drill per year (full stack, several systems, isolated restore zone), integrated with the tabletop exercise.
• Restore zone: isolated network segment in which recovered systems are validated before returning to production. Attacker artefacts are detected here.
• Documented recovery order: identity and DNS first, then databases, then applications, then front ends. Teams practise this order in advance to avoid improvisation.

A pure backup strategy addresses data recoverability while leaving downtime unanswered. Restoring entire environments typically takes days to weeks depending on volume, order and restore zone. A complementary recovery layer addresses encryption at endpoint level. Halcyon Anti-Ransomware detects the encryption attempt itself, aborts it and in many cases restores individual endpoints. The backup restore sequence then only needs to cover the systems lost. Halcyon complements backups by shortening the recovery window. It protects the production copy, which teams need first in a crisis.

• Immutability configuration on the day of the incident (screenshots, configuration state, retention window).
• Restore test history for the last twelve months with date, system, result and sign-off.
• Network segregation of the backup environment from the production domain (identity, network, privilege inheritance).
• MFA and access log for the backup console in the 30 days before the incident.
• Documented recovery order and its exercise history over the last twelve months.

If any of this evidence is missing, cover reduction or denial is likely, regardless of whether the control existed in reality. See SOC and cyber insurance for the warranty logic.