StealthTech
Every defense contractor we’ve onboarded in the past two years has had a backup solution before they called us. Most of them also had ransomware attackers who found and deleted those backups before encrypting production data. That’s not a coincidence it’s the current playbook. Modern ransomware operators don’t just lock your files anymore; they spend days or weeks inside your network first, mapping out where your backups live, harvesting domain admin credentials, and specifically targeting backup repositories and Volume Shadow Copies before they ever trigger the encryption payload. If your backup can be deleted, modified, or encrypted by someone holding the same credentials your IT admin uses, it isn’t a backup. It’s a second copy of the problem.
For companies handling Controlled Unclassified Information under a DoD contract, this isn’t an abstract risk exercise. A ransomware event that destroys your only recovery path is also a security incident that triggers reporting obligations under DFARS 252.204-7012, a potential CUI exposure, and depending on how long you’re down a contract performance failure. That combination is why immutable backups have moved from “nice to have” to a baseline expectation in nearly every serious cybersecurity assessment we run for clients preparing for compliance reviews.
What “Immutable” Actually Means
Immutability gets thrown around loosely in vendor marketing, so it’s worth being precise. An immutable backup is a copy of your data that cannot be altered, encrypted, or deleted not by a user, not by an administrator, not by a piece of malware running with domain admin privileges, and not even by the backup software itself for a defined retention period. The lock is enforced at the storage layer, typically through a mechanism like S3 Object Lock in compliance mode, or a purpose-built appliance with a hardened, immutable file system.
That last distinction matters more than most people realize. A “backup” sitting on a network share with delete permissions restricted to one admin account is not immutable it’s access-controlled, which is a meaningfully weaker guarantee. If that admin account is compromised (and in nearly every ransomware case we’ve investigated, an admin account was compromised), access controls evaporate. True immutability doesn’t rely on credentials being uncompromised. It relies on the storage system physically refusing the delete or overwrite command regardless of who is issuing it, until the retention clock expires.
Why CMMC and NIST 800-171 Are Pushing Immutability Into Scope
Neither CMMC nor NIST SP 800-171 uses the word “immutable” in a standalone control. What they do require, across the Contingency Planning and System and Information Integrity families, is the capacity to recover CUI-bearing systems within organizationally defined timeframes following a disruption, and to maintain the integrity of that recovery capability. An assessor evaluating your System Security Plan is going to ask a very direct question: if your production environment is fully encrypted tomorrow morning, what evidence do you have that your recovery data wasn’t encrypted along with it?
“We have backups” is not an acceptable answer anymore, and increasingly it’s not one that satisfies cyber insurance underwriters either. We’ve watched policy renewals get denied or premiums triple because a carrier’s questionnaire specifically asked whether backup repositories are network-accessible from the same domain as production systems. The direction of travel across CMMC requirements and the broader threat landscape described by CISA’s guidance on nation-state cyber actors both point the same way: recovery infrastructure has to be treated as an asset that’s actively targeted, not a passive insurance policy sitting quietly in the background.
We cover the broader compliance mapping in more detail on our compliance page, but the short version for a business owner is this: immutability isn’t a checkbox you add to satisfy an assessor. It’s the difference between a ransomware event costing you a bad week and costing you the business.
Air-Gapped vs. Immutable: They’re Not the Same Thing
I still hear these terms used interchangeably, and the confusion causes real gaps in recovery planning. An air-gapped backup is physically or logically disconnected from your network think of a tape sitting in a vault, or a drive that’s rotated offline. It’s protected because nothing on your network can reach it at all. An immutable backup, by contrast, can remain connected and even actively replicating, but the data itself is write-once, and read-many until the retention window closes.
Each approach solves a different problem. Air-gapping protects against network-based attacks reaching the media, but it introduces recovery point gaps if your tape was pulled yesterday, you lose today’s changes. Immutability protects continuously-replicated data from tampering even while connected, which shrinks your recovery point objective dramatically, but it depends entirely on the storage vendor’s implementation actually enforcing the lock at the hardware or object level rather than just flagging files as “protected” in software. The strongest architectures we build for backup and data recovery clients combine both: immutable, frequently-replicated primary backups for fast recovery, plus a periodic air-gapped or logically isolated copy for the scenario where an attacker somehow finds a way around the immutability lock itself, which while rare is not theoretical.
Where Immutable Backups Fit in Your Recovery Architecture
Immutability by itself doesn’t make you resilient. It’s one control in a chain, and the chain breaks if any other link is weak. We generally walk clients through four questions before we touch backup configuration at all: What’s your actual recovery time objective for each system tier, not the aspirational one? Where does the backup data physically live relative to production? Who or what service account has the technical ability to modify retention settings? And has anyone actually tested a full restore in the last twelve months, not just verified that a backup job completed successfully?
That last question trips up more contractors than any other. A green checkmark on a backup dashboard tells you the job ran. It tells you nothing about whether the resulting data is actually restorable, uncorrupted, and complete. We’ve walked into environments where “successful” backups had been silently failing to capture application-consistent snapshots of a SQL database for months the job showed green because the file copy succeeded, but the database itself would have been unusable on restore. Immutable data that can’t be restored cleanly is exactly as useless as mutable data that got encrypted. This is part of why we treat managed IT services engagements as incomplete unless recovery testing is built into the ongoing schedule, not treated as a one-time setup task.
The 3-2-1-1-0 Rule, Updated for Ransomware Reality
The old 3-2-1 backup rule three copies of your data, on two different media types, with one copy offsite was written for a world where the main threats were hardware failure and natural disaster. It wasn’t written with an adversary in mind who actively hunts for and destroys backup infrastructure as step one of an attack. The updated version we use with clients, 3-2-1-1-0, adds two conditions that matter specifically for ransomware resilience:
- One copy must be immutable or air-gapped, meaning it cannot be altered by anything on your production network, including a compromised domain administrator account
- Zero errors on recovery verification, meaning every backup set is periodically test-restored and confirmed usable, not just confirmed as “completed” in a job log
The zero-errors piece is the one organizations skip most often because it takes actual staff time rather than just storage budget. It’s also the piece that determines whether your recovery plan works when you need it or turns into a multi-day scramble discovering that half your restore points are corrupted. For companies without dedicated infrastructure staff to run this verification cycle themselves, a co-managed IT arrangement lets an internal team keep day-to-day control while offloading the recurring discipline of restore testing to a partner who does it across dozens of environments and has seen where it typically fails.
Object Lock, WORM, and the Technical Mechanics
For the technically-minded reader who wants to know what’s actually happening under the hood, immutability is generally implemented one of a few ways, and it’s worth understanding the differences before you sign a contract with a backup vendor claiming “immutable” storage:
- S3 Object Lock (compliance mode), used by most major cloud backup targets, where AWS’s own infrastructure enforces that an object cannot be deleted or overwritten until a specified retention date, and critically compliance mode prevents even the AWS root account from shortening that retention
- WORM (Write Once, Read Many) storage on purpose-built backup appliances, where the immutability is enforced at the firmware level of the appliance itself rather than in a software layer that a sufficiently privileged attacker could theoretically disable
- Blockchain-style hash-chaining used by some newer backup platforms to detect tampering after the fact, which is useful for integrity verification but is a fundamentally different guarantee than preventing the tampering from happening in the first place
The distinction between “governance mode” and “compliance mode” on object storage locks trips up a lot of buyers. Governance mode can be overridden by an account holding specific IAM permissions which means a sufficiently compromised cloud account can still delete “immutable” data locked in governance mode. Compliance mode cannot be overridden by anyone, including your own cloud provider, until the retention period expires. If a vendor can’t tell you clearly which mode their platform defaults to, that’s a disqualifying answer, not a follow-up question.
What Happens During an Actual Restore
Knowing your backups are immutable is only half the picture the other half is knowing how long it actually takes to get a business back online from them, and what that process looks like under pressure. Restoring from immutable cloud storage after a full ransomware event typically means standing up clean infrastructure first, since you can’t trust that any surviving on-premises hardware is free of the malware’s persistence mechanisms. That means your recovery time depends as much on how quickly you can provision clean compute and networking as it does on how fast the data itself can be pulled down.
This is where a lot of recovery plans quietly fall apart. We’ve seen organizations with genuinely solid immutable backups discover, mid-incident, that restoring forty terabytes of data over their office internet connection was going to take nine days a timeline that turns a contained incident into a business-ending one. Planning for this means thinking through bandwidth, staging environments, and priority order for which systems come back first (usually domain controllers, then core line-of-business applications, then everything else) well before an incident happens. Organizations moving toward hybrid or cloud-native infrastructure through a cloud transformation engagement generally have a real advantage here, since spinning up parallel clean infrastructure in the same cloud where the immutable backup already lives is dramatically faster than rebuilding from bare metal on-premises.
Common Mistakes That Undermine Immutability
The single most common failure we see isn’t a technology gap it’s a scope gap. A company implements immutable backups for their file server and their primary database, feels appropriately protected, and never extends the same protection to their Microsoft 365 tenant, their VoIP call recordings, or the configuration backups for their network firewalls. Ransomware operators don’t limit themselves to file shares, and neither should your recovery plan. If your organization runs cloud-based VoIP, those call logs and voicemail records often carry compliance obligations of their own and deserve the same immutability treatment as everything else.
The second common mistake is treating immutability as a substitute for identity security rather than a complement to it. Immutable backups don’t stop an attacker from encrypting production, disabling accounts, or exfiltrating CUI before encryption even begins they only guarantee you have something clean to restore from afterward. We’ve written elsewhere about how MFA fatigue attacks and weak authentication remain the most common initial access vector, and about the shift toward passkeys as a stronger alternative to passwords. Immutable recovery and strong identity controls solve different halves of the same problem, and skipping either one leaves the business exposed.
The third mistake, and the one that’s hardest to catch without an outside review, is retention periods set too short relative to attacker dwell time. If your immutability lock is set for fourteen days but the attacker was inside your network for six weeks before triggering encryption, your “clean” backups may already contain the same backdoor that caused the original breach. Retention windows for CUI-handling environments should generally be set with a wide enough margin to survive the median dwell times reported in current threat intelligence, which is one of the calibration decisions worth reviewing with a vCIO rather than leaving to default vendor settings.
Building This Into a Broader Recovery and Compliance Strategy
None of this exists in isolation from the rest of your security posture. An immutable backup strategy sits inside a larger cybersecurity program that should also address endpoint detection, network segmentation, and the kind of continuous monitoring that catches an attacker during the dwell-time phase, before they ever reach your backup infrastructure. CISA’s cybersecurity resources are a useful public baseline here, particularly for organizations still building out a formal incident response plan alongside their backup architecture.
Industry context matters too. A manufacturing client running OT and IT on a converged network faces a different recovery sequencing problem than a legal or healthcare practice whose primary exposure is client record confidentiality, and we’ve covered some of those industry-specific considerations directly, including how cybersecurity requirements intersect with bar association standards for law firms. For engineering firms and machine shops handling CUI under active DoD contracts, we’ve also broken down how often different data types actually need to be backed up by industry, which is a useful companion piece to this one since backup frequency and immutability retention need to be designed together, not separately.
If you’re weighing whether to build this internally or bring in outside help, it’s worth reading through the tradeoffs we outlined in co-managed IT versus fully outsourced IT immutable backup architecture is exactly the kind of specialized, infrequently-touched infrastructure where an outside partner’s pattern recognition across many environments tends to catch gaps that an internal team, however capable, simply hasn’t had the reps to notice yet.
Conclusion
Ransomware operators have adapted their tactics specifically to defeat conventional backups, which means a backup strategy that hasn’t adapted in response is already behind. Immutability, properly implemented in compliance mode with realistic retention windows and genuinely tested restore procedures, is the control that keeps a ransomware incident from becoming an extinction event for a defense contractor carrying CUI and contractual recovery obligations. It’s not a product you buy once it’s an architecture decision that touches your cloud storage configuration, your identity controls, your restore testing cadence, and your incident response plan, and it needs to be reviewed as attacker dwell times and techniques continue to shift.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
