Your data, always recoverable, always protected.

Not all backups survive a ransomware attack. Operators know that standard cloud sync and snapshot-based backups are reachable from the same compromised credentials used to encrypt your production data. A ransomware-proof backup architecture requires layered controls that remove attacker access to your recovery path entirely.

• 3-2-1-1-0 rule — Keep at least three copies of data, on two different media types, with one copy offsite, one copy offline or air-gapped, and zero unverified backups. The original 3-2-1 rule predates ransomware; the extra "1" (offline) and "0" (verified) are what close the gaps attackers exploit against standard cloud-synced backups.
• Immutable storage — Object-lock or WORM (write-once, read-many) storage prevents any process — including malware running as a domain admin — from deleting or overwriting backup data before the retention period expires. Azure Immutable Blob Storage, AWS S3 Object Lock, and purpose-built backup appliances all support this. Immutability must be set before an attack occurs; it cannot be applied retroactively.
• Air-gapped copy — An air-gapped backup has no live network path from your production environment. Tape rotated offsite, a physically disconnected appliance, or a cloud vault with no API credentials stored in your network all qualify. Air gaps stop credential-based attacks cold: even if an attacker dumps every password on your domain, they cannot reach the recovery copy.
• Backup account isolation — Backup service accounts and management consoles must not share credentials with Active Directory or your primary cloud tenant. Attackers routinely pivot from a compromised endpoint to backup infrastructure within hours of initial access. Separate identity providers, separate MFA enrollment, and no password reuse are non-negotiable.
• Tested recovery, not assumed recovery — A backup that has never been restored is not a backup — it is a hope. Monthly restore tests of a rotating sample of systems, documented with actual RTO measurements, are the only way to know whether your recovery window is achievable. Many SMBs discover backup software misconfigurations only during a live incident.
• Encryption in transit and at rest — Backup data must be encrypted before it leaves your environment. Vendor-managed encryption is insufficient if the vendor is also compromised. Customer-managed keys (CMK) stored outside the backup environment ensure that a breach of the backup platform does not expose plaintext data.
• Ransomware-specific recovery testing — Standard DR tests restore a system from a clean failure. Ransomware recovery is different: you must determine the point of initial compromise, ensure the restore target is clean, validate that malware is not present in the backup image itself, and confirm that all restored systems are patched before reconnecting them to the network. These steps must be documented and rehearsed annually at minimum.

Ransomware recovery is not a single action — it is a sequenced set of decisions made under time pressure. The steps below reflect the order of operations Quantm follows on every engagement. Deviating from this sequence — particularly by rushing to restore before containment is confirmed — is how organizations get re-encrypted within 48 hours of paying a ransom.

1. 1
   Detection and scope assessment

   The first priority is understanding what was hit. Quantm's monitoring stack correlates endpoint telemetry, backup job failures, and file-system change-rate anomalies to identify the scope of encryption within minutes of the first alert. We identify Patient Zero (the initially compromised device), the blast radius (all encrypted or potentially compromised systems), and whether the attacker still has an active foothold. Scope assessment takes 30–90 minutes and drives every subsequent decision.

2. 2
   Network isolation and credential reset

   Affected systems are isolated at the network layer — not just shut down — to prevent continued exfiltration while preserving memory artifacts for forensics. All privileged account passwords are rotated immediately, including service accounts, backup accounts, and any credentials found in password managers or browser stores on compromised endpoints. If Active Directory shows signs of compromise (new admin accounts, modified GPOs, DCSync activity), we treat the entire domain as untrusted and begin parallel domain recovery procedures.

3. 3
   Clean recovery environment preparation

   Before any data is restored, the recovery destination must be verified clean. This means deploying restore targets from known-good OS images — not snapshots of the compromised environment — and confirming that the network segment used for recovery has no path back to the infected environment. This step is often skipped by organizations attempting self-recovery, which explains why re-infection during restoration is one of the most common ransomware recovery failures.

4. 4
   Backup integrity validation and restore point selection

   Quantm validates backup integrity before beginning the restore. For each system in scope, we test-mount the candidate backup image, run malware scanning against the mounted volume, and verify that the backup predates the earliest evidence of attacker activity. If the selected restore point tests positive for malware (which occurs in roughly 15–20% of incidents where dwell time exceeded 30 days), we step back to an earlier restore point and repeat validation. This process adds hours but prevents restoring a pre-encrypted but already-compromised image.

5. 5
   Phased restoration and validation

   Restoration proceeds in priority order: identity infrastructure and core networking first, then business-critical applications, then endpoints. Each restored system is validated for functionality and malware-free status before being reconnected to the network. Business owners are briefed at each phase boundary on RTO progress versus the baseline estimate established during scope assessment. For most SMBs on Quantm-managed backup infrastructure, critical systems are operational within 4 hours of beginning the restore phase.

6. 6
   Root cause remediation and OPC reporting assessment

   Once operations are restored, we conduct root cause analysis to identify and close the initial access vector. Common findings include unpatched VPN appliances, compromised MFA bypass configurations, and phishing-derived credentials. We also prepare the PIPEDA breach notification assessment: documenting what personal information was in scope, the likelihood that it was accessed or exfiltrated, and whether mandatory OPC reporting applies. This documentation is produced within 72 hours of incident containment and is suitable for submission to the OPC, your insurer, and affected individuals if required.