IT Disaster Recovery Plan for Utah…

RTO and RPO: the two numbers that actually matter

The National Institute of Standards and Technology defines Recovery Time Objective (RTO) as the overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission or business processes. In plain terms: how long can this system be down before it actually hurts the business?

Recovery Point Objective (RPO) is the point in time to which data must be recovered after an outage. In plain terms: if the outage happened right now, how much of today's work are you willing to lose?

These numbers are not the same for every system. A file server might have an RTO of a few hours and an RPO of the previous night's backup. A practice management or point-of-sale system that the whole business depends on minute to minute needs a much tighter RTO and RPO. A disaster recovery plan assigns both numbers to each critical system deliberately, instead of discovering them by accident during an outage.

What "disaster" actually covers

For most Utah businesses, the realistic disaster scenarios are ransomware, a compromised or deleted cloud account, hardware failure, and a physical incident at the office (fire, flood, or a multi-day power or internet outage). Our ransomware response guide covers what to do during an active attack; this guide covers the planning that happens before one.

Regional seismic risk is also part of the planning conversation for any Wasatch Front business, not because it should drive daily decisions, but because it is the clearest reason a plan needs to survive the loss of the physical office, not just a server. The Utah Geological Survey's regional hazard assessment puts the 50-year probability of a magnitude 6.75 or greater earthquake somewhere along the Wasatch Front region at around 43 percent. That is a regional figure across the whole fault system, not a prediction for any single building, but it is the reason "our data is backed up" is not the same question as "can we reopen if the office itself is unusable."

DRaaS: what disaster-recovery-as-a-service actually includes

Disaster-recovery-as-a-service (DRaaS) is the industry term for replicating your servers to a separate cloud environment so that, if your primary infrastructure is unavailable, a working copy can be started up elsewhere instead of being rebuilt from scratch. Compared to backup alone, DRaaS is built around a documented failover process: what gets started first, in what order, and who is responsible for each step, tested ahead of time rather than figured out during the outage.

What a realistic recovery timeline looks like

Recovery time depends heavily on what failed and where the copies live. Based on the recovery tiers WITS documents for business backup and disaster recovery clients:

A single deleted file or folder, restored from local backup: typically minutes.

A full server, restored from a local backup appliance: typically 2 to 6 hours, depending on size.

Full disaster recovery from cloud backup (local infrastructure unavailable): a few hours to a full business day, depending on data volume and available bandwidth.

Total facility loss (fire, flood, or the office is otherwise unusable): most businesses can have core functions running on replacement cloud infrastructure within 24 to 48 hours, assuming the plan and the replication were already in place.

Notice the pattern: every one of those timelines assumes backups exist, are recent, and were tested before the day they were needed. None of them are achievable if the first time anyone tries a full restore is during the actual emergency.

Building your own IT disaster recovery plan

This applies whether you handle IT internally, work with WITS, or work with another provider.

List your critical systems and rank them: what has to be running in the first hour, the first day, and what can reasonably wait a week.

Assign an RTO and RPO to each one. Be honest about what the business can actually tolerate, not what would be ideal.

Document the failover steps for each critical system: what gets restored first, from where, and who does it. The CISA #StopRansomware Guide recommends keeping a hard copy of this plan, since a plan that only exists on the network you are trying to recover is not much use during an incident.

Keep at least one backup copy offline or immutable. CISA's guidance is specific on this point: many ransomware variants actively try to delete or encrypt accessible backups, so a copy the attacker cannot reach or modify is what makes recovery possible after an attack, not just after hardware failure.

Test a real restore on a schedule, not just when something breaks. A backup that has never been restored is a guess, not a plan.

Review the plan when the business changes. New software, a new location, or a new critical vendor should trigger an update, not wait for the next annual review.

How WITS builds this for Utah businesses

WITS documents a specific Recovery Time Objective and Recovery Point Objective for each client, based on their systems and risk tolerance, rather than selling a generic backup subscription. The architecture is multi-layer: local snapshots for fast, minutes-level restores, plus continuous offsite cloud replication to a geographically separate datacenter for true disaster recovery, plus immutable and air-gapped backup tiers that are built specifically so that an attacker with administrative access still cannot delete or encrypt them. Backups are verified daily, quarterly test restores confirm the data is actually recoverable, and an annual full disaster recovery exercise simulates a complete site loss with the client's team involved, not just WITS staff.

Other Blogs