Business Continuity & Disaster Recovery

Summary:

Business Continuity (BC) and Disaster Recovery (DR) are often discussed together, but they solve different problems.

Business Continuity focuses on keeping critical business functions operating during disruption, while Disaster Recovery focuses on restoring systems, applications, and data after a failure has occurred.

A successful organisation does not eliminate risk. Instead, it understands its risks, prepares for likely failure scenarios, and develops practical procedures that allow the business to continue operating when incidents occur.

Context

Every organisation experiences disruption.

The cause may be technical, environmental, operational, or human:

Hardware failure
Software defects
Cyber attacks
Power outages
Internet connectivity failures
Flooding
Fire
Human error
Supplier failure

The question is not whether disruption will occur, but whether the organisation can continue operating when it does.

Business Continuity and Disaster Recovery provide the framework for answering that question.

Common Misconceptions

Backups are not a Disaster Recovery strategy.
Disaster Recovery is not Business Continuity.
Cloud services do not automatically eliminate business continuity risks.
Redundancy does not replace planning.
Technology alone cannot solve continuity challenges.

Why It Matters

The impact of service disruption extends far beyond IT systems.

Potential consequences include:

Lost revenue
Decreased productivity
Regulatory consequences
Reputational damage
Loss of customer confidence
Contractual penalties

The longer an outage continues, the more expensive it becomes.

Core Concepts

Business Continuity

Business Continuity focuses on maintaining business operations during disruption.

Typical questions include:

Can staff continue working?
Can customers still receive services?
Can orders still be processed?
Can communication continue?

Business Continuity planning often involves:

Alternative work locations
Manual fallback procedures
Communication plans
Alternative suppliers
Emergency operating procedures

The objective is to ensure the business remains functional.

Disaster Recovery

Disaster Recovery focuses on restoring technology services.

Typical questions include:

How quickly can systems be restored?
How much data loss is acceptable?
Which systems must be recovered first?
What dependencies exist?

Disaster Recovery planning commonly includes:

Backup strategies
Replication technologies
Recovery procedures
Recovery testing
Infrastructure replacement plans

The objective is to restore technical services within acceptable timescales.

Recovery Time Objective (RTO)

RTO defines the maximum acceptable duration of service outage.

For example:

Email system: 8 hours
Customer portal: 1 hour
Public website: 24 hours

The lower the RTO, the greater the complexity and cost of the solution.

Recovery Point Objective (RPO)

RPO defines the maximum acceptable amount of data loss.

Examples:

24-hour RPO = potentially lose one day's data
1-hour RPO = potentially lose one hour's data
Near-zero RPO = continuous replication

Like RTO, lower RPOs generally increase implementation costs.

Reference Architectures

Small Organisation

A typical small business recovery model might consist of:

On-premises servers
Local backups
Cloud backup repository
Basic recovery documentation

Benefits:

Low cost
Simple management

Limitations:

Longer recovery times
Greater operational dependency on individuals

Enterprise Organisation

Enterprise environments typically introduce:

Geographic redundancy
Multiple data centres
Clustered infrastructure
Replicated storage
Automated failover systems

Benefits:

Reduced downtime
Greater resilience

Limitations:

Increased complexity
Higher implementation and operational costs

Hybrid Approach

Many organisations operate between these extremes.

Common examples include:

Microsoft 365 with on-premises line-of-business applications
Cloud-hosted infrastructure with local file services
Hybrid Active Directory deployments

Hybrid models often provide an effective balance between cost, flexibility, and resilience.

Operational Lifecycle

Build

During the design phase:

Identify critical services
Determine dependencies
Define RTO and RPO requirements
Assess risk exposure

Run

During normal operations:

Monitor systems
Verify backups
Review changes
Maintain documentation

Maintain

Continuity plans must evolve alongside the environment.

Review should occur when:

New systems are introduced
Infrastructure changes significantly
Business processes change
Suppliers change

Retire

Decommissioning systems should include:

Data archival requirements
Regulatory retention obligations
Recovery plan updates
Documentation updates

Practical Application

Identifying Critical Services

Not all systems are equal.

A common mistake is assuming every service is mission critical.

Instead, classify systems according to business impact.

Example:

System	Priority	Business Impact
ERP System	Critical	Financial operation stops
Email	High	Significant disruption
Intranet	Medium	Operational inconvenience
Archive Server	Low	Minimal immediate impact

Recovery efforts should prioritise critical systems first.

Mapping Dependencies

Many recovery failures occur because dependencies were not identified.

For example:

Customer Portal

   |
   +-- SQL Database
   |
   +-- Active Directory
   |
   +-- DNS
   |
   +-- Internet Connectivity
   |
   +-- SSL Certificates

Recovering the portal without restoring its dependencies achieves nothing.

Common Pitfalls

Backups Are Never Tested

A backup is merely a theory until restoration has been successfully demonstrated.

Regular restore testing should be mandatory.

Documentation Exists Only in Production

Recovery procedures stored on failed systems are of little value.

Critical documentation should exist in multiple accessible locations.

Key Knowledge Resides with One Person

Many organisations possess undocumented systems understood by only one administrator.

This represents a significant business risk.

Recovery Plans Are Never Practised

The first execution of a DR plan should never occur during a real disaster.

Testing frequently exposes assumptions, dependencies, and documentation gaps.

Security Implications

Business Continuity and Cyber Security are closely related.

Attackers increasingly target:

Backup systems
Replication systems
Identity services
Recovery infrastructure

Key recommendations include:

Immutable backups
Offline backup copies
Multi-factor authentication
Privileged access controls
Separate recovery credentials

Recovery systems should be considered critical security assets.

Troubleshooting & Diagnostics

When assessing resilience, ask:

Backup Health

Are backups completing successfully?
Are failures monitored?
Are restore tests performed?

Infrastructure Resilience

Are there single points of failure?
Is failover tested?
Is monitoring effective?

Operational Readiness

Is documentation current?
Are responsibilities assigned?
Are contact lists accurate?

Recovery Capability

Has recovery been rehearsed?
Are recovery times measured?
Can critical services actually meet RTO targets?

Design & Architecture Considerations

Scalability

Recovery solutions should grow alongside the business.

Security

Protect recovery infrastructure as carefully as production systems.

Maintainability

Complex recovery solutions often fail because they become difficult to support.

Prefer solutions that operations teams understand and can maintain confidently.

Backwards Compatibility

Legacy systems frequently outlive expectations.

Recovery planning should account for unsupported applications and historical dependencies.

Lessons from the Real World

Most major outages are not caused by dramatic disasters.

They are usually caused by ordinary events:

Failed storage
Expired certificates
Configuration mistakes
Software updates
Human error
Supplier outages

The most resilient organisations are not those that never fail.

They are the organisations that expect failure, prepare for it, and recover methodically.

A continuity plan should never aim to create the illusion that disruption is impossible.

Its purpose is to ensure that disruption becomes manageable.

References

ISO 22301 Business Continuity Management
ISO 27001 Information Security Management
NIST Cybersecurity Framework
NIST SP 800-34 Contingency Planning Guide
Vendor backup and recovery documentation