February 26, 2026

By Scott Kreisberg, Founder & CEO

Recovery Point Objective (RPO) is the maximum amount of data a business can afford to lose after a cyber attack, outage, or system failure. It is measured in time and determines how frequently backups must occur to limit operational and financial damage. For small and mid-sized businesses, defining RPO is a leadership decision, not just an IT responsibility. Prioritizing critical systems and regularly testing backups are essential steps toward building a secure and resilient digital business.

After four decades in technology and running a managed services company, I've learned that the most expensive lessons in business are the ones you learn the hard way. This article is my attempt to save you from one of those lessons.

 

The Phone Call That Changed How I Think About Backups

A few years ago, I got a call from a fellow business owner who ran a successful distribution company. His IT system had crashed on Tuesday afternoon, and his team was restoring backups.

Mike wasn't calling for technical help. He was calling because he'd just discovered his last backup was from midnight. It was now 3 PM. He'd lost almost 15 hours of orders, inventory updates, and customer communications.

"We're trying to piece together who ordered what from credit card receipts and emails," he said. "Do you have any idea how many orders we process in a day?"

The recovery cost him tens of thousands in lost productivity, overtime, and customer credits for delayed shipments. The worst part?

His IT person had been doing everything "by the book." They had backups running every night. Everyone thought they were protected.

They just didn't understand one critical question until it was too late.

 

What This Means (Without the Jargon)

I run a company that helps businesses with their technology, and I rely on smart people who know cybersecurity and disaster recovery best practices inside out.

Here's what I've learned: you don't need to be an expert to understand the questions that matter.

The tech people call it "Recovery Point Objective" or RPO. It sounds complicated, but it's asking a simple business question:

"How much work can we afford to lose if our systems go down?"

Think of it like this: If you save a document every two hours and your computer crashes, you lose at most two hours of work. Annoying but manageable.

Now imagine you're running a retail store during Black Friday, saving transaction data once a day. Your system crashes at 5 PM? You've lost every sale from that entire day. That's not annoying. That's devastating.

I hate that this has such a complicated name, because it keeps business owners from understanding something critical about their own business.

 

Two Different Problems You Need to Understand

When I talk to other business owners about IT disasters, they're often worried about the wrong thing. Or more accurately, one thing when they should worry about two:

Problem One: Your System is Down
Computers aren't working. Nobody can access anything. Work has stopped. Every hour costs you money. This is bad but usually fixable.

Problem Two: Your Data is Gone
Even after the system comes back up, your data is missing. Orders, inventory changes, and emails are gone. This is what Mike was dealing with.

His system came back up within hours (not great, but survivable). But 15 hours of business transactions had vanished.

Key insight: These are separate problems needing separate solutions.

You can be down for 4 hours, but only lose 30 minutes of data if you back up every 30 minutes. Or be down for 30 minutes, but lose 24 hours of data if you only back up daily.

 

How to Think About This as a Business Owner

Skip the technical presentations about "snapshots" and "replication." Here's the framework I use:

Ask: "What Would Happen If..."

For each important system, walk through this:

"If this system went down right now and we lost the last 24 hours of data, what would happen?"

Be specific:

  • Would we lose money we can't recover?

  • Would inventory counts be wrong?

  • Would we lose billable time for payroll?

  • Would clients lose work that takes days to redo?

  • Would we face compliance issues?

Then ask for 12 hours, 4 hours, 1 hour. When you start saying "painful but manageable," that's probably how often you need to back up that system.

Think in Dollars and Hours

"If we lost 4 hours of order data, it would cost us $X in revenue, plus $Y in staff time to reconstruct what we can, plus $Z in customer goodwill."

Once you think this way, conversations with IT get clearer. "Our order system generates $10,000/hour. We need to back up often enough to never lose more than $5,000 in orders."

  • Your IT team can work with that.

  • Don't treat all systems the same

  • Your product catalog changes weekly; daily backups are fine.

  • Your point-of-sale that captures transactions constantly needs frequent backups.

  • Your employee handbook hasn't changed in months—daily backup is overkill.

Treating everything the same can cause two problems. You may back up unneeded data too often. Or you may not back up critical systems often enough.

 

Real Examples from Companies Like Yours

The Medical Practice

A family practice lost a full day of appointments: who scheduled what, who canceled, who rescheduled. Patients showed up with no record. Others didn't show because they'd canceled, but the practice didn't know.

The lesson: Patient records don't change often (daily backups are fine). Scheduling changes constantly throughout the day (needs hourly backups). They were backing up everything once nightly because nobody had reconsidered it in five years.

 

The E-Commerce Company

They backed up their entire database every six hours. Sounds reasonable.

But their product catalog (massive, rarely changed) was being backed up constantly, while their order database (small, constantly updating) was only protected every six hours.

The lesson: We split it. Product catalog once daily. Orders every 15 minutes. Same cost, way better protection for what matters.

 

The Law Firm

Daily backups are running like clockwork. Very responsible. Until their server died and they discovered backups had been corrupted for three months. Nobody knew because backup software said "success" every night.

The lesson: Having a backup strategy isn't the same as having a working backup strategy. You must test it, and keep testing because things break over time.

 

What You Should Ask Your IT Team Today

The Essential Questions

1. "For each critical system, what's the longest period of data we could lose?"
If they say "last night's backup" and it's 3 PM, you're looking at potentially 15+ hours of data loss. Is that acceptable?

2. "When did we last test restoring from backups?"
If the answer is "never" or "I'm not sure," you have a problem. You don't know backups work until you've restored from them.

3. "Which systems are backed up most frequently, and why?"
Sometimes, backup frequency was set based on technical convenience rather than business need, or was set up years ago and never revisited.

4. "What would it cost to back up [critical system] every hour instead of every night?"
Sometimes it's "not much more," and it's a no-brainer. Sometimes it's expensive, and you need to weigh cost against risk. But you can't decide without knowing the number.

 

Common Mistakes I See

Assuming "Backed Up" Means "Protected"
Backups can fail silently, run successfully but not capture what you need, or work perfectly but take too long to restore to be useful.

Never Reviewing Strategy as Business Changes
When I started my company 40 years ago, we were five people with a local server. Daily backups made sense. Today, we're 40 people across three offices with clients depending on us 24/7. If I'd never updated our strategy, we'd be in serious trouble.

Treating Disasters as "IT Problems"
IT can fix technical problems, but only you can decide: Which systems to restore first? How much to spend on faster recovery? What's acceptable data loss? These are business decisions disguised as technical questions.

Not Testing Backups
Any competent professional tests. If your IT team says, "We don't need to test, I'm confident it works," that's your sign you need new IT support.

 

What You Need to Do This Week

Not a 47-step plan. Three things you can actually do:

1. Identify Your Three Most Critical Systems (30 Minutes)
List the three systems that would hurt most if they lost data. For each, write:

What data does it contain?

How often does that data change?

What would it cost if you lost a day's worth?

2. Ask Your IT Team the Key Questions (1 Hour)
Schedule an hour. Go through the questions above. Make it collaborative: "I've been thinking about protecting our business better, and I want to understand what we have in place."

3. Schedule a Backup Test (30 Minutes to Schedule)
Pick one non-critical system and ask IT to do a test restore. Time it. Document issues. This gives you real data about what recovery actually looks like.

If IT says, "We don't need to test," that's a red flag.

Quick Answers to Common Questions

"How do I know how much data loss is acceptable?"
If you lost 4 hours of data, would you lose unrecoverable money, have to redo expensive work, face compliance issues, or disappoint customers? If yes, 4 hours is too much. Keep shortening until you reach "painful but manageable."

"Isn't cloud backup good enough?"
Cloud is great, but you still decide how often to back up and what to back up. Cloud just means backups are stored offsite, not that they're stored frequently or that they're recoverable.

"What's a reasonable budget?"
Rough guideline: 3-5% of the overall IT budget. Less than 2%? Probably underprotected. More than 10%? Either you have special needs, or someone's overselling.

"How often should we test backups?"
Critical systems: quarterly (4x/year). Non-critical: twice yearly or annually. Once isn't enough—things change, configurations drift.

"We're small. Do we really need this?"
Yes. Actually, small businesses need this more. A Fortune 500 losing 12 hours of data is a problem. A small business might not recover at all. You don't have the cushion or resources to absorb major data loss.

"Can I outsource this to our IT vendor?"
You can outsource execution, not decisions. Only you can answer: "How much data loss is acceptable for my business?" That's a business decision, not technical.

 

Final Thoughts

I've been in the technology industry since the 1980s. We've come a long way, but one thing hasn't changed: Business owners need to think clearly about what matters and make sure technology supports those priorities.

I'm not a disaster recovery expert. What I am is someone who's been in business long enough to see what happens when owners do, or don't, take this seriously.

Businesses that survive disasters are the ones where someone thought through: "What would happen if we lost data? How much could we afford to lose? How do we make sure we can recover?"

It's not exciting or glamorous. It won't show up on quarterly results until the day it saves your business.

But the time you spend thinking about this now will be vastly less than the time spent cleaning up after a disaster you weren't prepared for.

Start with those three actions this week. Don't wait for the "right time" or more bandwidth.

The best time to prepare was five years ago. The second-best time is today. Click here to schedule your call with one of our IT and security experts.