Business Continuity, Critical Path, and Critical Operations are concerned with how you keep the business going.

Mission critical functions are functions you require to keep the business going, such as web servers, firewalls, power to the facility, etc. (this also includes staff needed to operate equipment and application troubleshooting).  For example, an ecommerce site would need to keep its sales and inventory fully functional to maintain operations.  

If a disaster happens, business continuity has failed in some regard, and contingency operations will be initiated, this basically means that critical stuff mentioned above will be brought up and functional first.

Once contingency procedures have brought the critical functions back, disaster recovery would be initiated, which represents the efforts needed to transition from contingency operations to normal operations.  Here is a breakdown of the order:

  1. Business continuity – mission critical
  2. Contingency operations
  3. Disaster Recovery

The acronym “BCDR” is frequently used for business continuity and disaster recovery, however you can use the acronym to visualize the order in which recovery procedures should be done at a high level.  

BC and DR efforts are often performed concurrently by the same or related functions in the organization.  

Business Continuity and Disaster Recovery (BCDR) Considerations

Senior management must define three key control parameters that will guide the development of BCDR plans:

  1. The Maximum Allowable Downtime (MAD)—also known as the Maximum Tolerable Downtime (MTD) or Maximum Allowable Outage (MAO)—refers to the maximum period a mission-critical business process can be disrupted before causing significant or unacceptable harm to the organization’s objectives.
  1. Recovery Time Objective (RTO) – This represents the target timeframe for restoring operations following a disruption. The RTO must always be shorter than the MAD, ensuring that recovery occurs well before reaching an unacceptable level of operational impact. Setting the RTO requires management’s expertise in assessing organizational needs, and all BCDR strategies must align with achieving this goal. It’s important to note that “recovery” in this context does not imply a full return to normal operations but rather the restoration of critical functions to a temporary operational state until complete recovery is feasible.
  2. Recovery Point Objective (RPO) – This defines the acceptable amount of data loss an organization can tolerate before experiencing severe disruption. Rather than being measured in storage capacity (such as gigabytes or terabytes), RPO is expressed in terms of time—ranging from minutes to days—based on organizational requirements. The RPO is determined by senior management and, together with the RTO, informs the overall BCDR planning process.

Work Recovery Time (WRT) –Beyond system restoration, organizations must account for WRT—the period needed to process transaction backlogs and restore operational stability. This phase ensures that all data and workflows disrupted during the outage are properly reconciled before returning to full operations.

These objectives serve as planning benchmarks rather than absolute limits. In practice, many organizations continue operating beyond the MAD threshold, and some manage to survive even when actual data losses exceed the planned RPO. However, these thresholds help management assess whether additional resources or prioritization are necessary for BCDR efforts.

Balancing Cost and Recovery Strategies

Determining the appropriate RTO involves financial considerations. The shorter the RTO, the greater the investment required to ensure rapid recovery. Similarly, the RPO influences decisions regarding data replication and backup strategies. For instance, in financial institutions, even a second of data loss is unacceptable, necessitating high-availability solutions. In contrast, other industries may have greater tolerance for data loss, influencing the choice of recovery sites and methods.

Addressing External Dependencies and Cloud Failures

A stakeholder map is something that includes all supply chain partners and customers, and highlights the importance of a communications strategy that should be included in the BCDR. When operations depend on cloud infrastructure, BCDR planning must account for various failure scenarios such as:

  • Local data center outages
  • Regional cloud service disruptions
  • Global cloud provider failures

Recovering from a complete Software as a Service (SaaS) provider failure presents significant challenges, requiring contingency planning to mitigate risks.

External Dependencies

A well-defined critical path needs to identify all external dependencies, including links in the supply chain and anything (assets) needed for operations, and by integrating these things, organizations can develop robust BCDR plans.

Determining the critical path

So how is the mysterious critical path determined?  The primary tool to be aware of is the Business Impact Analysis (BIA)  – a tool or template that contains asset values, the business impact if there is a loss, and possible threats to the organization.

Methods of conducting the BIA include:

  • Internal survey – talk to the asset owners; this can be informative but can also be biased
  • Financial audit – audits are thorough but might not be accurate for value fluctuations
  • Customer responses/surveys – such surveys only see the customer’s view, not the whole organization, operations, or the whole value chain
  • Industry Standards & Best Practices – Leverage insights from industry regulators and professional associations to guide continuity planning. Organizations that implement more robust continuity measures than their competitors may gain a competitive advantage, while those with weaker strategies risk reputational and financial harm during a crisis.