A ransomware incident is not the time to find out that your backup system can be deleted with the same compromised administrator account that encrypted your files. When business leaders ask, "are backups immutable," they are usually trying to answer a more practical question: if the worst happens, can we actually get our business back?
The short answer is no - not all backups are immutable. Many backup products offer immutability as an option, but it must be configured correctly, monitored, and paired with a recovery plan. A backup that merely exists is not necessarily a backup that will be available when you need it.
What immutable backups actually mean
An immutable backup cannot be changed, overwritten, or deleted for a defined retention period. Once the backup is written to an immutable storage location, even an administrator with normal high-level access should not be able to alter it before that retention period ends.
That protection matters because ransomware operators do more than encrypt active servers. They commonly look for backup consoles, backup repositories, cloud storage credentials, and virtual machine snapshots. If they can delete or corrupt your recovery copies first, they gain leverage. Your organization may be left deciding between a long, expensive rebuild and paying a ransom with no guarantee of receiving usable data.
Immutability creates a barrier between an attacker and the recovery data they want to destroy. It is not a vague security claim. It is a specific storage control that prevents changes for a set amount of time.
The retention period is central to the design. A company might make daily backups immutable for 30 days, monthly backups for a year, and certain records longer to meet contractual, legal, or regulatory requirements. The right period depends on how quickly your organization would detect a problem, how much historical data you need, and what rules govern your records.
Are backups immutable by default?
Usually, no. Traditional backups stored on a local server, a network-attached storage device, or a standard cloud folder are generally not immutable by default. They may be encrypted, access-controlled, and replicated, but those are different protections.
A backup platform may advertise immutable storage while leaving key decisions to the customer or IT provider. For example, immutability may need to be enabled at the repository level. It may require separate credentials, a compatible storage target, a minimum retention setting, or a properly configured cloud storage policy. If those details are missed, the backup may remain editable or deletable.
There is also a difference between a backup job being protected and the entire recovery process being protected. A backup could be immutable in storage but still be difficult to restore because the recovery instructions are outdated, the encryption key is unavailable, or the restoration process has never been tested.
For small and mid-sized businesses, this is why a simple question such as "Do we have backups?" is not enough. A better question is: "Which data is protected, where is it stored, who can change it, how long is it retained, and when did we last prove that we could restore it?"
What immutability protects - and what it does not
Immutable storage is one part of a business continuity plan, not the entire plan. It is highly effective at protecting backup copies from deletion, modification, and many ransomware tactics. It can preserve a known-good recovery point after a security incident or accidental deletion.
It does not stop a phishing email, block an attacker from accessing an employee account, or prevent malware from spreading through your network. It also does not guarantee that the data inside a backup is clean. If malware sits undetected in your environment for weeks and your retention window is too short, your available backups may already contain the problem.
Likewise, immutability cannot solve poor backup coverage. If your backup plan protects a file server but excludes cloud email, line-of-business applications, configuration data, and critical virtual machines, an immutable copy of that one server will not restore the business.
The trade-off is that immutability limits flexibility by design. You cannot quickly delete protected backup data to free storage space, even if someone with authority requests it. That is the point. Organizations need clear retention policies, enough storage capacity, and a process for handling legal or compliance requirements before locking data in place.
A practical backup design for a recoverable business
A dependable approach combines multiple layers rather than relying on one appliance, one cloud account, or one backup product. The familiar 3-2-1 rule remains useful: maintain at least three copies of data, on two different types of media, with one copy kept offsite. For ransomware resilience, many organizations extend that thinking by ensuring at least one copy is offline, air-gapped, or immutable.
The exact design should match the systems that keep your business running. A healthcare practice may need protected electronic health record data, scanned documents, email, and patient communications. A manufacturer may need ERP data, production files, engineering drawings, and network configurations. A law firm may need document management data, email, billing records, and matter files. In each case, the backup scope should reflect operational reality, not just what is easiest to copy.
A practical design also separates duties. The account that manages daily IT work should not automatically have unrestricted power to delete every protected backup. Multi-factor authentication, separate administrative accounts, limited permissions, and alerting on backup changes all make it harder for one stolen credential to become a complete business outage.
Recovery objectives should be documented in business terms. Your recovery point objective answers how much data loss is acceptable - perhaps four hours of work, or perhaps only 15 minutes for a critical system. Your recovery time objective answers how long a system can be unavailable. Those targets determine backup frequency, storage costs, recovery infrastructure, and the level of planning required.
Backup testing is where confidence becomes evidence
A green check mark in a backup console only confirms that a job completed. It does not prove that a server will boot, an application will function, or your staff can access the restored data under pressure.
Regular restore testing should be scheduled and documented. Start with individual files and folders, then test critical applications, virtual machines, and full recovery workflows. Verify that restored data is readable, that key users can perform normal work, and that the process meets the recovery time your business has set.
Testing often exposes issues that are easy to miss. A backup may have captured data but not application-consistent data. A cloud service may need a separate backup. A server may restore successfully but have an expired certificate or missing integration. These are manageable problems when found during a planned test. They are costly problems when found during an outage.
For regulated organizations, test records can also support compliance discussions. They show that backup controls are not just written into a policy but are being operated and checked.
Questions to ask your IT team or provider
You do not need to become a storage expert to assess whether your backup plan is credible. Ask for clear answers to the following questions:
- Which systems, cloud services, and data sets are included in our backups?
- Which copies are immutable, where are they stored, and how long are they protected?
- Can the same account that runs our network delete those copies?
- What are our agreed recovery point and recovery time objectives for critical systems?
- When was the last successful restore test, and what did it include?
- Who is responsible for monitoring failed jobs and responding when a backup issue appears?
If the answers are vague, or if no one can show you the backup scope and recent test results, treat that as an operational risk. Backups are not a set-it-and-forget-it task. They need ownership and regular review as systems, cloud services, and business requirements change.
Gravity Networks helps organizations turn these questions into a documented continuity plan with defined backup coverage, security controls, monitoring, and recovery testing. The goal is not to sell a single tool. It is to make sure a local business can keep operating when a server fails, data is deleted, or a security incident hits.
Immutable backups are one of the strongest safeguards available against destructive attacks, but their value comes from the plan around them. Build the copies, protect them from tampering, test the restore process, and make sure someone is accountable for the result before you need it.