How are backup copies protected from ransomware?

Backup copies are protected from ransomware through layered controls that limit what infected systems can reach, prevent unauthorised changes, and help identify a trustworthy recovery point. Protection is not achieved by simply making an additional copy: the backup design must also account for compromised credentials, malicious encryption, deletion attempts and the possibility that corrupted data could be copied into successive backup versions.

Use retention mechanisms that cannot be altered by ordinary backup operations. A protected retention period can prevent an attacker, an infected server or a compromised backup account from shortening retention or removing selected restore points. This is particularly important because ransomware operators may attempt to delete older copies before encrypting production data. The retention policy should be documented, approved by the organisation and reviewed when systems, regulatory requirements or recovery priorities change.

Maintain multiple recovery points rather than relying on the latest copy. If encrypted or damaged files are included in a backup run, later copies may preserve the problem. Versioned backups allow the recovery process to select an earlier point from before the compromise. Retention should therefore cover enough history to account for delayed discovery, not just the time needed to recover from a recent hardware failure.

Protect backup credentials as a separate security concern. Backup services should use dedicated identities with only the permissions required for their specific tasks. Credentials should not be reused for ordinary user accounts or left permanently available on systems that are being backed up. Administrative actions such as changing retention settings, adding destinations or removing copies should be subject to stronger authentication and a separate approval process where appropriate. This reduces the chance that one stolen password provides control over both production data and its recovery copies.

Encrypt copies, but understand what encryption does and does not provide. Encryption in transit protects data while it moves between systems, while encryption at rest helps prevent disclosure if storage media or a storage account is accessed improperly. Encryption does not by itself stop ransomware from deleting data or encrypting files through an authorised session. Key management must therefore be controlled separately, with restricted access, protected key material and a recovery method that does not depend on the same compromised environment.

Keep backup management components hardened and separate from normal user activity. The systems used to administer backups should be patched, monitored and restricted to authorised administrators. They should not be treated as general-purpose workstations, and their management interfaces should not be exposed more widely than necessary. Network controls can limit which systems may submit jobs, retrieve data or administer the backup platform. Logging should record policy changes, failed authentication, deletion requests and unusual restore activity so that suspicious actions can be investigated.

Scan and assess data before recovery. A backup can be available yet still contain encrypted files, malicious scripts or damaged databases. Recovery procedures should include checks appropriate to the data type, such as malware scanning, file accessibility checks, database consistency checks and examination of representative files. Where possible, copies should be restored into a controlled environment first rather than directly over live systems. This helps distinguish a usable recovery point from one that merely completed successfully as a storage operation.

Test the controls independently of the backup schedule. A successful backup job report confirms that a job ran, but it does not prove that the copy is protected against ransomware or can be used to rebuild a service. Reviews should confirm that protected retention cannot be bypassed through ordinary credentials, that recovery data remains available after a simulated compromise, and that the organisation can locate the required keys, accounts and procedures. Test results should be recorded, with weaknesses assigned for correction and retested after changes.

A practical ransomware-resistant design therefore combines version history, controlled retention, separate credentials, encryption and key protection, hardened administration, monitoring, malware-aware recovery checks and documented testing. The exact controls depend on the organisation’s systems and recovery requirements, but each layer should address a different failure mode rather than relying on a single backup destination or a single administrator account.

S2 Technology Group helps businesses around Stourbridge, Kinver, Wordsley, Kingswinford, Kidderminster, Halesowen, Dudley and neighbouring areas assess backup protection as part of wider IT and cyber security planning. The aim is to align backup controls with the systems and data the organisation must be able to recover.