RPO by Department: Accounting Can Lose an Hour, Sales Can Lose a Day

The server dies at two o’clock on a Thursday afternoon. Not a dramatic fire, just a controller board that quietly gave up. Your IT provider does exactly what they should. They spin up the most recent backup, which ran at eleven the night before, and by five thirty everybody is back at their desks. Crisis handled. Everybody goes home tired and mostly relieved.

Friday morning your bookkeeper walks in looking pale. She entered about forty vendor invoices Thursday morning. They are gone, not corrupted, just never in the backup, because the backup was from Wednesday night. Here is the part that ruins the weekend. She cannot tell you which forty. There is no list, only a pile of paper that may or may not be complete and a memory of a busy morning. The recovery worked perfectly and you still lost something you cannot get back.

Two numbers, in plain English

Two measurements in disaster recovery matter to owners, and they answer completely different questions.

Recovery point objective, or RPO, is how much work you can afford to lose. The National Institute of Standards and Technology, the federal agency that publishes security standards and is usually shortened to NIST, defines it in Special Publication 800-34 as the point in time to which data must be recovered after an outage. In plain terms, if your RPO is one hour, losing up to an hour of work is survivable and losing more is not.
Recovery time objective, or RTO, is how long you can afford to be down. NIST defines it in the same publication as how long systems can be in recovery before it hurts the business. RPO looks backward at lost work. RTO looks forward at lost hours.

Most small businesses have thought about RTO at least loosely, because downtime is visible and everybody feels it. Almost nobody has set an RPO, which is why the bookkeeper conversation goes the way it does. The number existed the whole time. Nobody chose it. The backup schedule chose it for you.

Why one number for the whole company is the wrong answer

When people do sit down to set an RPO, they pick one number for everything. That lands you in one of two bad places.

Pick a tight number for everything, say fifteen minutes, and you are protecting a marketing folder of old logo files at the same standard as your accounting system. Continuous protection costs real money in storage, bandwidth, and licensing, and you are spending it on data nobody would miss.

Pick a loose number, once a night, because that is what most backup systems do out of the box, and you have quietly decided a full day of financial entry is acceptable to lose. You never decided that. You just never questioned the default.

The right question is not how much data your company can lose. It is how much each kind of work can lose, and the honest answer varies enormously between departments in the same twelve person office.

Setting the number department by department

The useful test is not how important the work is. Everybody thinks their work is important. The test is how hard it would be to recreate from memory and paper. Data that exists nowhere else needs a tight RPO. Data duplicated in somebody’s inbox or somebody’s head can stand a loose one.

Accounting and payroll, measured in minutes. The tightest requirement in most small businesses, and not because of importance. Every entry is unique and unreconstructable. Nobody remembers the check numbers or can rebuild a morning of invoice coding from memory. An hour is a reasonable target, and tighter on payroll processing day.
Your main operational system, minutes to an hour. Whatever runs the actual business. The dispatch board, the practice management system, the point of sale, the job costing package. If it captures things that happened in the physical world and were never written down elsewhere, treat it like accounting.
Sales and customer records, a day is usually fine. This surprises people, but salespeople carry their own week in their head and in their sent mail. Losing a day of call notes is annoying and recoverable. A real cost, not a catastrophe, and paying premium rates for it is usually the wrong trade.
Shared files and documents, a day for most teams. With one exception. If people produce large files all day, drawings, video, engineering models, design work, they can lose a full day of production that cannot be recreated by remembering harder. Those folders may deserve a tighter schedule even when the rest of the drive does not.
Email, close to zero, but verify it. Mail systems keep messages as they arrive, so the RPO is naturally near zero. The gap is deletion. Retention windows and recycle bins are finite, and the cloud is just someone else’s computer. Microsoft and Google protect you against their hardware failing, not against an employee deleting a folder in March that you need in September.
Human resources and archives, a week is often honest. Employee files, old contracts, historical records. This data matters enormously and changes almost never. Protecting it every fifteen minutes is paying to back up the same unchanged files over and over.

Measuring what you actually have today

Here is where most businesses get an unpleasant surprise. Backup frequency is not RPO. Your real RPO is the worst case gap, and several things stretch it.

Start with the actual schedule, per system. Not what the contract says. What the logs show ran last night, and the night before, for each system separately. Systems get added and never included.
Add the time before anybody notices. If a backup job has been silently failing for nine days, your RPO that day is nine days, no matter what the schedule says. Somebody has to be looking at the results, and that somebody needs to be a person, not an unread automated email.
Account for the ransomware version of the question. With hardware failure you restore from last night. With ransomware you restore from before the intruder got in, which may be days or weeks earlier. That is why keeping multiple restore points, and keeping at least one copy an attacker on your network cannot reach or delete, matters more than the nightly schedule.
Test a restore, not just a backup. A backup that has never been restored is a hypothesis. Pick one system a quarter and actually bring the data back somewhere safe. Every experienced IT person has a story about a backup that ran perfectly for two years and could not be restored.

Where to spend the money

Once the numbers are written down by department, the budget conversation gets easier, because you are no longer arguing about whether backup is important. You are matching a specific cost to a specific exposure.

Tightening the RPO on your accounting system from a day to an hour is usually a modest change to one system, not a rebuild of your whole environment. Tightening it everywhere is a much bigger bill for much less benefit. Spend the money where the data cannot be recreated, and accept a looser number everywhere else on purpose, with your eyes open.

One more thing for the same page. Recovery assumes power and internet, and in Denton County we get storms that take out both. Backup internet matters here, and satellite service like Starlink works well as failover because it skips local infrastructure entirely. Pair it with battery backup, called a UPS or uninterruptible power supply, so the equipment stays up long enough to use it.

The bottom line

You already have a recovery point objective. Your backup schedule set it for you, probably years ago, probably by default. The only question is whether you have looked at the number and agreed with it.

Take an hour, list your systems, and write next to each how much work you could genuinely afford to lose. Accounting an hour, sales a day, archives a week. Then compare that list to what your backups actually do. The gaps are the whole project, and it is usually smaller and cheaper than people expect.

If you want a hand running that comparison for your business in Lewisville, Flower Mound, Highland Village, Frisco, or anywhere across Denton County, we will tell you straight what your real numbers are today. Contact Harrison Ward Technology.

Sources

Backup and Recovery Business Continuity Explainers Small Business IT

Comments are closed