# How to create a secure backup strategy that survives ransomware

> Protect backups from ransomware: immutable and offline copies, encryption with separate keys, isolated admin accounts, deletion alerts and clean restore tests.

- URL: https://computese.com/how-to-create-a-secure-backup-strategy-for-your-data/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-08-05
- Updated: 2026-09-25
- Topics: Hosting, Security

## In short
- Attackers go after backups on purpose: in a 2024 Sophos survey of ransomware victims, 94% said the attackers tried to compromise their backups, and CISA advises offline, encrypted backups because many variants delete the ones they can reach.
- Keep at least one copy the attacker cannot change or cannot reach: immutable storage such as S3 Object Lock in compliance mode or a locked backup vault, and an offline or air-gapped copy.
- Separate the backup system from production: its own accounts with phishing-resistant MFA, a second person for destructive changes, encryption keys stored apart from the data, and backup software patched early.
- Make tampering loud and recovery clean: alert on deletions, retention changes and stopped jobs, and test restores in an isolated network, scanning for malware before anything goes back to production.

A secure backup strategy assumes an attacker will reach your backups and makes sure they still cannot destroy them. Keep at least one copy immutable or offline, encrypt every copy with keys stored elsewhere, run the backup system under its own accounts with phishing-resistant MFA, alert on deletions and policy changes, and prove recovery by restoring into an isolated network.

This guide is about the security of the backups themselves: why ransomware crews go after them first, and the control that stops each move, with the settings in AWS, Azure, Microsoft 365 and common backup tools. Deciding what to back up, how often and how many copies to keep (the 3-2-1 rule, RPO and RTO) is [backup planning](https://computese.com/how-to-create-a-data-backup-strategy/), a separate topic. So is [backing up a website's files and database](https://computese.com/the-importance-of-backup-solutions-for-website/).

## Why attackers go after backups first

Backups are the reason a victim can refuse to pay, so removing them is part of the plan. The [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) from CISA and its partners (September 2023 edition) warns that many ransomware variants try to find and then delete or encrypt accessible backups, which is why it tells organizations to keep offline, encrypted backups and to test them regularly.

Victims report the same thing. In a [Sophos survey published in March 2024](https://www.sophos.com/en-us/blog/the-impact-of-compromised-backups-on-ransomware-outcomes) of 2,974 IT and security professionals whose organizations had been hit by ransomware, 94% said the attackers tried to compromise their backups, and 57% of those attempts succeeded. Where the backups fell, the median ransom demand was $2.3 million, against $1 million where they survived. Mandiant's [M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026) describes the same shift in its 2025 investigations: ransomware groups, including those using Akira and Qilin, went after backup infrastructure, identity services and virtualization management, and deleted backup objects from cloud storage.

MITRE ATT&CK catalogues these moves as [Inhibit System Recovery (T1490)](https://attack.mitre.org/techniques/T1490/). In practice they fall into five groups:

- **Local recovery points.** Deleting Windows volume shadow copies and the Windows Backup catalog, and removing virtual machine snapshots on ESXi hosts.
- **Online backups.** Anything reachable over the network: backup shares on network storage, and folders that sync to cloud services.
- **Cloud backups.** Turning off versioning and backup policies, then deleting snapshots, database backups, machine images and earlier object versions.
- **Warning signs.** MITRE notes that attackers may disable recovery notifications first, so nobody sees the backups being corrupted.
- **The backup server itself.** CISA's [Akira advisory](https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a) (AA24-109A, updated November 13, 2025) describes the group exploiting unpatched Veeam Backup & Replication servers (CVE-2023-27532 and CVE-2024-40711) and using a PowerShell script that obtains and decrypts the accounts stored on Veeam servers. A backup server holds credentials for everything it backs up, which makes it a target in its own right.

Backups cannot fix data theft. In what the CISA guide calls double extortion, attackers also threaten to publish what they stole, and a restore does not un-leak it. An unencrypted backup copy is also a convenient package to steal, which is where the first control starts.

## Encrypt every copy, and keep the keys somewhere else

Encryption protects backups against theft, both on the way to storage and once they are there. Send every transfer over TLS or the backup tool's own encrypted channel, and encrypt the stored data, ideally on the client before it leaves the server, so the storage provider and anyone who steals the storage account see only ciphertext. The open-source tool restic, for example, [encrypts stored data with AES-256 in counter mode and authenticates it with Poly1305-AES](https://restic.readthedocs.io/en/stable/100_references.html).

The key is the weak point, in both directions. The [NCSC's principles for cloud backups](https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-cloud-backups) point out that an attacker does not need to delete encrypted backups if they can delete or change the key. And if you lose the key yourself, the backup is gone: [restic's documentation](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html) states plainly that losing the repository password means the data is irrecoverably lost. So:

- **Keep keys out of the systems being backed up**, and out of any password vault that production admin accounts can open. A key stored next to the data protects nothing.
- **Keep an offline copy of each key.** The NCSC suggests an out-of-band key backup, such as the master key printed as text or a QR code and kept in a safe.
- **Use separate keys for separate systems** where the tool allows it. restic's threat model notes that a leaked key for a repository shared by several hosts exposes the backups of every one of them.
- **Make key deletion slow and loud.** AWS KMS [requires a waiting period of 7 to 30 days](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html), 30 by default, before it deletes a customer managed key. The key cannot be used while deletion is pending, the deletion can be cancelled, and scheduling it writes a CloudTrail entry you can alert on.
- **Rotate after an incident.** The CISA guide's recovery steps include updating customer-managed encryption keys once the environment has been cleaned.

## Make at least one copy immutable

Immutable storage, also called WORM (write once, read many), accepts new data but refuses to change or delete what it holds until a retention date passes. It is the control for the case that matters most: the attacker already has admin rights. If the storage itself refuses the delete, stolen credentials are not enough. The CISA guide recommends delete protection or object lock on the storage ransomware targets, and the [NCSC's on-premises principles](https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-on-premises-backups) suggest blocking deletion and alteration requests on backups, for example with WORM media.

![An admin laptop sends delete requests at a storage bucket of stacked backup versions. The requests bounce off a shield held by an orange padlock, while a new backup still joins the stack.](https://computese.com/images/blog/how-to-create-a-secure-backup-strategy-for-your-data/lock.229e4e1453-1536.webp)

*Immutability refuses the delete, not the write: new backups keep arriving while locked versions wait out their retention date.*

### Amazon S3 Object Lock: governance or compliance mode

[S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) works only on buckets with versioning, and protects each object version with a retention period, a legal hold (which lasts until someone removes it), or both. Once it is enabled on a bucket, [you cannot disable Object Lock or suspend versioning](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html) for that bucket. The retention mode decides who can undo a lock:

|                                | Governance mode                                                      | Compliance mode                                  |
| ------------------------------ | -------------------------------------------------------------------- | ------------------------------------------------ |
| Who can delete a version early | Users with `s3:BypassGovernanceRetention` who send the bypass header | Nobody, including the account's root user        |
| Can the retention be shortened | Yes, by those same users                                             | No, it can only be extended                      |
| Use it for                     | Testing retention settings; data you may need to release early       | The backup copy that must survive the worst case |

Two details change how much governance mode is worth. The S3 console sends the bypass header by default, so anyone holding the bypass permission can delete governance-locked objects with a few clicks. And for compliance mode, AWS notes that the only way to delete a locked object before its date is to delete the AWS account, which makes the account itself the thing to protect (covered below). A default retention rule applies the lock to every new object written to the bucket:

```json
{
  "ObjectLockEnabled": "Enabled",
  "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 30 } }
}
```

### Azure immutable blob storage

[Immutable storage for Azure Blob Storage](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview) offers the same two tools: time-based retention policies and legal holds, set at container level or, with versioning, down to individual blob versions. A new time-based policy starts unlocked so you can test it, and Microsoft recommends locking it, typically within 24 hours. A locked policy cannot be deleted, and its retention can be extended but never shortened. Retention runs from 1 day to 146,000 days.

### Locked backup vaults

Backup services apply the idea to a whole vault. [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) has a governance mode and a compliance mode; in compliance mode, once a grace time of at least 72 hours ends, neither you nor AWS can change or remove the lock, and no recovery point can be deleted before its retention ends. The [Azure Backup immutable vault](https://learn.microsoft.com/en-us/azure/backup/backup-azure-immutable-vault-concept) blocks the operations that would lose recovery points, and can be locked so that nobody can switch immutability off again.

> [!WARNING]
> A compliance lock binds you too. AWS warns that recovery points set to keep "Always" in a locked vault will be retained, and billed, forever, and the CISA guide cautions that immutable storage does not meet some regulations' compliance criteria and that a misconfiguration can impose significant cost. Test with governance mode or an unlocked policy, check the retention, then lock.

## Keep a copy offline or air-gapped

Immutability stops deletion through the storage's own interface. An offline copy stops everything that needs a network path. [NIST's glossary](https://csrc.nist.gov/glossary/term/air_gap) defines an air gap as an interface where two systems are not physically connected and any logical connection is not automated, so data crosses only manually, under human control. That is a stricter test than many products sold as "air-gapped" meet, so it helps to be precise about what each option isolates:

| Copy                                    | How it is isolated                                     | Trade-off                                                        |
| --------------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------- |
| Tapes or disks rotated to another site  | Physically disconnected; no network path at all        | Manual handling, slower restores, only as fresh as the last swap |
| External drive unplugged after each run | Offline between backups                                | Exposed while connected; depends on someone unplugging it        |
| Logically air-gapped cloud vault        | Separate service-owned account under a compliance lock | Still reached through the provider's control plane               |
| Copy with a second provider             | Different credentials and a different control plane    | One more account to secure and monitor                           |

For physical media, the NCSC adds a practical point: choose the storage location with floods and fires in mind. For cloud copies, the CISA guide suggests considering more than one cloud for cloud-to-cloud backups, in case every account with a single vendor is affected. AWS's [logically air-gapped vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html) is a middle ground: backups are stored in an account owned by the AWS Backup service, the vault comes with a compliance-mode Vault Lock, and with multi-party approval you can still restore from it if your own account is locked out or closed, until the post-closure period ends.

What does not count as offline: a network share mapped on every PC, a USB drive that stays plugged in, or a folder that syncs to the cloud. MITRE lists network storage and synced folders among the online backups attackers delete. On a single Windows PC, [controlled folder access](https://learn.microsoft.com/en-us/defender-endpoint/controlled-folder-access-overview) lets only trusted apps change files in protected folders, which can stop ransomware rewriting your documents, but it is not a backup; our guide to [choosing antivirus software](https://computese.com/choose-the-right-antivirus-software-for-your-pc/) explains how to turn it on, and our guide to [recovering deleted files on Windows](https://computese.com/how-to-recover-deleted-files-on-windows/) covers the copies Windows and OneDrive can give back.

## Give the backup system its own accounts and least privilege

The NCSC notes that in a ransomware attack it is common for attackers to gain access to enterprise admin accounts and move laterally with them. If the backup console accepts those same accounts, the backups fall with the rest of the network. Its on-premises principles ask for credentials used only for the backup system, MFA on any request to alter or destroy backup data, a management interface reachable only from controlled locations, and regular reviews of who has access, physical access to backup media included.

![A production network sends backup data one way into a separate backup zone. Production accounts are blocked from its console, which a separate laptop reaches with an orange hardware security key.](https://computese.com/images/blog/how-to-create-a-secure-backup-strategy-for-your-data/isolation.afeb14763d-1536.webp)

*Backups can flow in from production, but control of the backup system should not: it answers only to its own accounts and keys.*

In practice:

1. **Keep the backup console off the production directory.** If it signs in through the same directory or single sign-on the attacker has just taken over, it is not separate. Use accounts that exist only for the backup system, from a dedicated admin workstation.
2. **Use phishing-resistant MFA.** The CISA guide asks for phishing-resistant MFA on accounts that access critical systems. CISA's [fact sheet on phishing-resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) (October 2022) names FIDO/WebAuthn as the only widely available form, with PKI-based smart cards as the other, and explains why push approvals and SMS codes fall to push bombing and SIM swapping.
3. **Split the roles.** A backup agent needs to add data, not delete it: the NCSC's cloud principles suggest forbidding destructive requests from every customer identity, backup agents included, and authorizing exceptions out of band. Operators run jobs and restores; changing retention or deleting data is a separate, rarer permission.
4. **Require a second person for destructive changes.** Azure Backup's [multi-user authorization](https://learn.microsoft.com/en-us/azure/backup/multi-user-authorization-concept) puts critical operations behind a Resource Guard owned by a different user, which can sit in a different subscription or tenant. Disabling soft delete and removing the protection are always guarded; deleting backup data and reducing retention are guarded by default.
5. **Protect the account that owns the storage.** The only way to delete a compliance-locked S3 object early is to delete the AWS account, and when an AWS account holding a locked backup vault is closed and not reopened within 90 days, AWS deletes the vault's contents. The NCSC's cloud principles add that an attacker should never be able to lock you out of your backups by disabling your accounts: agree a separate, out-of-band way in with the provider.
6. **Patch the backup software early.** The NCSC asks for backup appliances and software to be inside the normal patching regime and on a supported version. The Akira intrusions through unpatched Veeam servers show why a vulnerability in backup software deserves priority.

## Make deletion slow and reversible

Where full immutability is not available, or not affordable for every copy, the next best thing is a delete that takes time and can be undone. The NCSC suggests three mechanisms: soft delete by default, so deleted data stays recoverable for a period from an area that users and administrators cannot purge; a delay on deletion or alteration requests, matched to how often you check; and an alert that reaches someone. Without the alert, soft delete only gives the attacker a timer: if everything is soft-deleted and nobody notices before the period ends, it is gone.

[Azure Backup's soft delete](https://learn.microsoft.com/en-us/azure/backup/secure-by-default) keeps deleted backup data for 14 days by default, extendable to 180 days. Microsoft's secure-by-default change enforces it, so in the regions where that applies it can no longer be turned off. It has limits worth knowing: the disk and virtual machine snapshots kept for instant restores can be deleted directly before the soft-delete period ends. Treat them as a speed feature, not a safety copy. On object storage, the CISA guide recommends versioning, so an overwritten or deleted object can be recovered from an earlier version; versions can still be deleted by someone with permission, which is the gap Object Lock closes.

Retention policy matters as much as the lock. Keep backups for a fixed period of time, not a fixed number of copies. The NCSC explains the attack this prevents: run enough backups of corrupted data in quick succession, and a count-based policy pushes every good copy out. restic's threat model describes the same trick against its own `forget` retention command, with garbage snapshots created until the real ones are pruned. The NCSC also suggests an alert when backup storage approaches capacity, since flooding it is another way to force good data out.

## Alert on failed, changed and deleted backups

Attackers try to work quietly. MITRE notes they may disable recovery notifications before corrupting backups, and the NCSC warns that they may act outside office hours. Its principles list the kinds of change that should raise an alert, whether or not the attempt succeeds. In practice:

| Event                                                        | Why it matters                                         |
| ------------------------------------------------------------ | ------------------------------------------------------ |
| Mass deletion requests, or recovery points deleted           | The direct attack on the backups                       |
| Backups stopping, or jobs failing for a system               | The quiet version: no new good copies from that day on |
| Global retention periods shortened                           | Old copies will expire on their own, without a delete  |
| Encryption policies changed, or a key scheduled for deletion | The data survives but can no longer be read            |
| Admin account details changed, or new admins added           | Someone is preparing to take over the console          |
| Soft delete, immutability or MFA switched off                | The safety net is being removed before the attack      |
| Storage close to capacity                                    | A sign of flooding with junk backups                   |

Send these alerts to a channel that does not depend on the systems under attack. The NCSC suggests a security operations centre for larger organizations and an automated email to a monitored group mailbox for smaller ones; if that mailbox lives in the same tenant the attacker may control, add a second route. Azure Backup shows what good defaults look like: its [built-in security alerts](https://learn.microsoft.com/en-us/azure/backup/monitoring-and-alerts-overview) for deleted backup data or disabled soft delete fire as Sev 0 alerts and cannot be turned off, while job failure alerts are on by default. Also alert on silence: a system with no successful backup in its expected window is as urgent as a failed job.

On Windows endpoints, the CISA guide lists the built-in tools whose unusual use signals an attempt to impair recovery: `bcdedit.exe`, `fsutil.exe` (deletejournal), `vssadmin.exe`, `wbadmin.exe` and `wmic.exe` (shadowcopy or shadowstorage). These are MITRE's examples of what that looks like on a command line, and each one deserves a high-priority alert in your endpoint or SIEM tooling:

```text
vssadmin.exe delete shadows /all /quiet
wbadmin.exe delete catalog -quiet
bcdedit /set {default} recoveryenabled no
```

## Back up SaaS data, and limit what the backup app can reach

Software as a service does not remove the need for backups. Microsoft's [shared responsibility model](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility) is explicit that for every cloud deployment type, including SaaS such as Microsoft 365, you own your data and identities. The CISA guide asks organizations to review that model for services like Microsoft 365 and to back up data often, offline or cloud to cloud.

There are two routes, and each has one account that matters most:

- **The provider's own backup.** [Microsoft 365 Backup](https://learn.microsoft.com/en-us/microsoft-365/backup/backup-overview) keeps restore points every 10 minutes for two weeks and weekly snapshots back to 52 weeks for OneDrive and SharePoint, and every 10 minutes for 52 weeks for Exchange Online, with a recovery window you can set between 3 months and 2 years (1 year by default). The data stays inside Microsoft 365, and the backups are immutable unless the Backup tool's administrator deletes them by offboarding the product. Protect that administrator role as you would the backup console.
- **A third-party backup app.** Most read your tenant with app-only access. Microsoft's [permissions overview](https://learn.microsoft.com/en-us/graph/permissions-overview) calls application permissions highly privileged: an app granted `Files.Read.All` as an application permission can read any file in the organization, and only a Privileged Role Administrator or Global Administrator can consent to it. The backup vendor's console is therefore a key to every mailbox and file you back up.

For either route, check which application permissions the backup app holds in Microsoft Entra ID and remove any it does not need, give the backup console the same separate accounts and phishing-resistant MFA as above, and ask the vendor where copies are stored, whether they are immutable and who can delete them. The CISA guide says that when a third party or managed service provider runs your backups, it should follow the same practices, written into the contract.

## Test restores in an isolated environment

A backup is only proven by restoring it, and the restore is also when an attacker can come back. The CISA guide warns that the ransomware may be only the visible part of an intrusion: the dropper malware behind it has to be found before rebuilding from backups, and clean systems must not be re-infected, for example by adding only clean systems to a new recovery VLAN. Timing matters too. M-Trends 2026 puts the global median dwell time at 14 days in 2025, and 122 days in cyber espionage and North Korean IT worker cases, so the newest backup may already contain the intruder's tools, and retention has to reach back further than that.

![A backup is restored into a sealed test network, where a magnifying glass finds one orange malicious file before a closed gate lets anything through to the production servers.](https://computese.com/images/blog/how-to-create-a-secure-backup-strategy-for-your-data/sandbox.1470edd968-1536.webp)

*A restore test run inside production can bring the attacker back with the data; the isolated network is where you find out safely.*

A restore test that proves something:

1. **Build the isolated environment before you need it:** a separate network segment or cloud account with no route to production, no shared credentials and no trust with the production directory.
2. **Pick the restore point deliberately.** In a real incident, choose one from before the first sign of compromise, not simply the latest.
3. **Scan before release.** Veeam's [Secure Restore](https://helpcenter.veeam.com/docs/vbr/userguide/av_scan_about.html) checks restore points for malware, with its own engine, third-party antivirus or YARA rules, before a machine returns to production. [Malware protection in AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/malware-protection.html) uses Amazon GuardDuty to scan recovery points, and AWS recommends on-demand scans to find your last clean backup and a full scan before a restore.
4. **Look for persistence as well as malware:** admin accounts that should not exist (Akira operators have created new accounts and added them to the administrators group), scheduled tasks and remote access tools.
5. **Check the data, not just the job status:** the application starts, the database is consistent, files open and record counts match.
6. **Time it and keep the evidence.** [AWS Backup restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html) runs scheduled restores, records how long each took, supports a validation step and then deletes the test resources. Whatever the tool, keep a dated record of what was restored, how long it took and what failed.

> [!TIP]
> Restore at least one complete system each time, not a single file. A file restore proves the storage works; a full restore proves the credentials, keys, documentation and people work too.

## A secure backup checklist

Use this to review an existing setup. Each line should have an owner and a way to prove it:

| Control                                                | What it stops                               | How to check it                                                   |
| ------------------------------------------------------ | ------------------------------------------- | ----------------------------------------------------------------- |
| One immutable copy (compliance lock or locked vault)   | Deletion with stolen admin credentials      | Try to delete a test backup with an admin account; it must fail   |
| One offline or air-gapped copy                         | Anything that needs a network path          | Name the copy, where it is and when it was last refreshed         |
| Encryption with keys stored apart, plus an offline key | Theft of backup copies; deletion of the key | Restore on a clean machine using only the offline key copy        |
| Separate backup accounts with phishing-resistant MFA   | Reuse of stolen production admin accounts   | List who can sign in to the console, and how                      |
| Second-person approval for destructive changes         | One compromised administrator acting alone  | Attempt to shorten retention; it should need approval             |
| Soft delete and time-based retention                   | Fast deletion; flooding with junk backups   | Check the soft-delete period and the retention rules              |
| Alerts on a channel outside production                 | Silent sabotage                             | Trigger a test alert and time how long it takes to reach a person |
| Patched backup software                                | Exploits of the backup server               | Compare versions against the vendor's security advisories         |
| Isolated restore tests with malware scanning           | Restoring the attacker along with the data  | Dated evidence of the last full restore and its duration          |

If you would rather have this run for you, our [hosting and maintenance service](https://computese.com/services/hosting-maintenance/) keeps three copies on two kinds of storage, one off-site and immutable, and runs restore drills that restore a recent backup into an isolated environment and record how long recovery took. Our [security scanning](https://computese.com/services/security-testing/) reviews AWS and Azure accounts for public storage and snapshots, over-permissive IAM and stale keys, and checks websites for exposed files, panels and backups.

## Key terms
- **Immutable backup**: A backup the storage refuses to change or delete until its retention date has passed, whatever permissions the person asking has. New backups can still be written.
- **WORM (write once, read many)**: The storage model behind immutability: data can be written and read, but not modified or deleted while a retention period or legal hold applies.
- **Governance and compliance mode**: The two S3 Object Lock retention modes. Governance mode lets users with a special permission delete early; compliance mode lets nobody, including the account's root user, delete or shorten the retention.
- **Air-gapped backup**: A copy with no physical connection to your systems and no automated logical one, such as a tape or disk moved off-site. Data crosses only manually, under human control.
- **Logically air-gapped vault**: A cloud backup vault isolated by accounts, locks and permissions rather than by physical separation, such as AWS Backup's vault kept in a service-owned account under a compliance-mode lock.
- **Soft delete**: Deleted backup data is hidden but kept recoverable for a set period, in storage that users and administrators cannot purge, so a malicious deletion can be undone.
- **Phishing-resistant MFA**: Multi-factor authentication that a fake login page cannot capture and replay, such as FIDO2/WebAuthn security keys or PKI-based smart cards.
- **Multi-user authorization (MUA)**: A control that makes destructive backup operations, such as disabling soft delete or cutting retention, require approval from a second person who owns a separate resource.
- **Dwell time**: How long an attacker is inside a network before being detected. It decides how far back a clean restore point may be.

## Common questions

### What makes a backup ransomware-proof?

No single product does. Recovery is reliable when at least one copy is immutable or offline, the backup system's accounts and keys are separate from production, tampering raises an alert, and restores have been tested. CISA's #StopRansomware Guide recommends offline, encrypted backups that are tested regularly.

### What is the difference between immutable and air-gapped backups?

An immutable backup stays online, but the storage refuses to change or delete it until its retention date. An air-gapped backup has no automated connection to your systems at all, like a tape or a disconnected disk. Immutability stops deletion through the storage's own interface; an air gap stops anything that needs a network path. Many teams keep one of each.

### Should I use S3 Object Lock governance mode or compliance mode?

Use governance mode to test your retention settings, because users with the bypass permission can still delete early. Use compliance mode for the copy that must survive a full account takeover: nobody, including the root user, can delete a locked version or shorten its retention. Size the retention first, because compliance mode binds you as well.

### Should backups be encrypted, and where should the key be kept?

Yes, in transit and at rest, ideally before the data leaves the server. Keep the key outside the systems being backed up and away from production admin accounts, with an offline copy in a safe. Deleting the key destroys a backup as surely as deleting the data, and losing it yourself does the same.

### Is OneDrive, Dropbox or Google Drive sync a backup?

Not by itself. Sync copies changes, including files ransomware has encrypted, and attackers treat synced folders as online backups to delete. Version history helps with small accidents; for ransomware, keep a separate backup with its own retention that the synced account cannot change.

### How often should we test restoring backups?

On a schedule and after major changes, restoring a whole system into an isolated environment rather than a single file. CISA advises regularly testing the availability and integrity of backups in a disaster recovery scenario, and tools such as AWS Backup restore testing can run and time scheduled restores for you.

## Sources
1. [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide), CISA
2. [The impact of compromised backups on ransomware outcomes](https://www.sophos.com/en-us/blog/the-impact-of-compromised-backups-on-ransomware-outcomes), Sophos
3. [M-Trends 2026: Data, Insights, and Strategies From the Frontlines](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026), Google Cloud (Mandiant)
4. [Inhibit System Recovery (T1490)](https://attack.mitre.org/techniques/T1490/), MITRE ATT&CK
5. [#StopRansomware: Akira Ransomware (AA24-109A)](https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a), CISA
6. [References: design and threat model](https://restic.readthedocs.io/en/stable/100_references.html), restic
7. [Principles for ransomware-resistant cloud backups](https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-cloud-backups), NCSC (UK)
8. [Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html), restic
9. [Deleting AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html), Amazon Web Services
10. [Principles for ransomware-resistant on-premises backups](https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-on-premises-backups), NCSC (UK)
11. [Locking objects with Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html), Amazon Web Services
12. [Configuring S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html), Amazon Web Services
13. [Store business-critical blob data with immutable storage in a WORM state](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview), Microsoft Learn
14. [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html), Amazon Web Services
15. [Immutable vault for Azure Backup](https://learn.microsoft.com/en-us/azure/backup/backup-azure-immutable-vault-concept), Microsoft Learn
16. [Glossary: air gap](https://csrc.nist.gov/glossary/term/air_gap), NIST Computer Security Resource Center
17. [Logically air-gapped vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html), Amazon Web Services
18. [Protect folders from ransomware with controlled folder access](https://learn.microsoft.com/en-us/defender-endpoint/controlled-folder-access-overview), Microsoft Learn
19. [Implementing Phishing-Resistant MFA (fact sheet)](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf), CISA
20. [Multiuser authorization using Resource Guard](https://learn.microsoft.com/en-us/azure/backup/multi-user-authorization-concept), Microsoft Learn
21. [Secure by default with soft delete for Azure Backup](https://learn.microsoft.com/en-us/azure/backup/secure-by-default), Microsoft Learn
22. [Monitoring and reporting solutions for Azure Backup](https://learn.microsoft.com/en-us/azure/backup/monitoring-and-alerts-overview), Microsoft Learn
23. [Shared responsibility in the cloud](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility), Microsoft Learn
24. [Overview of Microsoft 365 Backup](https://learn.microsoft.com/en-us/microsoft-365/backup/backup-overview), Microsoft Learn
25. [Overview of Microsoft Graph permissions](https://learn.microsoft.com/en-us/graph/permissions-overview), Microsoft Learn
26. [Secure Restore](https://helpcenter.veeam.com/docs/vbr/userguide/av_scan_about.html), Veeam Backup & Replication User Guide
27. [Malware protection in AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/malware-protection.html), Amazon Web Services
28. [Restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html), Amazon Web Services