Dex: Created page with "'''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..."

2026-07-06T06:57:25Z

Created page with "'''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..."

New page

'''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:

{| class="wikitable"
! 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.

== Related Topics ==

* [[Risk Management]]
* [[High Availability]]
* [[Backup Strategies]]
* [[Infrastructure Architecture]]
* [[Capacity Planning]]
* [[Cyber Security Fundamentals]]
* [[Cloud Migration Strategy]]

== 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

Business Continuity & Disaster Recovery - Revision history