Direct Answer: A real IT recovery plan is a documented set of decisions made in advance, what systems are critical, how long they can be down, how much data loss is acceptable, and who does what when something goes wrong.
Most small businesses in Monterey County have some form of backup running. What most of them don’t have is a plan that tells people what to do when the backup is actually needed. Those are two very different things.
A backup is a copy of your data. A recovery plan is the document that answers every decision your team will face at 7 p.m. on a Wednesday when something stops working, before the panic sets in. If that document doesn’t exist, or if it’s a vague template someone downloaded and filed away, your recovery time will be measured in days instead of hours.
This article walks through what a real plan actually contains, section by section. If you’re building one from scratch or reviewing one that was handed to you, this is what to look for.
The Four Questions Every Recovery Plan Must Answer
Before any document is built, there are four decisions the plan must capture in writing. Without answers to all four, the document is incomplete.
- What systems are critical? Not every server or application is equal. The plan needs a ranked list of every system the business depends on, ordered by how quickly it needs to be restored before real damage occurs.
- What is the RTO for each system? The Recovery Time Objective is how long each critical system can be offline before the business takes serious harm. For a Salinas agricultural company running logistics and dispatch software during harvest season, that window might be two to four hours. For a Monterey Peninsula law firm that depends on its document management system and email, it could be even shorter.
- What is the RPO for each system? The Recovery Point Objective is how much data the business can afford to lose, measured in time. If the last backup ran at 6 a.m. and a failure happens at 3 p.m., you’re potentially losing nine hours of transactions. Is that acceptable? The plan should say so explicitly, for each system.
- Who is responsible for each step, and how do they reach the right people? Recovery doesn’t happen by itself. Every action in the plan needs an owner, and that owner needs a way to contact vendors, carriers, and decision-makers without searching for phone numbers while the server is down.
These four answers form the foundation. Everything else in the plan supports them.
The Asset Inventory: What Goes on the Priority List
The plan needs a written inventory of every server, application, and data set the business relies on. Then each item gets ranked by how quickly it must be restored.
This list looks completely different depending on the business. A Salinas produce distributor running logistics software and QuickBooks needs those systems back first, without them, shipments don’t move and invoices don’t go out. A law firm on the Monterey Peninsula, on the other hand, may be far more dependent on its document management platform and email. Those two businesses might share the same backup vendor and have similar budgets, but their priority lists are entirely different.
The inventory should capture:
- Every server, whether physical or virtual
- Cloud-hosted applications and the data they hold
- Communication systems, including VoIP and email
- File shares, databases, and industry-specific software
- The most recent backup location for each item
If you’re unsure how to think through cloud versus local infrastructure when building this list, the private cloud vs. on-premise comparison for Monterey Bay businesses covers the tradeoffs in plain terms. The point here is that the inventory is not a one-size document, it reflects your specific operation, ranked by real business impact.
The Five Components of a Complete Recovery Plan
This breakdown shows what each section of a real IT recovery plan should contain and why it matters.
Two Things Most Plans Are Missing
When an IT provider reviews a small business recovery plan for the first time, two gaps show up more often than any others.
The first is a tested restore log. A backup job that shows “completed” in the software is not the same as a backup that actually works. A tested restore log is documented evidence that someone ran a test restoration recently, confirmed the data came back cleanly, and recorded the date and result. Without this, you won’t know your backup is broken until you desperately need it.
The second is a contact tree. This is a list of vendors, software providers, carriers, and internal decision-makers who need to be reached in a specific order when an incident happens. Internet provider, server vendor, software support line, key internal staff, all with direct phone numbers, not general support queues. Without a contact tree, recovery time stretches by hours while people search for numbers under pressure.
These two items are the difference between a plan that actually functions and one that just exists on paper. For more on what a foundational security and IT posture looks like for a small business, the cybersecurity baseline guide for small businesses in Monterey County covers the broader picture.
Recovery Plan Components at a Glance
This table shows each required component, what it should contain, and the most common gap when IT providers review plans for the first time.
| Component | What It Should Include | Most Common Gap |
|---|---|---|
| Asset Inventory | All servers, apps, and data sets ranked by restoration priority | Systems listed but not ranked or missing cloud apps |
| RTO Targets | Max acceptable downtime per system, in hours | Generic targets not tied to specific systems |
| RPO Targets | Max acceptable data loss per system, in hours | Never formally defined, defaults to whatever the backup schedule is |
| Recovery Procedures | Step-by-step instructions with named owners | Exists but no one assigned to execute each step |
| Contact Tree | Vendors, carriers, and internal decision-makers in call order | Often completely absent or lists generic support numbers |
| Tested Restore Log | Dated records of successful test restorations | Backup job shows complete but restores have never been verified |
Why Ransomware Changed the Backup Conversation
A recovery plan written five years ago may have a gap that didn’t exist then. Ransomware attackers in 2025 and 2026 routinely target backup systems as part of the attack, not as an afterthought. Some groups deliberately seek out and corrupt or encrypt backup repositories before they deploy ransomware against production systems. The goal is to make recovery impossible, which increases pressure to pay the ransom.
This means your recovery plan needs to answer a harder question: not just “where are our backups” but “can a compromised admin account reach them?”
There are three concepts worth understanding here:
- Immutable backups: Backup data that cannot be altered or deleted once written, even by an administrator. Most modern cloud backup platforms support this.
- Air-gapped copies: A copy of backup data that is physically or logically separated from the production network, an attacker who owns your network cannot reach it.
- Separate backup credentials: Backup system access should be managed with credentials that are distinct from general admin accounts. If one set of credentials is compromised, the backup environment stays protected.
The NIST Cybersecurity Framework addresses backup isolation as part of its recovery function guidance, and it is increasingly referenced in California compliance conversations. This is also worth reading alongside the broader question of why small businesses have become ransomware’s primary target, a pattern that shows up clearly in Monterey County’s small and mid-sized business sector.
If your current recovery plan doesn’t address backup isolation, that section needs to be written before anything else is updated. A backup that an attacker can also encrypt is not a recovery option.
Frequently Asked Questions About IT Recovery Plans
What is the difference between a backup and a disaster recovery plan?
A backup is a copy of your data. A disaster recovery plan is the documented set of decisions that tells your team what to do when something goes wrong, which systems to restore first, in what order, who is responsible, and how to reach the right people. You can have backups without a plan, but you can’t execute a recovery efficiently without one.
How often should a recovery plan be tested?
Most IT professionals recommend a full test at least once per year, with restore log verification quarterly. If your business changes significantly, new software, staff changes, infrastructure upgrades, the plan should be reviewed any time those changes happen, not just on an annual schedule.
Does the plan need to be different for cloud systems versus on-premise servers?
Yes. Cloud-hosted systems often have their own recovery tools and retention policies that need to be documented separately. On-premise servers require physical recovery procedures. A good plan addresses both, and it doesn’t assume that “it’s in the cloud” means recovery is automatic.
What should a contact tree actually look like?
It should be a simple ordered list, not a flowchart, with the name of the vendor or person, the direct phone number, what they are responsible for, and any account numbers needed to authenticate during a support call. Internet provider, server or hosting vendor, key software support lines, and two or three internal decision-makers who have authority to make calls during an incident.
Our backup job shows completed every night. Isn’t that enough?
No. A completed backup job means the backup software ran and did not report an error. It does not confirm that the data is intact, that the restore process works, or that the recovered files are actually usable. A tested restore log is the only way to know your backups actually work. Many businesses discover their backups were corrupted or incomplete only when they try to recover from an actual incident.
Want Someone to Review What Your Plan Is Actually Missing?
Adaptive Information Systems works with small and mid-sized businesses across Monterey County, from Salinas to the Peninsula to the South Valley, to build and pressure-test recovery plans that hold up when something actually goes wrong. If you have a plan and want a second set of eyes on it, or if you’re starting from scratch, reach out at (831) 644-0300 or visit adaptiveis.net to start the conversation.
