The useful question is not only, “Did the last backup job complete?” It is also, “Can we reach and restore a usable copy if an attacker tries to delete, encrypt, or alter our backups?” This article is an editorial template for small and medium businesses designing backups that are more resilient to ransomware. It does not assume that one product, setting, or storage location solves the whole problem.
Ransomware can target backups that are accessible from the affected environment, including attempts to delete or encrypt them. For that reason, the Cybersecurity and Infrastructure Security Agency (CISA) recommends keeping at least one backup copy offline or otherwise isolated. This is not a recommendation for a particular vendor. It is a design requirement that should become a clear operating procedure in your environment.
Start with what must be restored
Before choosing a backup schedule or storage system, list the systems and data the business actually needs. The backup planning guidance from the National Institute of Standards and Technology (NIST) includes deciding what to protect, how to maintain usable backup files, and how to support disaster recovery. This article uses that as a planning frame, not as a claim that every organisation needs the same inventory.
As an internal decision, group systems into services the business cannot operate without, important data whose recovery can wait, and material that can be recreated. For each group, define the longest acceptable time between the latest restorable copy and the point of disruption. This is how this article uses recovery point objective (RPO). The backup schedule should match that objective rather than an unreviewed default. That scheduling advice is this article’s design recommendation, not a number supplied by the sources.
Separate an available copy from a protected copy
Files in a cloud service or on another server are not automatically protected from ransomware. If the same accounts or systems can reach and change them, they may be exposed to the same incident. Microsoft’s guidance on preparing a backup and recovery plan says that online backups should use controls such as multi-factor authentication (MFA) or approval steps before modification, and describes stronger protection through immutable, offline, or off-site storage.
As an editorial design choice, select one or more of these paths:
- An offline copy when continuous connectivity is not required.
- An off-site copy, with documented ownership and a documented process for reaching it during recovery.
- Immutable storage when your platform and retention policy can support it.
If you use an external drive, do not leave it continuously connected. CISA’s guidance on protecting data stored on devices states that ransomware may be able to access, corrupt, or delete a connected backup. “Off-site” also does not automatically mean “secure”; review the accounts, modification path, and recovery access for that location.
Separate backup administration from production administration
This article recommends not making backup operations fully dependent on an administrative identity that also manages production systems. Separate backup administration accounts, and identify who can create a job, delete a copy, change retention, or approve a sensitive change. For online backups, use MFA or an approval step before modification where the platform supports it, consistent with the Microsoft guidance cited above.
These steps are not presented as a guarantee that an attack will be stopped. They are design controls intended to make it less straightforward to change every backup through one administrative path, and they need practical testing. Record the accounts, change approvers, and the method for recovering administrative access if a device or account is lost.
Encrypt backups, but do not confuse encryption with isolation
CISA’s ransomware guidance recommends encrypting backups and regularly testing their availability, integrity, and restoration, rather than checking only whether a backup job completed successfully. Encryption protects backup content according to your key and permission design, but it does not by itself answer whether an attacker can delete or alter the copy or block access to it. Treat encryption, isolation or immutability, and restore testing as separate controls.
This is also a good point to maintain an internal record of where keys are held, who may use them, and whether recovery depends on a service or account in the production environment. Implementation details vary, so this article does not specify a product, retention period, or key type.
Protect recovery documentation, not only data files
A recovery team may need configuration information, network diagrams, and procedures for restoring accounts and services. Microsoft’s guidance says that recovery documentation, configuration information, and network diagrams should survive an attack because threat actors may target them to obstruct restoration. Based on that source-backed point, this article recommends keeping a protected copy of these materials, with instructions that can be read when normal tools are unavailable.
Include the restoration order, contacts, dependencies between services, access to isolated copies, and post-restore checks. This is a proposed design checklist, not a requirement from a particular provider. Keep system images or infrastructure-as-code templates where they are relevant to your environment, and test that these materials are available outside the path most likely to be affected.
Test restoration in a clean environment
A successful backup job does not demonstrate that restoration will work. CISA says backups should be regularly tested for availability, integrity, and restoration. Microsoft’s ransomware-resilient backup architecture guidance adds that restore testing should validate both backup copies, measure recovery time objective (RTO) and RPO, and preferably restore into a clean environment isolated from the compromised production estate.
- Choose a specific system and backup copy, and record why it was selected.
- Check the copy’s integrity and confirm that your procedures can access or decrypt it.
- Restore into a clean, isolated environment rather than over a system suspected of compromise.
- Measure the actual restoration time and compare the recovered data with business needs.
- Record failures, correct the procedure, and test again.
Testing should not be a one-time demonstration. Make the frequency an operational decision linked to system and policy changes. The number and timing of tests in this template are editorial recommendations; the team should set them according to risk and capacity.
For higher-value workloads, add independent layers carefully
For critical workloads, Microsoft’s Azure Backup architecture guidance says that two independent immutable copies across separate administrative or regional boundaries can reduce single points of failure. This design is not a guarantee and does not remove the need for restore testing. It should also be balanced against storage cost, retention requirements, and operational complexity. That balance is an organisational decision, not a price comparison between vendors.
A decision checklist before adopting the plan
Use the checklist attached to this article to see whether the plan has a clear path from discovery to restoration. If an answer is “no”, record the risk, owner, and target date instead of treating a successful backup job as sufficient evidence. The broad recommendation in this template is to treat isolation or immutability, separated administration, encryption, recovery documentation, and restore testing as connected layers.
In short, a resilient backup is more than an extra copy. It is a copy that is isolated or protected from modification, managed through separated permissions, encrypted, accompanied by recovery documentation, and actually restored in a clean environment. Test what you do not yet know before you need it.