Most Chicago businesses do not fail because of one dramatic cyber movie moment. They fail because something small goes wrong at the wrong time: a server dies during payroll week, a ransomware alert freezes access to files, a vendor outage takes down a core app, or a “minor” flood turns into a week of downtime.
Disaster recovery is how you make sure a bad day stays a bad day, not a business-ending week.
This guide is an evergreen DR playbook for Chicago organizations. We will cover what disaster recovery actually includes, how to set realistic RTO and RPO targets, the backup approaches that matter most, and how to test your plan so it works when you need it.
What “disaster recovery” really means
Disaster recovery (DR) is your ability to restore systems and keep operating after a major disruption. It is closely related to business continuity, but DR is more specific: it focuses on IT systems, data, and the steps to get them back online.
A solid DR plan answers four questions:
-
What needs to be restored first?
-
How quickly do we need it back?
-
How much data can we afford to lose?
-
Who does what when things go wrong?
RTO vs RPO (the two numbers that drive your entire plan)
If you only learn two terms, make them these:
RTO: Recovery Time Objective
How fast you need a system back online after an outage.
Example: “Email must be restored within 4 hours.”
RPO: Recovery Point Objective
How much data you can afford to lose measured in time.
Example: “We can lose no more than 15 minutes of file changes.”
Here is the practical takeaway: lower RTO and lower RPO cost more. Faster recovery usually requires more infrastructure, more automation, and more planning. The goal is not to chase perfection. The goal is to match your recovery targets to business reality.
Step 1: Identify what matters most (and rank it)
Every business has “Tier 1” systems, even if they have never said it out loud. Start with a simple tier list:
-
Tier 1 (Must restore first): identity/login, email, core files, line-of-business app, financial systems
-
Tier 2 (Important but not immediate): internal tools, collaboration apps, reporting dashboards
-
Tier 3 (Can wait): legacy systems, low-use archives, nice-to-have tools
This step helps you avoid the classic mistake of treating every system like it is equally critical.
Step 2: Choose backup types that match your risk
Not all backups are equal. Many companies think they are protected because “we back up our files,” but disaster recovery depends on the backup method, how quickly it can be restored, and whether it is protected from the same incident that caused the outage.
File-level backups
Good for protecting documents and shared drives.
Limitations: restoring an entire environment can be slow if you only have files, not systems.
Image-based backups
Back up a full system image (servers or key machines).
Strong option for restoring quickly after hardware failure.
Cloud-to-cloud backups
Critical for Microsoft 365 and other SaaS platforms.
Many organizations assume Microsoft 365 data is automatically protected forever. In reality, retention and recovery options depend on configuration and licensing. A dedicated backup tool improves recoverability and control.
Offsite and immutable backups
If ransomware is part of your threat model (it should be), consider backups that cannot be altered or deleted easily. The point is to make sure your backups survive the same attack that hits production systems.
The “3-2-1” rule (still useful, but only if you test it)
A classic baseline is:
-
3 copies of data
-
2 different media types
-
1 copy stored offsite
This is a solid starting concept, but it is not a substitute for testing. If you have never restored from your backups, you do not know your real recovery time.
Step 3: Build your DR runbook (the part people skip)
A runbook is a step-by-step guide for what to do when disaster hits. It should be written so someone can follow it under pressure.
At minimum, include:
-
A contact list (internal owners, MSP/IT partner, ISP, cloud vendor, security partner)
-
Where credentials are stored and who can access them
-
The order of restoration by tier
-
How to declare an incident and who approves major actions
-
Communication templates (internal update, customer update if needed)
-
A short checklist for “first 60 minutes”
If you have a managed IT services provider, this is where you confirm who owns what. If you do not, this is where you avoid chaos.
Step 4: Tabletop exercises (the fastest way to spot gaps)
A tabletop exercise is a structured “what would we do if…” meeting. No scary technical work required. The goal is to test decision-making and workflows before you are forced to do it live.
Run one tabletop for each of these scenarios:
-
Ransomware on a key workstation that spreads
-
A core server failure
-
Cloud outage or major SaaS disruption
-
Lost or compromised admin credentials
In 60 minutes, you will usually uncover the same problems:
-
“We do not know who has the admin passwords”
-
“We do not know what order to restore systems”
-
“We are not sure what our backups actually cover”
-
“We have no plan for internal communication”
That is good news. Those are fixable.
Step 5: Test what matters, not just what is easy
Testing is what turns disaster recovery from a document into a capability. You do not need to test everything at once. Start with the systems that represent the biggest operational risk.
Good testing milestones include:
-
Restore a set of files and confirm version integrity
-
Restore a server image to a sandbox environment
-
Test Microsoft 365 restore workflows (mailboxes, OneDrive, SharePoint)
-
Validate that backup accounts use MFA and least privilege
-
Confirm you can restore within your target RTO and RPO
If a restore takes 2 days, your “4 hour RTO” is a fantasy. Better to find that out during a planned test than during a real incident.
A practical 30/60/90-day disaster recovery checklist
First 30 days: visibility and quick wins
-
Create a system inventory and tier list (Tier 1, 2, 3)
-
Define RTO and RPO targets for Tier 1 systems
-
Confirm backups exist for Tier 1 data and core systems
-
Ensure admin accounts have MFA and strong access controls
-
Document where credentials and recovery keys are stored
-
Write a one-page incident contact list and escalation path
Next 60 days: strengthen protection and the runbook
-
Add offsite or immutable backups where needed
-
Implement cloud-to-cloud backups for Microsoft 365 (if not already in place)
-
Standardize backup retention and review policies
-
Draft a DR runbook with restore order and roles
-
Create internal communication templates for incidents
-
Run your first tabletop exercise
Next 90 days: testing and measurable readiness
-
Perform a restore test for Tier 1 systems
-
Measure actual recovery time and compare to targets
-
Fix gaps found during testing
-
Schedule quarterly tabletop exercises
-
Schedule routine restore tests (monthly or quarterly based on risk)
Disaster recovery for nonprofits and resource-tight teams
If you are a nonprofit or a smaller team, DR can feel overwhelming because budgets are tight and IT is not the main mission. The key is to prioritize Tier 1 systems and focus on recoverability:
-
Protect email and identity first (MFA, access policies, backup)
-
Protect core files (SharePoint/OneDrive plus backup)
-
Document your restore steps and contacts
-
Test restores regularly, even if the environment is small
A simple, tested plan beats an elaborate plan nobody can execute.
The bottom line
Disaster recovery is not about fear. It is about control. When something breaks, you want clarity: what to restore first, how fast you can recover, and who owns each decision.
If you have not defined RTO and RPO, documented your restore order, and tested a real restore, your DR plan is not complete. The good news is you can make meaningful progress in 30 to 90 days with a focused, practical approach.