On July 16, Coca-Cola filed an 8-K telling the SEC that ransomware had reached production systems at Fairlife, its ultra-filtered dairy brand. The company activated its incident response and business continuity protocols the same day it detected the intrusion. All four US plants stopped anyway.
Most of that Fairlife production stayed offline until July 27.
Shoppers barely noticed, because Fairlife had finished cases sitting in distribution centers, and the shelves stayed full while engineers worked through the rebuild. What saved the company for eleven days was inventory.
But that was Coca-Cola. A 30-person operation in Chandler doesn’t get that cushion. Your backup answers one question: does a copy of the file exist. Whether you can run operations undisrupted is a separate question.
Backup, recovery, and continuity are three separate promises
Most owners use those words interchangeably. Your vendor doesn’t, and neither does NIST.
Backup is storage. It proves a copy exists. Disaster recovery is the work of turning that copy back into functioning systems, which takes a lot of time, and costs start compounding. Disaster recovery services for a small business get measured by that small window.
But business continuity asks something else entirely: can you keep serving customers during the stretch in between?
The NIST Cybersecurity Framework 2.0 treats recovery as its own function, with outcomes you’re expected to plan for rather than improvise. That structure exists because surviving an incident and resuming operations aren’t the same for organizations.
The two numbers nobody wrote down
Recovery is measurable, and two numbers do all the work.
- Your recovery time objective (RTO) is how long the business can run without a system before the damage compounds.
- Recovery point objective (RPO) is how much recent work you can afford to lose.
Picture a Gilbert dental practice backing up nightly at 11 p.m. That’s an eight-hour RPO during clinic hours, so a failure in the afternoon erases every chart note and payment posted since the night before. Nobody chose that. It arrived with the backup schedule.
A new report on data resilience found the same pattern across 900 senior IT and risk leaders. 90% said they were confident they could recover inside their RTOs, while only 69% said those RTOs actually lined up with their business continuity goals.
If you’ve never written these numbers down, you still have them. Chances are, your vendor’s defaults picked them for you.
Your restore time is a guess until somebody times it
A completed backup job proves the copy was written. But it says nothing about how long that copy needs to turn into a working environment.
The order of operations is where most restores slow down. Your file server can’t authenticate anyone until identity comes back first, and applications can’t find each other until DNS is correct.
NIST’s revised incident response guidance, SP 800-61r3, tells organizations to document procedures for the processes urgently needed during an emergency. What we typically see is that teams discover mid-crisis that nobody wrote down what comes back first.
Throughput is the other surprise. Pulling 4 terabytes down a Tempe business fiber line takes as long as it takes, whatever the contract promised, which is why backup cloud capacity changes the equation.
Think of this as an example: you have a spare tire in the trunk, but you’ve never timed changing it on the shoulder of the I-10 in August.
So, how often should backups be tested? Quarterly, and again after any major change to your environment. A real test restores a critical system to a working state while somebody stands there with a stopwatch. That number goes next to your RTO, and if the two don’t agree, you’ve found the problem before it found you.
What sits outside the restore
Both RTO and RPO assume the things you need were backed up in the first place. Often it isn’t the case. Here are the things you need to look out for:
- Settings, not files. License keys, firewall rules, and the config someone spent days tuning.
- Backup credentials that also reach production. We covered where that leads when an AI agent wiped a company’s database and took the backups with it.
- The line-of-business application nobody wrote down. Practice management software, or the estimating tool your project manager swears by.
- Microsoft 365 runs on a shared responsibility model. Microsoft keeps the service available, but your mail and files are yours to protect.
Veeam found that among organizations hit by ransomware, only 28% recovered all their affected data, and 44% got back less than 75%.
The hourly average hides your worst week
You’ve probably seen an average hourly cost of downtime quoted somewhere. Treat that figure as a floor.
Three days offline in February costs a Scottsdale CPA firm something very different than three days in June. Same for a retailer running through snowbird season, or a logistics operation during peak I-10 freight.
An average doesn’t give you the full picture of what a bad week costs you. We broke the numbers down in our piece on what IT downtime costs per hour.
Business continuity planning for Arizona SMBs
Owners skip this part because “business continuity plan” sounds like something requiring a compliance officer. At your size, it’s just a short document.
- Start by naming the processes that must survive the first 24 hours. Payroll, order intake, patient scheduling, whatever stops your revenue when it stops. Write the target beside each system so the number becomes a business decision instead of a vendor default.
- Then add one manual workaround for your top revenue process. Paper intake forms, or a phone script, and a shared spreadsheet. It won’t be elegant. That’s fine.
- Last comes the part almost everyone forgets, which is telling people. CSF 2.0 treats recovery communications as its own outcome, because customers and staff need to know what’s happening while you rebuild. Keep that contact list somewhere outside the email system that’s currently down.
Where MyTek fits in your backup and recovery process
None of what we’ve discussed requires an in-house security team. You need someone to manage it beyond the setup week.
That’s the work MyTek does for Arizona businesses. Our managed backup and disaster recovery covers the whole chain: we set recovery targets against what your operation can survive, run restore tests on a schedule instead of during an emergency, separate backup credentials from production access, and keep the plan current as your environment changes.
All of it folds into the same managed IT and cybersecurity coverage watching the rest of your stack.
Your backup is doing its job. Nobody has checked whether the rest of the plan is working. Schedule a business continuity assessment with MyTek, and we’ll find out how long your recovery actually takes.