Picture the audit. An MSP runs backup for a regional healthcare group. The insurer's assessor asks them to prove that 90 days of patient backup data was never altered or deleted during the retention window. Not assert it. Prove it. The backup console shows a green immutability flag on every job. The assessor wants something else: independent evidence that the storage actually enforced that flag, and a record of every operation the MSP could not have edited after the fact.
The backup was never the problem. The proof was.
The Immutability Flag Passes the Demo and Fails the Audit
Every MSP now sells immutable backup as ransomware protection. Most are reselling a claim they cannot independently demonstrate.
Here is why. The immutability flag lives at the application layer. The backup software marks a job as locked and refuses to overwrite it through its own interface. That is real and useful. It is also a policy the application enforces against itself. Whether the storage underneath actually enforces object lock, independent of the backup application, is a different question with a different answer.
Clients conflate the two. They hear "immutable" and assume the bytes cannot be changed by anyone. What they have is an application that declines to change them. Compromised storage credentials, an insider with backend access, a lock the storage silently fails to honor: the flag tells you nothing about any of it. The flag is a statement of intent, not a record of fact.
And attackers know exactly where that gap is. In Veeam's 2025 ransomware trends research, 89% of organizations hit by ransomware had their backup repositories targeted, and attackers modified or deleted an average of 34% of those repositories (Computer Weekly). The layer you point to as your defense is the layer they go after first. That is precisely when "our software says it was locked" stops being an acceptable answer.
The Record You Did Not Write and Cannot Quietly Rewrite
Audit-ready backup storage closes the gap by moving the proof below the application. Every operation against the object store is recorded on an append-only immutable storage ledger: every write, every retention setting, every attempted delete. Two mechanisms make that record verifiable rather than trusted. First, content-addressing: each object is identified by a Content Identifier (CID) derived from its bytes, so changing a single byte produces a different CID, and the mismatch is detectable by anyone with access. Second, the ledger is maintained across independent nodes, so no single operator can silently rewrite history.
When the assessor asks whether a backup was modified during retention, the answer stops being "our software says no" and becomes a record that exists independently of both the software and the operator.
The honest framing is detection, not prevention. Nothing here claims a backup can never be touched, and a tamper-evident ledger does not stop a stolen key from being used. The claim is narrower and more useful: any modification is independently detectable, and the operation history cannot be edited afterward. That converts "trust the vendor" into "audit it yourself." It is the difference between an assurance and evidence, and it is the thing an insurer's audit or a post-incident forensic review is actually testing. The cyber-resilient backup breakdown walks through the architecture.
When You Certify Destruction, Where Did the Bytes Go?
Retention has a back end too. When a window closes and data must be destroyed, "deleted" usually means a pointer was removed while the bytes linger on shared media. For a regulated client certifying destruction, lingering bytes are a liability, not a footnote.
Auditable storage handles end of life cryptographically: data is encrypted, and destroying the keys renders it unrecoverable rather than merely dereferenced. The destruction lands on the same ledger as every other operation, so when a compliance officer asks for evidence that retired backups are actually gone, you hand over a record you did not author by hand.
Where Akave Fits
Akave Cloud is an S3-compatible object store built on an immutable storage ledger, with every object content-addressed so modification is independently detectable without trusting a vendor-controlled log. It works as a backup copy target through the standard S3 workflows enterprise backup platforms already use. No re-architecture. The audit trail lives at the storage layer, outside the systems your team controls day to day.
The economics fit backup's read-back reality. The Standard tier runs $5.99 per TB/month for long-retention data, no per-request charges, with egress free up to 3x stored capacity monthly (100TB minimum commit). That allowance is the point: recovery tests and auditor spot checks mean reading data back, and on hyperscaler storage every restore carries an egress line item people quietly avoid. Below 100TB, or for heavier read-back, the Plus tier applies at $14.99/TB flat with unlimited free egress. Data sits in SOC 2-certified facilities, GDPR-ready, with 99.9% availability and durability up to 11 nines (pricing).
The Question That Fails Audits Even When the Backup Is Perfect
Back to the stalled audit. The data was intact. What failed was the proof, because the only record of what happened to that data lived in a system the vendor controlled. When the assessor asked whether the record itself could have been changed, the honest answer was "yes, in principle." That answer fails audits even when the backup is perfect.
You can keep selling immutability as a claim and hope nobody asks you to back it. Or you can run backup on storage where the proof exists before anyone asks. Setup runs through standard S3 workflows. See the free trial and docs for the backup copy target configuration.
FAQ
My backup software shows an immutability flag on every job. Isn't that proof nothing changed?
No. The flag is enforced by the application against its own interface. It does not prove the storage layer beneath it enforced object lock, or that nothing changed through other paths. Independent proof requires a record that lives outside the backup application and outside any log the operator can edit.
When the assessor asks me to prove nothing changed, what do I hand over?
The storage-layer record: every operation written to an append-only ledger, with each object carrying a CID derived from its bytes that changes if any byte changes. Because the ledger is held across independent nodes, the assessor can verify it directly instead of taking a vendor's word.
Does this prevent ransomware from touching my backups?
It guarantees detection, not invulnerability. A stolen credential can still attempt operations, but every attempt is recorded on a ledger that cannot be edited afterward, and any successful modification changes the object's CID. Combined with object lock and WORM controls, that makes tampering both harder to do and impossible to hide. That is what recovery and forensics actually depend on.
How do I prove data was actually destroyed when retention ends?
Cryptographically. Data is encrypted, and destroying the encryption keys renders it unrecoverable rather than just dereferenced. The destruction is recorded on the same ledger, giving a compliance officer verifiable evidence rather than a screenshot of an empty folder.
Won't egress bills for restores and audit checks eat the savings?
The Standard backup tier ($5.99/TB/month, 100TB minimum) includes free egress up to 3x stored capacity monthly and no per-request charges, which covers routine restores, recovery tests, and audit pulls for most backup patterns. Heavier read-back or sub-100TB deployments fit the Plus tier at $14.99/TB flat with unlimited free egress.
Sources
- Veeam, "2025 Ransomware Trends: From Risk to Resilience": 89% of ransomware victims had backup repositories targeted; average 34% of repositories modified or deleted. Via Computer Weekly. https://www.computerweekly.com/news/366628213/Data-resilience-critical-as-ransomware-attacks-target-backups
- Akave Cloud pricing, tiers, egress allowance, durability, and availability: https://akave.com/akave-cloud-pricing