How should businesses protect backups from ransomware?
Businesses should protect backups from ransomware by keeping protected copies isolated from production systems, enforcing strong access controls and using encryption where appropriate. Regularly test that backups can be restored, monitor access for suspicious activity and retain recovery points that ransomware cannot alter or delete.
Ransomware-resistant backups require more than copying files to another location. Businesses need a backup design that limits how attackers can tamper with recovery data, preserves useful historical versions and provides a controlled process for deciding what to recover after an incident.
Start with a complete backup scope. Identify the servers, endpoints, applications, cloud services, databases, configuration files and business documents needed to resume operations. A backup plan that covers only shared folders may leave critical systems unrecoverable, including identity services, line-of-business applications, virtual machines and the settings required to rebuild them.
Document the dependencies between systems as well. For example, an application may rely on a database, authentication service and network configuration. Recording these relationships helps the recovery team restore systems in a sensible order rather than recovering individual files without the services needed to use them.
Use retention policies that reflect how ransomware spreads. Attackers may remain undetected before encrypting data, so a single recent backup may contain already-compromised files. Retention should provide historical recovery points covering the period in which malicious activity could have gone unnoticed. Older versions should not be removed solely because a newer backup completed successfully.
Retention also needs governance. Define who can change the policy, under what circumstances older recovery points may be removed and how exceptions are recorded. This prevents routine housekeeping from eliminating the very versions needed during an investigation.
Separate backup administration from ordinary IT administration. If the same credentials control production systems and backup operations, a compromised administrator account may provide access to both. Use distinct administrative identities, limit privileges to the tasks required and review access when staff roles change. Backup management interfaces should not be exposed more widely than necessary, and changes to schedules, retention or deletion settings should produce an auditable record.
Multi-factor authentication is particularly important for administrative access to backup platforms and cloud consoles. It should be supported by secure credential storage and a documented process for recovering administrative access without weakening the controls that protect the backups.
Do not treat snapshots as a complete backup strategy. Snapshots can provide useful short-term rollback, but they may share infrastructure, permissions or failure points with the systems they protect. They should be considered one recovery mechanism within a broader design, rather than the only copy of business data.
Businesses should also consider whether each backup method can recover the required type of data. File-level recovery may be suitable for individual documents, while a server failure may require application-aware recovery, full-system restoration or bare-metal rebuilding. These capabilities should be recorded for each important workload.
Monitor backup operations as well as backup data. A failed job, unexpected reduction in data volume, sudden change in retention settings or unusual deletion activity can indicate either an operational fault or an attack. Alerts should be directed to people who can investigate them, with clear escalation criteria and records showing how each significant alert was handled.
Backup logs should be retained separately from the main backup platform where practical. This helps preserve evidence if an attacker alters the management system and supports investigation into when access changed, which jobs ran and whether data was removed.
Prepare a recovery decision process before an incident. Define who can authorise restoration, how affected systems will be assessed and how the business will distinguish clean recovery points from potentially compromised ones. The process should include communication with senior management, data protection advisers and relevant suppliers where an incident involves personal or regulated information.
Recovery documentation should include system owners, dependencies, restoration priorities and the information needed to rebuild the backup environment itself. Keep this documentation accessible through a method that does not depend entirely on the potentially affected production network, and review it when systems or suppliers change.
Assess the backup provider and platform, not just the storage capacity. Ask how administrative actions are logged, how retention changes are governed, what recovery formats are supported and how the provider handles suspected compromise. Contracts should make clear who is responsible for configuration, alerts, data protection, incident communication and recovery assistance.
S2 Technology Group can help businesses review backup architecture as part of wider IT support, cyber security and disaster recovery planning. The aim is to align backup protection with the organisation’s systems, risk profile and operational requirements, rather than treating backup as an isolated storage task.
Use immutable recovery points where the backup platform supports them. Immutability prevents backup data from being altered or deleted during a defined protection period, even if an attacker gains access to an administrative account. It is particularly useful for preserving recovery points while an incident is being investigated.
Immutability should be configured deliberately rather than assumed. Confirm which data is protected, how the protection period is set, who can change it and what evidence records those changes. Check that the setting applies to backup copies as well as indexes or catalogues needed to locate them. An immutable backup can still contain encrypted or corrupted data, so it must form part of a wider process that identifies suitable recovery points and validates restoration before affected systems are returned to service.
