Every backup strategy written for a lean team assumes the same thing: that when the bad day comes, the backups will be sitting there, intact, waiting. That assumption is the part attackers attack. Encrypting production data is the noisy half of a ransomware operation. The quiet half, which usually happens first, is finding your backups and making sure they cannot save you.
This post is for a small engineering team, five to fifteen people on AWS, GCP or Azure, with a backup job that has been green for months and a restore nobody has attempted. The goal is narrow: make the backup copy impossible to delete even by a fully compromised admin, then prove by measurement that you can restore from it.
What generic ransomware articles get wrong is where they spend their words. They spend them on prevention and close with one line about backups. Prevention is worth doing and is not the subject here. The subject is the assumption that survives after prevention fails, because that assumption is the difference between a bad week and a dead company.
Quick context: what the 2026 numbers actually say
Sophos published its seventh annual ransomware survey in 2026, based on interviews with 2,158 IT and cybersecurity decision makers across 17 countries, in organisations of 100 to 5,000 employees, run by Vanson Bourne in Q1 2026. Two findings belong together. Attacks got better at encrypting: 56 percent succeeded, up from 50 percent. Recovery also got better: backup-based recovery was used in 66 percent of encrypted-data cases, up 12 percentage points, and 55 percent of organisations recovered within a week. Average recovery cost still landed at 1.7 million dollars per incident, up 11 percent year over year (Sophos, State of Ransomware 2026).
The other 2026 finding shapes the whole design: 79 percent of attacks originate from compromised identities, with malicious email at 26 percent and phishing at 24 percent of root causes (Sophos press release, July 2026). If most incidents start with someone else holding valid credentials, then a backup protected only by permissions is protected only until those permissions belong to the attacker.
1. Your backup is a target, not a fallback
The clearest measurement is a dedicated Sophos study from March 2024 covering 2,974 ransomware-hit organisations. In 94 percent of cases the attackers attempted to compromise backups, and across all sectors 57 percent of those attempts succeeded (Sophos, The Impact of Compromised Backups on Ransomware Outcomes). Organisations whose backups were compromised were far more likely to have data encrypted, 85 percent against 52 percent, and faced a median ransom demand of 2.3 million dollars against 1 million dollars.
That last number explains attacker behaviour better than any threat report narrative. Your backup is not a technical inconvenience, it is the single input to your negotiating position. An intact, restorable backup is the reason you can say no, so destroying it is worth real money to them.
The design consequence is that a backup you can delete is a backup an attacker can delete: with your credentials, through your console, using the same API call your cleanup script uses. Everything below removes that capability from the system, including from yourself.
Takeaway: evaluate backups by who is capable of destroying the result, not by whether the job succeeds.
2. Immutable means the delete cannot be authorised, not that the data is hidden
Immutability is usually explained as a storage feature. It is more useful as an authorisation feature: no principal in the system, however privileged, can issue a delete the platform will honour before a date you set in advance.
Amazon states this plainly for S3 Object Lock. In compliance mode, a protected object version cannot be overwritten or deleted by any user, including the root user of the AWS account, and the retention period cannot be shortened once set. The documentation names the only exit: the sole way to delete an object under compliance mode before its retention date expires is to delete the associated AWS account (AWS, Locking objects with Object Lock).
Governance mode is the softer variant. Users cannot delete or alter locked objects unless they hold the s3:BypassGovernanceRetention permission and send the x-amz-bypass-governance-retention:true header. AWS notes the S3 console includes that header by default, so a console user holding the permission simply succeeds at deleting. Governance mode is a fine place to rehearse retention settings. It is not the control you want between an attacker with admin and your last clean copy.
Takeaway: pick compliance mode for the copy you would restore from in a ransomware event, and use governance mode only while you are still tuning retention values.
3. S3 Object Lock: the three details that decide whether it works
Object Lock is easy to switch on and easy to misread. Three details do most of the damage.
Versioning is not optional. Object Lock works only in buckets with S3 Versioning enabled, and locks apply to individual object versions rather than object names. That is the mechanism, not a footnote. A later upload under the same key creates a new version with its own settings, while the older protected version stays locked.
Delete markers still appear. AWS is explicit that retention periods and legal holds do not prevent new versions from being created, nor delete markers from being added on top of the object. A permanent delete naming a version ID returns 403. A simple delete with no version ID returns 200 OK and inserts a delete marker that becomes the current version. Your data is intact underneath, but anyone reading a bucket listing mid-incident will think it is gone. Practitioner opinion: this is the most common reason a team believes Object Lock failed when it worked as documented, so write the version-aware restore command into your runbook now.
Retention only moves forward. A retain-until date can be extended by anyone with s3:PutObjectRetention, never shortened. Bound what your automation may set using the s3:object-lock-remaining-retention-days condition key in the bucket policy, the guard rail that stops a buggy pipeline locking a petabyte for ten years. Legal holds are the other tool: same protection, no expiry, removable by anyone holding s3:PutObjectLegalHold, which makes them a workflow control rather than an anti-ransomware one.
Takeaway: enable versioning, set a default bucket retention in compliance mode, bound it with the retention-days condition key, rehearse a version-aware restore.
4. AWS Backup Vault Lock and the logically air-gapped vault
Object Lock protects objects in a bucket. Most of what a startup needs to recover is not in a bucket: it is RDS, EBS, DynamoDB, EFS. For those the equivalent control is AWS Backup Vault Lock, which applies WORM semantics to recovery points in a backup vault. In compliance mode, once the lock takes effect it cannot be changed or deleted by any user, by your account administrators, or by AWS (AWS Backup Vault Lock documentation).
One design detail is worth planning around: the cooling-off period. AWS enforces a minimum 72-hour grace window before a compliance-mode lock becomes immutable, expressed as ChangeableForDays, which must be 3 or greater. During the grace period you can still remove the lock or change its configuration. After it expires, you cannot. Practitioner opinion: treat those 72 hours as your only chance to catch a retention number you will regret, so make the review a scheduled task with an owner.
The newer piece is the logically air-gapped vault, which stores immutable backup copies locked by default and encrypted with AWS owned keys, shareable with other accounts including across organisations via AWS Resource Access Manager, for direct restore without first copying data into the destination account (AWS Storage Blog). That is the shape of a real recovery, where the destination account is new because the old one is evidence.
Takeaway: put database and volume recovery points in a locked vault, and confirm ChangeableForDays before the grace window closes.
5. The same control on GCP and Azure
The pattern transfers, with different names and slightly different edges. On Google Cloud, a bucket retention policy prevents objects from being deleted or replaced for the retention duration, and the policy itself can be locked so it cannot be removed or shortened. Object holds sit alongside it and protect individual objects independent of any bucket-level policy (Google Cloud, Bucket Lock).
On Azure, immutable storage for Blob Storage provides WORM through two policy types, time-based retention and legal hold, applied at container or version scope. A locked time-based policy can be extended up to five times but never shortened, and once locked it cannot be deleted. Microsoft documents locked policies as compliant with SEC 17a-4(f) and comparable regimes (Microsoft Learn, Immutable storage for blob data).
If you sell into regulated buyers, that framing is not decoration. AWS notes S3 Object Lock has been assessed by Cohasset Associates for environments subject to SEC 17a-4, CFTC and FINRA rules, and in a vendor security review a named control with a documented mode beats a paragraph of prose.
Takeaway: whichever cloud you are on, the control exists and is free to enable, so the only real decision is the retention window.
6. The real blast radius is identity, not storage
Immutability stops deletion. It does not stop an attacker holding your identity from changing future backup policy so new copies stop arriving, deleting the key material the copies depend on, or waiting out a short retention window. Given that 79 percent of 2026 attacks started from compromised identities, the identity boundary around the backup deserves as much attention as the lock.
The structural fix for a small team is account separation, and it is cheaper than it sounds. Put the immutable copy in a separate AWS account, GCP project or Azure subscription whose only purpose is holding backups. The production role writes into it and can never delete from it. No human holds standing admin there. Access is broken glass: a separate identity, a separate MFA device, ideally a separate identity provider, used only during a recovery. Practitioner opinion: if the same SSO login that manages production can also administer the backup account, you have one boundary, not two, and one phished session ends both.
Two more controls cost almost nothing. Use organisation-level guard rails, AWS service control policies or the GCP and Azure equivalents, to deny delete and policy-modification APIs on the backup account outright, so the permission does not exist to steal. And keep the encryption keys under separate control, because a copy you cannot decrypt is a copy you do not have.
Takeaway: a separate account with no standing human admin turns one compromised session into a contained incident.
7. What immutability does not protect you from
Being honest about the limits is what makes the control trustworthy. Four failure modes survive a perfect Object Lock configuration.
Corruption you copied in. Immutability preserves whatever it was given. If ransomware sat in your environment for three weeks before detonating, some locked copies are faithful, undeletable snapshots of already-encrypted data. That is the argument for retention measured against dwell time, not convenience.
Exfiltration extortion. A growing share of pressure comes from publishing stolen data rather than withholding it. A flawless restore fixes availability and does nothing about a leak. Backups are an availability control, and saying so plainly beats implying otherwise.
Storage you now have to pay for. Locked objects cannot be deleted early, including by your own cleanup script. Lock the wrong prefix with a five-year retention and that spend is committed. Practitioner opinion: this is where governance mode earns its place, as a rehearsal before you commit to compliance mode.
Restores you have never run. An immutable copy nobody can restore within your tolerable downtime is a compliance artefact, not a recovery capability. That is the next section.
Takeaway: name these four limits in your own runbook, because a control whose edges you cannot state is a control you are trusting rather than using.
8. Choosing the retention window, and paying for it
Retention is the one number here you cannot copy from a blog post, including this one. Two things set it: how long an intruder might plausibly sit in your environment before acting, and how long it might take you to notice. If your locked copies go back 14 days and the intrusion started 30 days ago, immutability preserved nothing useful.
The practical approach is tiered rather than uniform: a short, dense band of recovery points for ordinary failures like a dropped table, and a longer, sparser band for the ransomware case. Daily for a few weeks, weekly for a few months, monthly for a year is a common shape, and it costs a fraction of locking everything for the longest window.
The cost conversation follows. Because locked data cannot be expired early, backup storage becomes a committed line item rather than a variable one, so model it first: size per tier, times storage class price, times retention months. Practitioner opinion: for most pre-seed teams that number is small enough to be uninteresting, and computing it beforehand prevents the panicked, and now impossible, cleanup later. Backups also only cover what you told them to cover, so buckets, database snapshots, secrets and configuration state each need an explicit answer, even if the answer is that they are reproducible from code.
Takeaway: derive the long retention window from your realistic detection time, then tier the shorter windows so the bill stays proportionate.
9. The restore drill: the only test that can fail for the right reason
A green backup job proves data was written. It cannot fail for the reason you care about, which is whether you can get your product running again from that data. Only a restore can fail for that reason, which is why CISA, the FBI, the NSA and MS-ISAC put regular testing of backup and restore procedures directly in the #StopRansomware Guide, alongside maintaining offline, encrypted backups. NIST makes the same point in SP 800-184, Guide for Cybersecurity Event Recovery: recovery is a capability to be exercised, not a document to be written.
A drill that proves something has five properties. It restores into a clean environment, a fresh account or project, not the one that already works. It uses only the broken-glass credentials, so you find a missing MFA device now instead of on the day. It is timed end to end, from decision to working service, and that number is compared against what the business can tolerate. It verifies application-level correctness rather than the presence of files: the service starts, migrations apply, a real query returns a real row. And it names the gaps it uncovered, which are the actual output of the exercise.
Quarterly is a reasonable default for a small team, plus a shorter drill whenever the data model or infrastructure changes materially. Practitioner opinion: the highest-value hour is the first drill, because that is where you find the undocumented dependency, the credential nobody rotated, and the assumption that the database restores in minutes when it restores in hours.
Takeaway: schedule one timed restore into a clean account this quarter and treat the elapsed time, not success or failure, as the finding.
Summary: the controls and what each one actually buys
| Control | Where it lives | What it prevents | What it does not prevent |
|---|
| S3 Versioning | Bucket | Overwrite hiding the previous state | Version deletion by a privileged principal |
| Object Lock, governance | Object version | Deletion without bypass permission | Deletion by anyone holding that permission |
| Object Lock, compliance | Object version | Deletion by any principal including root | Early cleanup, so the cost is committed |
| Backup Vault Lock, compliance | Backup vault | Recovery point deletion by admins or AWS | Config changes in the 72-hour grace period |
| Logically air-gapped vault | Vault shared via RAM | Loss tied to the compromised account | Compromise of the restoring identity |
| Separate backup account | Organisation | One stolen session reaching prod and backups | Anything, if one SSO administers both |
| Timed restore drill | Process | Learning your recovery time mid-incident | The incident itself |
What to do at your stage
Pre-seed, one to five engineers, no dedicated ops. Two things this month. Enable versioning plus Object Lock in compliance mode on the bucket holding your database dumps, with a retention window longer than your realistic detection time. Then run one restore into a fresh account and write down how long it took. If the separate-account step would stall you, book it as next, not as a gap you are ignoring.
Seed, five to twenty engineers, first compliance conversations. Add the separate backup account with no standing human admin, move managed database recovery points into a locked vault, and put the drill on the calendar quarterly with a named owner. This is also where the control starts paying for itself in vendor security reviews.
Series A and beyond, or regulated buyers. Formalise it: recovery time and recovery point objectives agreed with the business, deny-by-default organisation policies on the backup account, separate key control, drill results kept as evidence. If your buyers fall under SEC 17a-4, CFTC or FINRA style retention rules, the Cohasset assessment of Object Lock and the Azure locked-policy documentation are artefacts their auditors already recognise.
If you want a second pair of eyes on where your backups sit today, who can delete them, and how long a restore would actually take, that is what a short outside review is good at. MatrixGard runs a free cloud posture check covering backup immutability, identity blast radius and recovery gaps, and returns a written report. Start it from the cloud security checklist on the homepage.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice that acts as the cloud, infrastructure and security team for pre-seed and seed startups across India, Singapore, the UAE, the US and the UK. He works on cloud cost, platform stability and security posture for teams too small for a dedicated platform hire and too exposed to keep postponing one.
Methodology note
Every quantitative claim here comes from a named public source, linked inline: the Sophos State of Ransomware 2026 survey of 2,158 IT and cybersecurity leaders across 17 countries, run by Vanson Bourne in Q1 2026; the Sophos March 2024 study of 2,974 ransomware-affected organisations on backup compromise; and official AWS, Google Cloud and Microsoft documentation. Recovery-testing guidance comes from the CISA, FBI, NSA and MS-ISAC #StopRansomware Guide and NIST SP 800-184. Statements reflecting judgement rather than published data are labelled practitioner opinion inline. No client engagements, customer outcomes or private incident data appear anywhere in this post, and no figures have been estimated or invented.
