🇮🇩 Baca artikel ini dalam Bahasa Indonesia
Executive Summary: The events of 2020 have exposed a hard truth — most IT disaster recovery plans were built for a world that no longer exists. They assumed localized disruptions, on-premise infrastructure, and employees who could physically reach an office. This article examines the specific assumptions that made your DR plan obsolete before the pandemic even started, and outlines a practical framework for rebuilding it around the risks that actually matter now.
Six months ago, if you had asked most CIOs whether their organization had an IT disaster recovery plan, the answer would have been yes. Confidently, even. The plan sat in a binder somewhere — or more likely in a SharePoint site no one had touched since the last audit cycle. It covered server failover procedures, backup schedules, and recovery time objectives for critical applications. On paper, it looked thorough. In practice, it was built for hurricanes, power outages, and hardware failures. Not for a scenario where every employee in the company goes home on a Friday and doesn’t come back.
That is exactly what happened. And the gap between what organizations planned for and what they actually faced has been staggering.
I have spent twenty years advising organizations on IT strategy, and I have reviewed more disaster recovery documentation than I care to count. What struck me this year was not that plans failed — it was how predictably they failed. The weaknesses were not hidden. They were baked into the foundational assumptions that most organizations never bothered to challenge.
What Most IT Disaster Recovery Plans Actually Cover
To understand why so many plans fell short, you need to understand what they were designed to do. The typical IT disaster recovery plan is structured around a specific set of scenarios: natural disasters, hardware failures, cyberattacks, and facility-level disruptions. The playbook usually includes data backup and restoration procedures, failover to secondary data centers, communication trees for IT staff, and documented recovery time objectives (RTOs) and recovery point objectives (RPOs) for business-critical systems.
These are not unimportant. But they share a common thread: they assume the disruption is contained. A flood hits one data center. A ransomware attack encrypts one network segment. A fire takes out one office. The plan accounts for getting systems back online while people continue working — perhaps from a secondary location, but still within a controlled, predictable environment.
What almost no plan accounted for was a simultaneous, global disruption that changed not just where systems run, but how, where, and whether people can access them at all.
Five Assumptions That Made Your IT Disaster Recovery Plan Obsolete
After working through recovery and continuity challenges with several organizations this year, I have identified five assumptions that consistently undermined otherwise well-documented plans.
1. The Office Will Be Available
Most DR plans assume that at least some physical infrastructure remains accessible. Even plans with “work from alternate site” provisions typically point to a secondary office, a co-working arrangement, or a partner facility. When every office in every city closed simultaneously, that assumption collapsed overnight.
Organizations that had not already invested in remote access infrastructure — VPN capacity, cloud-based collaboration tools, virtual desktop environments — found themselves scrambling to provision access for hundreds or thousands of employees in days rather than months.
2. Disruptions Are Temporary
Traditional DR planning uses recovery time objectives measured in hours or days. The implicit assumption is that you are bridging a gap — keeping things running until normal operations resume. No one planned for a disruption lasting six months and counting, with no clear end date.
This distinction matters because it changes the calculus entirely. A temporary workaround — routing traffic through a backup connection, for example — is acceptable for 72 hours. It is not acceptable for six months. Temporary solutions become permanent infrastructure, and they were never designed or secured for that purpose.
3. The Workforce Is Constant
DR plans account for systems going down. They rarely account for people going down — or becoming unavailable in large numbers. The pandemic introduced mass absenteeism, furloughs, childcare constraints, and mental health challenges that reduced effective workforce capacity across every function, including IT.
I worked with one mid-size manufacturing firm where the entire three-person infrastructure team was affected within the same two-week window. Not by the virus itself, but by school closures that left them splitting attention between server migrations and second-grade math homework. The plan had no provision for this.
4. Supply Chains Are Functional
Need to replace a failed server? Order new laptops for remote workers? Procure additional VPN licenses? In a normal disruption, the supply chain is intact and procurement is a matter of lead times and budget approval. In 2020, global supply chains seized up. Laptop shortages became a genuine business continuity risk — a sentence I never expected to write in a professional context.
Hardware lead times that were normally two to three weeks stretched to two to three months. Organizations that relied on just-in-time procurement with no buffer inventory found themselves unable to equip their own employees.
5. Cybersecurity Posture Holds Under Pressure
The rush to enable remote work created an enormous attack surface expansion that most security teams were not resourced to address in real time. Personal devices on corporate networks. Hastily configured VPNs. Shadow IT proliferating as employees found their own solutions to collaboration gaps. According to the FBI, reported cyberattack complaints increased by approximately 400% in the early months of the pandemic [Source: FBI IC3, 2020].
Most disaster recovery plans treat cybersecurity as a separate domain with its own incident response procedures. But when the DR activation itself introduces new security vulnerabilities, the two are inseparable — and few organizations had planned for that overlap.
Why This Is Not Just a Pandemic Problem
It would be convenient to treat this as a once-in-a-century anomaly and move on. I would advise against that.
The underlying shifts that made traditional DR plans inadequate were already in motion before COVID-19 accelerated them. Cloud adoption was increasing. Remote work was growing. Cyber threats were escalating. The pandemic did not create these trends — it stress-tested organizations against them with no warning and no grace period.
The question executives should be asking is not “how do we plan for the next pandemic” but rather “what other scenarios would expose these same gaps?” A major cyberattack that disables corporate networks for weeks. A geopolitical event that disrupts cloud provider availability in specific regions. A climate event that makes physical offices inaccessible for extended periods across multiple geographies. These are not hypothetical. They are increasingly probable.
Rebuilding Your IT Disaster Recovery Plan for Current Reality
Updating a disaster recovery plan is not a matter of adding a “pandemic” section to the existing document. It requires re-examining the plan’s foundational architecture. Here is a framework I have been using with clients, organized around four pillars.
Pillar 1: Scenario Expansion
Move beyond single-point-of-failure scenarios. Your plan should address:
- Localized disruptions — the traditional scope (facility loss, hardware failure, regional events)
- Distributed disruptions — events that affect multiple locations simultaneously but leave infrastructure intact (pandemic, widespread civil disruption)
- Sustained disruptions — events lasting weeks or months rather than hours or days
- Cascading disruptions — events where the initial incident triggers secondary failures (e.g., remote work transition creating security breaches)
For each category, document specific assumptions, dependencies, and recovery strategies. The goal is not to predict every possible disaster but to ensure your plan functions across a range of disruption patterns rather than just one.
Pillar 2: Infrastructure Resilience
Evaluate your technology stack against one critical question: can every essential business function operate with zero reliance on a physical office?
This is not an argument for abandoning on-premise infrastructure entirely. It is an argument for ensuring that your recovery capabilities do not depend on physical access. Specific areas to assess:
- Remote access capacity: Can your VPN or zero-trust architecture handle 100% concurrent remote users — not just the 20-30% typical in normal operations?
- Cloud readiness: Are critical applications accessible from any location, or do some require on-premise network access?
- Communication systems: Does your crisis communication plan work when email servers are down and employees are not in the building?
- Endpoint management: Can you provision, secure, and support devices that are not on the corporate network?
Pillar 3: People and Process Continuity
This is the area most DR plans handle worst. Technical recovery procedures are meaningless if the people who execute them are unavailable, untrained, or overwhelmed.
Build explicit provisions for:
- Cross-training: No critical recovery procedure should depend on a single individual. Document procedures at a level of detail that allows someone outside the primary team to execute them
- Succession depth: Identify at least three tiers of ownership for every critical system and process
- Decision authority: Pre-authorize spending limits and decision-making authority so that recovery actions are not bottlenecked by approval chains during a crisis
- Workforce capacity planning: Model scenarios where 25%, 50%, or 75% of a team is unavailable and identify minimum viable staffing levels
Pillar 4: Testing That Reflects Real Conditions
Annual DR tests that involve switching to a backup data center on a Saturday morning with the full IT team standing by are better than nothing — but not by much. They test technical failover. They do not test organizational resilience.
Effective testing should include:
- Unannounced exercises that simulate real-world conditions, including incomplete information and key personnel being “unavailable”
- Tabletop exercises with senior leadership — not just IT — walking through decision-making under specific disruption scenarios
- Extended-duration simulations that go beyond the first 24 hours and test sustained operations under degraded conditions
- Post-test reviews with documented findings, assigned remediation owners, and deadlines — not just a summary slide in a quarterly report
The Business Continuity Institute’s 2019 Horizon Scan report noted that only 27% of organizations tested their continuity plans more than twice a year [Source: BCI Horizon Scan Report, 2019]. Given what we now know, that number should concern every executive reading this.
Frequently Asked Questions
How Often Should an IT Disaster Recovery Plan Be Updated?
At minimum, annually — but that should be a comprehensive review, not a rubber stamp. Material updates should also be triggered by any significant change in infrastructure, organizational structure, vendor relationships, or threat landscape. If you migrated a major application to the cloud, changed ERP systems, or onboarded a new managed services provider, your DR plan should reflect that within 30 days, not at the next annual review cycle.
What Is the Difference Between Disaster Recovery and Business Continuity?
Disaster recovery focuses specifically on restoring IT systems and data after a disruption. Business continuity is the broader discipline of maintaining all critical business functions — including people, processes, facilities, and supply chains — during and after a disruptive event. A strong IT disaster recovery plan is a component of business continuity, not a substitute for it. One of the clearest lessons of 2020 is that organizations need both, and they need them to be tightly integrated.
Should Small and Mid-Size Businesses Invest in DR Planning?
Absolutely — and arguably more urgently than large enterprises. Larger organizations typically have more redundancy, deeper bench strength, and greater financial reserves to absorb disruption. A mid-size company with a three-person IT team and a single-vendor dependency has far less margin for error. The plan does not need to be a 200-page document. It needs to clearly answer three questions: what are our critical systems, how do we recover them, and who is responsible for making that happen?
How Does Cloud Migration Affect Disaster Recovery Planning?
Cloud migration changes DR planning significantly but does not eliminate the need for it. Cloud providers handle infrastructure-level redundancy, which reduces your exposure to hardware failures and facility-level events. However, you remain responsible for application-level recovery, data backup strategies, access management, and — critically — understanding your provider’s own DR commitments. Read the SLA carefully. “99.9% uptime” still allows for nearly nine hours of downtime per year, and most cloud SLAs explicitly exclude certain categories of outage from their guarantees.
The Plan You Need Is the One You Are Willing to Maintain
There is a temptation, in the aftermath of a crisis, to over-engineer the response. I have seen organizations produce 300-page DR documents that are comprehensive, meticulously detailed, and utterly useless because no one reads them and no one maintains them.
The best IT disaster recovery plan is not the most thorough one on paper. It is the one that is understood by the people who need to execute it, tested under conditions that approximate reality, and updated regularly enough to reflect the environment it is supposed to protect.
2020 handed every organization a live stress test of their preparedness. Some passed. Most did not. The question now is whether the lessons learned translate into structural changes or get filed away alongside the old plan that did not work in the first place.
My advice: do not wait for the next crisis to find out. Pull your disaster recovery plan off the shelf this week. Read it with fresh eyes and ask a simple question — would this actually work if everything went wrong again tomorrow? If the honest answer gives you pause, you know what needs to happen next.
