StealthTech
A defense contractor in Sarasota once told us their backup job had been “running fine” for fourteen months. It had. Every night, right on schedule. What nobody had checked was whether the job was actually capturing the engineering drawings folder that had moved to a new share path eleven months earlier. The backup was healthy. The data behind it was not. That gap — between a backup that runs and a backup that protects what you actually need protected — is where most business data backup best practices conversations should start, and almost never do.
Backup frequency isn’t a single number you can look up and apply to every department. A finance team closing the books monthly has a different tolerance for data loss than a CAD engineer editing the same assembly file forty times before lunch. Getting the interval wrong in either direction costs money: too infrequent and you’re rebuilding hours of irreplaceable work after an incident; too aggressive and you’re burning storage, bandwidth, and administrative overhead on data that doesn’t change fast enough to justify it. This guide breaks the frequency question down by how different parts of a defense supply chain business actually generate and lose data, and it does so with the compliance obligations of DFARS 252.204-7012 sitting in the background the entire time, because for contractors handling Controlled Unclassified Information, backup frequency is not purely an operational decision. It’s a documented control.
Why “Once a Night” Stopped Being an Answer
For a long time, nightly backups were the default answer to nearly every business continuity question, and for a lot of static file-server data, they still work. The problem is that “nightly” was designed around an era when most business-critical data lived in a handful of file shares that changed slowly during business hours. That’s no longer how a modern defense contractor operates. Design files sync continuously to cloud storage. ERP transactions post in real time. Email and Teams messages containing CUI get generated hour by hour. A single nightly snapshot treats all of that as equally volatile, which means you’re either over-protecting slow-moving archival data or under-protecting the systems where an eight-hour data loss window is genuinely unacceptable.
The right question isn’t “how often should we back up,” stated as one interval. It’s “what is our acceptable data loss window for each system,” which in technical terms is your Recovery Point Objective, paired with “how fast do we need that system back,” your Recovery Time Objective. Once those two numbers exist for each critical system, the backup schedule writes itself. Skipping this step is why so many companies discover their actual RPO — the gap since the last good backup — only after a ransomware event, when it’s the worst possible time to learn it.
RPO and RTO: The Two Numbers That Should Drive Your Schedule
RPO answers a blunt question: if this system went down right now, how much work are you willing to lose? For a shared drive of policy documents that changes twice a month, an RPO of 24 hours is fine — nobody’s redoing a week of work. For an engineering PLM system where a machinist is actively cutting parts against a drawing revision, an RPO measured in hours, or even minutes, might be the only defensible answer, because the cost of re-deriving lost design changes exceeds the cost of more frequent, smaller backup jobs by a wide margin.
RTO is the companion number, and it’s just as often ignored. It’s not enough to have a recent backup if restoring it takes three days on a contract with a delivery penalty clause. A system with a tight RTO needs backup infrastructure built for fast recovery — image-level backups with instant virtual machine boot capability, replicated storage, or a documented failover path — not just files sitting in cold cloud storage that take a day to retrieve and rehydrate. This is precisely the kind of planning that belongs in a formal business continuity and disaster recovery strategy rather than something improvised during an incident, and it’s a conversation worth having with whoever owns your cybersecurity posture before an auditor or an incident forces the issue.
Setting RPO and RTO per system, rather than per company, is the single biggest shift that separates a mature backup program from a checkbox exercise. It also happens to be the foundation NIST expects contractors to build on. NIST SP 800-171 Revision 3 doesn’t dictate a specific backup interval, but its contingency planning and system integrity requirements assume you’ve done exactly this kind of impact analysis rather than applying one schedule uniformly across environments of very different criticality.
What CMMC and DFARS Actually Require — and What They Don’t
One of the more persistent myths we hear from prime contractors and subcontractors alike is that CMMC specifies a backup frequency. It doesn’t. What the framework requires, largely inherited from NIST SP 800-171’s contingency planning and media protection families, is that you maintain backups of organizational information, protect the confidentiality of that backed-up data — meaning CUI in a backup needs the same encryption and access controls as CUI in production — and periodically test your ability to restore. The frequency is left to you, because the framework is impact-based, not prescriptive, and your organization is expected to justify the interval based on data criticality and operational risk.
That flexibility is not a loophole. An assessor reviewing your System Security Plan is going to ask why your backup schedule looks the way it does, and “we’ve always done it this way” is not a defensible answer. What they want to see is a rationale tied to data sensitivity, system criticality, and demonstrated recovery testing — which is a very different conversation than simply pointing at a job scheduler and saying it runs every night. This is also where a lot of contractors underestimate scope: backup and recovery isn’t isolated to IT operations, it’s a compliance control with an audit trail, and treating it as a pure infrastructure decision is how gaps get discovered during an assessment instead of before one.
There’s a related wrinkle specific to defense work. If your backups contain CUI, the marking and handling expectations in the CUI Registry still apply to that data at rest in your backup repository, whether it’s sitting in an on-premises appliance or a cloud target. A backup strategy that satisfies restore-ability but ignores where CUI physically resides, who can access it, and how it’s encrypted has solved half the problem.
Engineering and CAD-Heavy Environments: Backup Frequency Measured in Hours, Not Days
If you’re running a shop with active PLM or PDM systems — SolidWorks, Siemens NX, Creo, or similar — nightly backups are frequently insufficient, and it has nothing to do with paranoia. A design engineer working through a change order can generate meaningful, non-reproducible work in a two-hour window. Losing that window doesn’t just cost the engineer’s time; it can cascade into a missed internal milestone that shows up as a late delivery to a prime.
The practical answer for these environments is continuous or near-continuous data protection for active project directories, supplemented by scheduled full backups for archival and completed-project data that no longer changes. This tiered approach — fast, frequent protection for hot data, slower and cheaper protection for cold data — keeps storage costs sane while matching the actual rate of change in each dataset. It also aligns naturally with how engineering firms in the defense supply chain already think about version control for design files; backup frequency should mirror that same logic rather than existing as a separate, disconnected process bolted on by IT.
Manufacturing Floors: The Data You’re Not Backing Up Is the Data That Stops Production
Manufacturing environments have a blind spot that rarely shows up in a generic backup policy: operational technology. MES systems, CNC program libraries, quality management records tied to AS9100 or ISO certifications, and even PLC configuration backups are often left out of the enterprise backup schedule entirely, because they sit on machines the IT team doesn’t touch day to day. When a controller fails or a machine’s local storage corrupts, the shop discovers that the program library backup was the operator’s personal USB drive, last updated when the machine was commissioned.
For manufacturing operations, the frequency question has to extend past the server room. CNC programs and quality records tied to active work orders need backup intervals that match production cadence — daily at minimum, and ideally after every significant program revision — while OT network configurations should be backed up any time a change is made, not on a calendar schedule. This is also where the supply chain risk emphasized in CISA’s guidance on critical infrastructure resilience becomes directly relevant: a ransomware event that halts production doesn’t just cost internal time, it puts downstream delivery commitments to a prime at risk, with contractual consequences that dwarf the cost of a properly scoped backup solution.
Finance, Legal, and Healthcare: When Retention Rules Drive the Schedule
Not every industry’s backup frequency question is about minimizing data loss during active work — for some, it’s about satisfying retention and discovery obligations that have nothing to do with RPO in the traditional sense. A finance department managing government contract billing needs backups frequent enough to protect daily transaction integrity, but it also needs long-term retention that satisfies both DCAA audit expectations and standard financial recordkeeping requirements — a different problem than protecting against accidental deletion.
Legal teams face a similar dynamic from a different angle: litigation holds and e-discovery obligations mean that “backup frequency” has to account for immutability and defensible retention, not just recoverability. A backup that can be deleted or overwritten before a hold period expires isn’t just an operational risk, it’s a legal one. And healthcare practices layered onto a defense contractor’s environment — occupational health clinics serving cleared personnel, for instance — carry HIPAA backup and retention requirements on top of whatever CUI protections already apply, meaning the same data set can be subject to two overlapping regulatory frameworks with different minimum retention windows.
The practical takeaway across all three: backup frequency for these industries is a two-part answer. How often you back up to protect against operational loss, and how long you retain those backups to satisfy retention law, are separate variables that get conflated far too often in generic backup policies.
Applying the 3-2-1-1-0 Framework to CUI Environments
The traditional 3-2-1 backup rule — three copies of your data, on two different media types, with one copy offsite — has evolved for organizations handling regulated or sensitive data, largely in response to ransomware that specifically targets backup infrastructure. The updated version, 3-2-1-1-0, adds two requirements worth walking through directly:
- Three copies of your data. Production data plus two backup copies, because a single backup copy is itself a single point of failure.
- Two different media or storage types. Disk-based backup paired with cloud replication, for example, so a failure mode affecting one storage technology doesn’t take out both copies simultaneously.
- One copy offsite. Physically or logically separated from your primary location, protecting against site-level events — fire, flood, or a regional outage affecting your Boston, Tampa, or Sarasota facility specifically.
- One copy immutable or air-gapped. This is the addition that matters most against modern ransomware, which actively hunts for and encrypts or deletes connected backup repositories before executing the primary attack. An immutable copy — write-once storage that cannot be altered or deleted even by an administrator account, for a defined retention period — assumes your production environment and your backup credentials may both be compromised at the same time.
- Zero errors, verified. A backup job that completes without confirmed, tested restorability is a backup in name only. This is the step most frequently skipped, and it’s the one that determines whether every other part of the framework actually matters when you need it.
For contractors storing CUI, that immutable copy isn’t optional hardening — it’s the practical answer to a threat model that CISA has been explicit about. Guidance on nation-state cyber actors targeting the defense industrial base consistently describes adversaries who understand backup infrastructure well enough to target it deliberately, which means a backup strategy designed around accidental deletion or hardware failure alone is designed for a threat that no longer represents your primary risk.
Testing Restores Is the Part Everyone Skips
There is a specific, recurring failure pattern in backup programs that have every other element right: encrypted, frequent, offsite, immutable — and never actually tested end to end. The backup software reports green across the board for months, sometimes years, right up until a real restore is attempted and something in the chain doesn’t work. Maybe the encryption key management has a gap. Maybe the restore process assumes access to infrastructure that no longer exists in its original form. Maybe the backup captured the database files but not the application configuration needed to make them usable.
A realistic testing cadence looks different depending on system criticality, but as a baseline: critical systems tied to production or active contract deliverables should have full restore tests quarterly, and every system should have at least an annual full-scale recovery exercise that simulates a genuine incident rather than a single-file restore from a file share. This is also where working with a vCIO pays off, because someone needs to own the discipline of scheduling these tests as a standing calendar item rather than a reactive task that only happens after a close call. Treating a backup as a completed project once it’s configured, rather than an ongoing operational commitment, is the single most common way well-designed backup strategies quietly stop protecting anything.
Regional Considerations for Boston, Tampa, and Sarasota Operations
Backup strategy isn’t purely a data-criticality question — physical geography factors in more than most IT plans account for. A Massachusetts operation in Boston faces winter storm-related power and connectivity disruptions that can affect both a primary site and a poorly chosen “offsite” backup location if that location sits in the same regional power grid or weather pattern. True geographic separation, not just a different building across town, is what the offsite requirement in 3-2-1-1-0 is meant to achieve.
Florida operations in Tampa and Sarasota carry a more acute version of the same issue with hurricane season, where the risk isn’t just data loss but extended physical inaccessibility to a primary facility for days or weeks. For these locations specifically, cloud-based backup targets with documented, tested cloud recovery paths matter more than they might for an inland operation, because the RTO conversation has to account for a scenario where nobody can physically reach the primary site to begin recovery. Contractors in these markets working through their broader managed IT services planning should treat regional disaster patterns as a direct input into backup architecture decisions, not an afterthought addressed after a storm has already caused damage.
Building a Frequency Schedule That Actually Holds Up to an Audit
Pulling this together into something you can defend to an assessor starts with an inventory: every system that stores or processes CUI or otherwise business-critical data, tagged with its RPO and RTO, its regulatory retention requirement if any, and its current backup interval. Gaps between the required RPO and the actual backup frequency should be closed first, not the systems that are already over-protected relative to their actual criticality — a surprisingly common misallocation of backup infrastructure budget.
From there, the schedule itself should reflect the tiers this guide has walked through: near-continuous protection for active engineering and production data, daily backups for transactional systems like ERP and financial platforms, and less frequent but longer-retention backups for archival and compliance-driven records. Layered against all of it, the immutable copy requirement and quarterly restore testing apply universally, regardless of how frequently a given system’s data changes. None of this needs to live in a company’s head — it belongs in the same documentation set referenced by your System Security Plan, alongside the broader AI integration and cloud transformation initiatives that are increasingly reshaping how contractors architect their environments in the first place, since new platforms and workloads change the data-criticality map every time they’re adopted.
Conclusion
Backup frequency isn’t a policy you set once and revisit during the next audit cycle. It’s a living reflection of how your business actually generates and depends on data, and that picture changes every time you adopt a new platform, win a new contract with different retention obligations, or shift more work into the cloud. The contractors who get this right treat their backup schedule the way they’d treat any other risk control tied to CMMC — documented, tested, and revisited on a real cadence rather than assumed to still be correct because nothing has broken yet.
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.
