Restore point or backup? Rotation schemes, the SaaS backup gap, and what actually survives ransomware

A ransomware group doesn’t need to break your backups to beat you. They just need your backups to be reachable from the same compromised admin account as your live data, or for what you call a backup to actually be a snapshot sitting in the same storage account it’s meant to protect. Both scenarios end the same way: the encryption event takes the recovery option down with the original.

This happens constantly with SaaS data specifically, because most organisations have never asked a basic question: when the platform says your files are safe, whose job is it to make sure a deleted, corrupted, or encrypted copy can still be recovered. The answer is very often “yours,” and the version history or recycle bin you were relying on was never designed to answer it.

Key takeaways

• A restore point (snapshot, version history, point-in-time database checkpoint) and a backup are not the same thing. The test is simple: if the thing that destroys your live data can also destroy your recovery copy, it’s a restore point, not a backup.
• Cloud and SaaS providers are generally responsible for infrastructure durability, not for protecting you against deletion, ransomware, or misconfiguration. Read the terms of service, most say so explicitly.
• A backup rotation scheme is what turns “we have some backups somewhere” into a defined, auditable policy: known copies, at known ages, in known locations. GFS, Tower of Hanoi, and FIFO are the named classics.
• GFS’s tiered logic (daily, weekly, monthly, yearly) is what most modern cloud backup tools implement by default. If your backup policy can’t state its tiers and retention lengths, it isn’t really a scheme.
• ISO 27001 Annex A 8.13 and ISO 22301’s recovery strategy requirements both expect a documented rotation policy and a tested restore, not a screenshot of a job that says “completed.”
• Rotation schemes assume damage is noticed quickly. Silent corruption that outlasts the retention window can contaminate every tier at once, daily, weekly, and monthly alike. Lost or stolen encryption keys are worse still: a lost key makes a perfectly intact backup permanently unreadable, and a stolen one lets an attacker defeat an immutable, air-gapped backup without ever touching it.

Restore point or backup: the test that actually matters

The terms get used interchangeably, which is where the trouble starts. A restore point is a snapshot of a system or dataset at a point in time, a VM checkpoint, a SharePoint version history entry, a database point-in-time recovery window, an OS restore point. It exists inside the same environment as the thing it’s a copy of: same storage account, same tenant, often the same credentials that control the live data.

A backup is a copy held independently of the system it protects: a different account, a different tenant, ideally a different provider or an offline copy, with access controls that a compromised production admin account cannot reach. The independence is the entire point. A snapshot that lives in the same storage account as production is a convenience feature for undoing a mistake quickly. It is not a defence against an attacker, or an administrator, who can delete or encrypt both at once.

Ransomware operators have understood this distinction for years, even where IT teams haven’t. A now-standard step in a ransomware playbook is to locate and delete accessible snapshots, version histories, and backup jobs before triggering encryption, specifically because organisations that call a same-environment restore point their “backup” have nothing left once that step succeeds. If your recovery plan depends on a restore point surviving the same compromise that took out production, it was never a backup, however reassuring the dashboard looked yesterday.

The SaaS shared responsibility gap

Cloud infrastructure and SaaS platforms are built around a shared responsibility model. The provider is responsible for the durability and availability of the platform itself: keeping hardware running, replicating data across their infrastructure, and meeting their own uptime commitments. What most providers are explicitly not responsible for is protecting you against your own mistakes, a malicious insider, a ransomware infection that syncs encrypted files into the cloud, or a retention policy that quietly expires the one version you needed. Read the terms of service for almost any major SaaS platform and you’ll find that data protection and backup are named as the customer’s responsibility, not the provider’s, which is exactly the kind of gap a proper third-party risk assessment is meant to catch before an incident, not after one.

The practical effect is that native recovery features, recycle bins, version history, short-term retention windows, are built for the common case of “I deleted the wrong file an hour ago,” not for “an attacker had admin access for three weeks and everything they touched needs to be rolled back six months.” They’re recovery conveniences, not a backup regime, and they usually have a retention window that a determined or patient attacker can simply outlast.

This is the gap a lot of SaaS customers discover only after they need it: the platform kept its promise (the infrastructure stayed up, nothing was lost to a hardware fault) while the actual data protection question, “can we restore what we had before someone or something deleted or corrupted it,” was quietly left unanswered.

Backup rotation schemes, and why they still matter

Backup rotation schemes were developed for the tape era, when media was expensive, finite, and had to be physically reused. The constraint that produced them, “we can’t keep every backup forever, so how do we decide what to keep and what to overwrite,” hasn’t gone away just because storage is now cheap and virtual. It has just changed shape: unmanaged cloud backup retention doesn’t run out of tape, it runs up an unbounded storage bill and an unaudited pile of copies nobody can account for.

First-In-First-Out (FIFO) is the simplest scheme: new backups overwrite the oldest ones in a fixed-size rotation. Fourteen backup slots gives you fourteen days of rolling history before the oldest is recycled. It’s easy to reason about and needs minimal planning, but it gives you one recovery granularity only, and if corruption or a compromise goes undetected for longer than the window, every remaining copy is affected.

Grandfather-Father-Son (GFS) solves that by running several rotations at different intervals at once: daily backups on a short cycle, weekly backups retained longer, monthly backups longer still, and often a yearly archive retained indefinitely. It’s the scheme almost every serious backup product implements today, AWS Backup, Azure Backup, and tools like Veeam all use GFS terminology directly in their retention policy settings, because it balances recent, granular recovery against longer-term retention without keeping every single daily copy forever.

Tower of Hanoi is the most storage-efficient of the classic schemes, using a mathematically staggered pattern (based on powers of two) so that a small number of media sets can cover a much longer retention span than FIFO would allow with the same number of copies. It buys efficiency at the cost of restore granularity: the further back you go, the sparser your recovery points get, and the scheduling logic is genuinely harder to explain to whoever has to run it. Cheap cloud storage has made the original media-saving rationale largely obsolete, but the underlying idea, that recovery points should thin out logarithmically as they age rather than being kept at a flat density forever, still shows up in how some tiered backup and archive products manage long-term retention.

Incremented media and weighted random distribution round out the set: the former cycles through numbered media sets with the oldest of each cycle archived off permanently, the latter randomly thins older generations using weighted probability. Both are mostly relevant to physical tape estates or irregular, unscheduled backup patterns, and rarely worth choosing deliberately in a modern cloud backup design.

The scheme you pick matters less than picking one on purpose. What every named scheme forces you to do is state, explicitly, how many recovery points you keep, at what intervals, and for how long, which is precisely the thing an unmanaged pile of cloud snapshots or a SaaS platform’s default version history never makes you do.

Corruption and lost or stolen keys: what rotation alone doesn’t fix

A rotation scheme assumes the thing going wrong is sudden and detected quickly, a deletion, a ransomware trigger, an admin mistake caught the same day. Two scenarios break that assumption entirely, and both are worse than losing a single restore point.

Silent corruption beats point-in-time recovery by outlasting it. Point-in-time recovery only helps if you can point to a moment before the damage started. Ransomware is usually loud: encryption happens in a burst, gets noticed within hours, and the restore point from yesterday is almost certainly clean. Corruption from a bad database migration, a slow-acting application bug, or a dormant piece of malware is quieter. If it starts corrupting records on day one and isn’t discovered until day thirty-five, then under a GFS scheme with daily, weekly, and monthly tiers, every daily backup, every weekly rollup, and possibly the nearest monthly archive all contain the same corruption. The rotation scheme did exactly what it was configured to do. It just didn’t have a clean point left to recover to, because detection lagged the retention window rather than the other way round. This is the argument for testing restores against known-good checksums or record counts, not just confirming a restore completes, and for retention windows sized to realistic detection times, not just convenience.

Lost or stolen encryption keys are worse than either. Encrypting backups is correct practice, an attacker who copies an encrypted backup off a compromised account gets nothing readable. But encryption introduces a second single point of failure: the key. Two ways this goes wrong in practice. If the key is lost, stored only in the same tenant as production, held by one administrator who leaves without a documented handover, or generated by a key management service that’s deleted along with the rest of the account during an offboarding clear-out, the backup data still exists, bit for bit, and is permanently unreadable. Mathematically, an encrypted backup with no key is indistinguishable from no backup at all. If the key is stolen, and key management is reachable from the same identity domain as production (the same admin credentials that got phished or brute-forced can also reach the key vault), an attacker doesn’t need to touch your immutable, air-gapped backup to defeat it. They already hold the key that makes it readable, which turns a well-designed backup into a data exfiltration target instead of a safety net, the mechanism behind a growing share of “double extortion” ransomware cases where the backup itself becomes the second thing held to ransom.

Immutability and offsite storage solve the “same blast radius” problem: an attacker who deletes production can’t also delete a backup they can’t reach. They do nothing for the “same key custody” problem: an attacker, or a departing employee, who can reach the key can still make the backup useless, either by taking it or by destroying the only copy of it. A tested restore that only confirms a file exists proves nothing about either scenario. A tested restore that actually decrypts and validates the data proves both.

Where this shows up in ISO 27001 and ISO 22301

Annex A control 8.13 (information backup) requires backup copies of information, software, and systems to be taken and tested regularly, in accordance with an agreed policy. “Agreed policy” is the operative phrase: an auditor asking about backups is really asking whether you have a documented rotation scheme, where the backups actually live relative to production, and evidence that a restore has been tested, not just that a job status says “completed.” A green tick confirms the backup process ran. It says nothing about whether the data inside it is usable, or whether it would still exist after the scenario you’re supposed to be protecting against. Annex A control 8.24 (use of cryptography) is the one that catches the key-custody problem specifically: encryption without a documented key management and custody arrangement, separate from production administrative access, satisfies the letter of the backup control while leaving the actual risk unaddressed.

ISO 22301 comes at the same problem from the recovery side. Your Business impact analysis sets a Recovery Point Objective, the maximum data loss you can tolerate, and your backup rotation scheme is the mechanism that either meets that objective or doesn’t. A daily-only FIFO rotation with a 24-hour cycle cannot deliver a four-hour RPO, no matter how reliably the backup job runs. The rotation scheme and the RPO have to be chosen together, not set independently and hoped into alignment.

Neither standard requires a specific named scheme. Both expect you to be able to answer, without hedging: where do the backups live, is that location independent of production credentials, how far back can you recover at what granularity, and when did you last prove a restore actually works.

Practical questions to ask now

• For each SaaS platform in use, does its native recycle bin, version history, or retention setting count as a backup, or does it only cover accidental deletion within a short window?
• Could a compromised production admin account also delete or encrypt your backups? If yes, they’re restore points wearing a backup’s name.
• Can you state your rotation scheme in one sentence: how many daily, weekly, monthly, and yearly recovery points, and for how long each is retained?
• When was the last time someone actually restored from backup, and decrypted and validated the data, rather than just confirming the backup job completed?
• Are the encryption keys protecting your backups held independently of the identity domain that controls production, so that one compromised or offboarded admin account can’t reach both?
• Would silent, slow-developing corruption be caught before it outlasts your longest retention tier, or only after every restore point already contains it?
• Does your backup retention actually support the Recovery Point Objective set in your BIA, or was it configured independently of it?

Closing

Tape rotation schemes look like a relic of a much older problem, but the underlying discipline they forced, deciding in advance what you keep, for how long, and how independent it is from the thing it protects, is exactly what’s missing from most cloud and SaaS backup setups today. The platforms are reliable. The infrastructure rarely fails. What fails is the assumption that reliable infrastructure and a recoverable copy of your data are the same guarantee.

They aren’t. The organisations that find this out the hard way are usually the ones who never asked which one their SaaS provider was actually giving them.

If you’d like help reviewing your backup and recovery strategy against your Recovery Point and Recovery Time Objectives, or auditing where your SaaS backups actually live, get in touch. Our ISO 22301 and Risk & Governance services both cover this ground.