7 steps to build a disaster recovery plan

Imagine this scenario: You’ve spent years building a successful business, and then disaster strikes. It could be a hurricane, fire, hardware failure, human error, or ransomware attack. Suddenly, critical systems and the data they contain are unavailable.

What would you do?

Most businesses have backups. Far fewer have a documented and tested disaster recovery plan that explains how they will restore critical systems and resume operations.

For a small business, prolonged downtime can quickly affect revenue, customer service, employee productivity, and the ability to meet contractual or regulatory obligations. Regardless of what causes the disruption, the most important question is how quickly employees can return to work, customers can be served, and essential operations can resume.

A disaster recovery plan bridges the gap between protecting data and restoring the systems the business depends on.

Backup protects data. Disaster recovery protects the business.

Many organizations assume that having backups means they can recover quickly from an outage. Backups are essential, but they are only one component of recovery.

That confidence can be misleading. In an OpenText survey, 95% of SMBs said they were confident they could recover from a ransomware attack, yet only 15% were actually able to do so. Confidence is not the same as recoverability, and having a backup is not the same as having a tested recovery plan.

A backup provides a copy of data. Disaster recovery addresses the much larger challenge of restoring applications, servers, identities, network connectivity, user access, configurations, and the other dependencies required to operate the business.

Even when data is recoverable, restoring systems can take days or weeks if the recovery process has not been planned and tested. During that time, employees may be unable to work, customers may be unable to place orders, and the organization may be unable to generate revenue.

Here are seven steps small businesses can take to build a practical disaster recovery plan.

Define your incident response process

When a disruption occurs, your team should know who has the authority to declare an incident, who coordinates the response, and who communicates with employees, customers, vendors, insurers, law enforcement, and technical support providers.

Document the order in which people should be contacted, the circumstances that require escalation, and how the team will communicate if normal email, phone, or collaboration systems are unavailable.

The immediate response will vary by incident. A fire or severe-weather event begins with protecting people and property. A ransomware incident may require isolating affected systems, preserving evidence, engaging security specialists, and preventing compromised devices from reconnecting to the environment.

Preparation should also include regular security awareness training so employees can recognize potential threats, report suspicious activity, and understand their role during a security incident.

Assign each task to a primary owner and designate a backup. Review the plan with employees and conduct tabletop exercises so everyone understands their role before an actual emergency occurs.

Identify critical systems and establish recovery objectives

Start by identifying the products, services, and business processes that must be restored first. Then map the applications, servers, identities, network connections, data, employees, and third-party services each process depends on.

Your disaster recovery plan should answer four important questions:

Which systems are most critical?

Prioritize systems according to their importance to the business. Document the order in which they must be restored, including dependencies such as identity services, DNS, networking, cloud platforms, and vendor-managed applications.

How long can each system remain unavailable?

Establish a recovery time objective, or RTO, for each critical service. The RTO defines the maximum acceptable amount of time the service can remain unavailable.

How much data can the business afford to lose?

Establish a recovery point objective, or RPO. The RPO determines how frequently data must be protected and how far back the organization may need to recover.

How will the business operate during recovery?

Document alternate work locations, manual processes, backup communication methods, and the vendors or service providers that can help maintain essential operations.

Use the Downtime Calculator to estimate how an extended outage could affect your revenue and productivity.

Protect more than your data

Your recovery strategy should protect the complete environment required to operate the business, not only individual files.

Identify the applications, servers, operating systems, configurations, databases, cloud services, identity systems, and network services required for each critical business process. Document where these systems will run if the production environment becomes unavailable and how employees will securely access them.

Maintain separate, versioned recovery copies of critical data and systems. At least one recovery copy should be isolated or immutable so ransomware, compromised credentials, or accidental deletion cannot alter every available copy.

Recovery credentials should also be protected separately from everyday administrative accounts. If the same compromised identity can access both the production environment and its recovery systems, attackers may be able to damage both.

A reliable server backup and recovery solution can help protect critical systems and provide the recovery points needed to restore operations following hardware failure, accidental deletion, ransomware, or another disruption.

Organizations that cannot tolerate extended downtime may also need recovery services that allow critical workloads to operate from alternate infrastructure while production systems are being restored.

Test the complete recovery process

A successful backup does not prove that the business can recover. Testing should validate the complete recovery process, including applications, servers, identity services, network connectivity, user access, system dependencies, and the integrity of restored data.

Run recovery tests regularly and measure the results against your RTOs and RPOs. Confirm that systems can be restored in the required order and that employees can access the applications and information they need.

For cyber incidents, verify that systems can be restored from a well-known recovery point without reintroducing malware, compromised credentials, unauthorized access, or the original vulnerability.

Document what worked, where recovery took longer than expected, and which procedures or responsibilities were unclear. Update the plan whenever the business adds new systems, changes vendors, modifies its infrastructure, or discovers a gap during testing.

Review your insurance coverage

Insurance can help absorb some of the financial impact of a disruption, but coverage varies significantly by policy, incident type, and recovery expense.

Review your policies regularly with your insurer and confirm the notification, documentation, security-control, and reporting requirements that must be satisfied before a claim will be covered.

Depending on the policy, relevant coverage may include:

• Data recovery and system repair
• Incident response and forensic investigation
• Legal and regulatory expenses
• Business interruption and income loss
• Ransomware and social engineering incidents
• Customer and stakeholder notification
• Damage affecting critical suppliers or service providers

Understand any exclusions, coverage limits, waiting periods, or security requirements that could affect a claim. Insurance can help manage financial loss, but it is not a replacement for a tested recovery plan.

Prepare alternate ways to operate

Disaster recovery becomes easier when resilience is built into normal business operations.

Determine how employees will work if a primary location is unavailable. Provide secure alternate methods for internet access, internal connectivity, communication, and authentication.

Prepare for disruptions involving power, internet connectivity, phone service, transportation, or building access. Document alternate locations, backup communication methods, critical equipment, and any manual processes required to continue essential work.

Cloud-hosted applications may improve availability, but moving a service to the cloud does not automatically create a recovery plan. Understand what the provider protects, what your business remains responsible for, and how data, configurations, identities, and access can be recovered.

Business records and communications may also need to remain accessible during an outage, especially when they are subject to legal, regulatory, or retention requirements.

Business communications archiving can help organizations preserve and access important communications while supporting compliance and information-governance requirements.

Store protected copies of the recovery plan, technical procedures, vendor contacts, insurance information, and required credentials somewhere the response team can access even when normal systems are unavailable.

Account for suppliers and service providers

Your business may depend on cloud platforms, internet services, software vendors, payment processors, suppliers, managed service providers, and other third parties. A disruption affecting one of them could prevent your business from operating even if your own systems remain available.

Identify these dependencies and understand each provider’s recovery commitments, support process, and communication procedures. Maintain current escalation contacts and determine whether alternate suppliers or temporary workarounds are available for critical services.

Ask critical providers how they protect your data, how frequently they test their own recovery procedures, and how they will communicate during an outage. Your recovery plan should also address how data and services can be moved or restored if a provider is unavailable for an extended period.

If your organization provides essential products or services to other businesses, document how you will notify customers, set expectations, and continue delivering priority services during a disruption.

Recovery confidence should come from testing

A disaster recovery plan is not simply an IT document. It is a business strategy for maintaining essential operations and restoring the systems the organization depends on.

Before returning restored systems to production, validate that the selected recovery point is clean, confirm that compromised accounts and access tokens have been revoked, apply required security updates, and monitor for signs that an attacker still has access.

The goal is not simply to restore data. It is to restore a trustworthy, functional environment within the recovery objectives established by the business.

Recovery confidence should come from evidence, not assumptions. Organizations are better prepared when they have established recovery priorities, protected the systems and data required to rebuild, assigned clear responsibilities, and repeatedly tested whether the plan works under realistic conditions.

OpenText Cybersecurity offers solutions spanning business communications archiving, server backup and recovery, and recovery services to help organizations protect critical information, restore essential systems, and maintain operations during a disruption.