Backups should be designed for an attacker as well as an equipment failure. CISA's StopRansomware guide recommends offline, encrypted copies and regular testing of their availability and integrity.

No backup architecture is “ransomware-proof.” The aim is to preserve usable recovery options and demonstrate how the organization will restore its important services.

Understand the risk without overstating it

In a Sophos 2024 survey of 2,974 professionals at organizations hit by ransomware, 94% reported an attempt to compromise backups. That is a result for the surveyed population, not a measurement of every ransomware attack.

Review whether production administrators, compromised identities or the backup platform itself could delete all recovery copies. Separate administrative access and verify what remains recoverable after the failure of each security boundary.

Choose immutability deliberately

Immutability is a product capability with configuration and retention conditions. Amazon S3 Object Lock documentation distinguishes governance mode, which privileged permissions can bypass, from compliance mode protection for retained object versions.

Do not assume the same semantics for every provider. Record the storage target, retention mode, permissions, expiry behavior and recovery procedure.

For an Acronis design, check the exact product and storage prerequisites in its immutable storage documentation. A feature in one version or deployment model should not be promised for every SKU.

Keep independent recovery options

An offline copy has a different exposure from an online repository. A separately administered online copy can also be useful, but its access paths and dependencies need to be understood.

Use the copy count and location as a starting point, then ask what could make several copies fail together. Shared credentials, retention mistakes, encryption-key loss and undetected corruption should be considered alongside ransomware.

Choose the retention window and capacity with the business, including how long it may take to detect an incident. Test that the required keys and credentials are available during recovery.

Prove recovery, not just job completion

A successful backup job does not establish that the application will resume within its objective. Restore representative systems, check data consistency and validate dependent services.

Record the recovery point, elapsed time, application result and any corrective actions. Recovery after a compromise also needs a process for selecting an appropriate clean point and restoring into a controlled environment.

Keep notification separate from restoration

Article 24 of the PDPL Implementing Regulations sets a 72-hour awareness-based notification window for qualifying personal-data breaches. This is not a universal recovery-time objective.

Assign incident assessment and notification to named roles while the technical team investigates and restores. Preserve evidence and follow the applicable reporting conditions rather than assuming every incident has the same notification duty.

When comparing suppliers, the Acronis provider selection guide explains how to check entitlements, account ownership and recovery responsibilities.

BustanTech offers backup and disaster recovery services and Acronis backup solutions. Contact us to discuss recovery objectives and a testable design.