COMP 6660 · Enterprise Cybersecurity Business Continuity and Disaster Recovery

00 Introduction

Lesson 6.7 examined incident response — the security discipline of detecting, containing, eradicating, and recovering from an attack. This lesson examines the adjacent disciplines that determine what happens to the business while the response is ongoing: business continuity and disaster recovery.

A ransomware incident that encrypts production systems, a denial-of-service attack that takes a customer-facing service offline, a data-centre fire that destroys the primary facility, a failed software update that corrupts a critical application — these are not only security incidents. They are business disruptions. The security team's job is to contain the attack and restore the systems; the business continuity function's job is to keep the business operating while that happens. The two must work together — but they are distinct disciplines with distinct owners, distinct planning, and distinct testing.

Business continuity and disaster recovery are frequently treated as afterthoughts — documentation produced to satisfy an auditor, plans that are never tested, and recovery objectives that are aspirational rather than demonstrated. The consequence is predictable: when the disruption occurs, the enterprise discovers that its recovery assumptions were wrong, that its restoration capability does not work, and that the business has no defined way to keep operating while the technology is unavailable. The cost of that discovery is measured in extended outages, lost revenue, failed recovery, and — in the worst cases — the enterprise's survival.

This lesson examines business continuity and disaster recovery in detail. It establishes why the disciplines matter and what happens in their absence. It distinguishes them from incident response and from each other. It examines business impact analysis — the process through which the enterprise identifies its critical functions and the consequence of their disruption. It examines recovery objectives — recovery time objective, recovery point objective, maximum tolerable downtime, and the other parameters that define what recovery must achieve. It examines business continuity planning — the strategies, procedures, and resources through which the enterprise maintains critical functions during disruption. It examines disaster recovery planning — the strategies, procedures, and technologies through which the enterprise restores its systems and infrastructure. It examines recovery strategies and technology — from backup and restore through to active-active architectures. It examines backup and restoration — the foundation of recovery capability. It examines testing and exercising — the practice that determines whether the plans work. It examines governance, maintenance, and coordination — the disciplines that keep continuity and recovery capability current. And it closes with the pitfalls that recur across BC/DR programmes.

The material here builds directly on Lesson 6.7 (incident response) — which is the security discipline that feeds into continuity and recovery — and on Unit 5, which examined the infrastructure and platform resilience that recovery depends on. It prepares for Lesson 6.9 (cyber resilience and enterprise recovery), which addresses the enterprise's ability to withstand and recover from disruption more broadly, and for Lesson 6.10, which examines emerging trends including the evolving resilience landscape.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 6 outcomes U6.6 (resilience) and U6.5 (incident response planning), and to Module 3 outcomes M3.5 and M3.6. See the Unit 6 learning outcomes page for the full mapping.

02 Why business continuity and disaster recovery matter

Business continuity and disaster recovery matter because disruption is inevitable — from cyber attacks, from technology failure, from natural events, from human error, from supply-chain failure. The question is not whether the enterprise will experience disruption; it is whether the enterprise can continue operating while the disruption persists, and whether it can restore its systems and services afterwards.

What BC/DR failure looks like

BC/DR failures are recognisable, and the patterns repeat:

• No business impact analysis. The enterprise does not know which functions are critical, what they depend on, or what the consequence of their disruption would be — so continuity and recovery priorities are guesswork.
• No recovery objectives. Recovery time objective and recovery point objective are undefined or unachievable — so the recovery capability is not aligned with business requirements.
• Backups not verified. Backups are taken but never tested for restoration — and are frequently found to be incomplete, corrupted, or un-restorable when needed.
• Backups compromised with the environment. Backups stored on the same network, with the same credentials, and accessible from the same systems as the production environment — so they are encrypted, deleted, or corrupted by the same attack.
• Plans never tested. Continuity and recovery plans exist on paper but have never been exercised — so the first time they are used is during a real disruption.
• Recovery takes far longer than planned. Recovery times measured in hours are planned; recovery times measured in days or weeks are experienced — because the plan was theoretical rather than tested.
• No manual workarounds. The business has no defined way to operate manually while systems are unavailable — so operations stop entirely.
• No communication. Employees, customers, and suppliers do not know what is happening, what to do, or when service will be restored.
• Dependencies unknown. The enterprise discovers during the disruption that critical functions depend on systems, suppliers, or people it had not identified.
• Plans are out of date. The plans describe systems, processes, and organisations that no longer exist — because they were written years ago and never maintained.

03 What business continuity and disaster recovery are — and are not

Business continuity and disaster recovery are frequently conflated with each other and with incident response and crisis management. The distinctions matter because each discipline addresses a different problem, is owned by a different function, and requires a different type of preparation.

The disciplines distinguished

The disciplines are related and operate together during a significant disruption:

• Incident response addresses the security dimensions — detecting, containing, eradicating, and recovering from the attack.
• Business continuity addresses the operational dimensions — keeping the business functioning while systems are unavailable or degraded.
• Disaster recovery addresses the technology dimensions — restoring systems and data after disruption.
• Crisis management addresses the strategic and reputational dimensions — coordinating the enterprise's response and managing external communication.
• Emergency management addresses the safety and physical dimensions — where the disruption has physical consequences.

Business continuity and disaster recovery distinguished

Business continuity and disaster recovery are frequently treated as a single discipline — "BC/DR" — but they are distinct:

In practice, the two are inseparable: business continuity defines the recovery objectives that disaster recovery must meet; disaster recovery provides the technology restoration that business continuity depends on. The distinction is useful for clarity of ownership and planning — but the two are managed together as a single capability.

Common misconceptions about BC/DR

Characteristics of effective BC/DR

• Business-driven. Priorities are derived from business impact analysis — not from technical preference or from what is easiest to recover.
• Risk-based. The BC/DR strategy is aligned with the enterprise's risk assessment — addressing the disruption scenarios that matter most.
• Documented. Plans, procedures, recovery objectives, and dependencies are documented and accessible.
• Tested. The capability is exercised regularly — through tabletop exercises, component testing, and full-scale tests.
• Maintained. Plans and capabilities are reviewed and updated as the business and technology change.
• Owned. Named owners for the BC/DR programme, for the business continuity plans, and for the disaster recovery plans.
• Integrated. BC/DR integrates with incident response, with risk management, with third-party management, and with the enterprise's governance framework.
• Proportionate. The investment in BC/DR is proportionate to the consequence of disruption — not uniform across all systems and functions.
• Reported. The BC/DR capability, its testing, and its readiness are reported to the board and executive.
• Improving. Lessons from tests and from real disruptions feed into continuous improvement.

04 Business impact analysis

Business impact analysis (BIA) is the foundation of BC/DR. It identifies the enterprise's critical functions, the consequence of their disruption over time, and the dependencies on which they rely. Everything else in BC/DR depends on the BIA — the recovery objectives, the continuity strategies, the recovery strategies, and the priorities.

What the BIA determines

• Critical business functions. What the business does that must continue — the processes, services, and activities whose disruption would have significant consequence.
• Impact over time. How the consequence of disruption increases over time — the difference between an outage of one hour, one day, one week, and one month.
• Dependencies. What each critical function depends on — systems, data, people, facilities, suppliers, and other functions.
• Recovery priorities. Which functions must be restored first — based on the consequence of their disruption.
• Minimum acceptable service levels. What level of service is acceptable during disruption — which may be less than normal but more than zero.
• Resource requirements. What resources are required to maintain each function during disruption and to restore it afterwards.

The BIA process

05 Recovery objectives

Recovery objectives define what recovery must achieve. They translate the business impact analysis into measurable targets — how quickly systems must be restored, how much data loss is acceptable, and how long the enterprise can survive before the consequence becomes unacceptable.

The principal recovery objectives

Recovery Time Objective (RTO)

The maximum acceptable time between the disruption and the restoration of the function or system — how long the business can operate without it before the consequence becomes unacceptable. RTO is expressed in hours or days, and is measured from the moment of disruption to the moment the function is available at the required level of service.

Recovery Point Objective (RPO)

The maximum acceptable amount of data loss, measured in time — how much data can be lost before the consequence becomes unacceptable. An RPO of one hour means the enterprise can tolerate the loss of up to one hour of data. RPO determines the frequency of backup and the replication approach required.

Maximum Tolerable Downtime (MTD)

The total time the business can tolerate the disruption of a function before the consequence becomes unacceptable — including the time required to detect the disruption, to invoke continuity, and to recover. MTD is the outer limit; RTO is the target within it.

Maximum Tolerable Period of Disruption (MTPD)

A term used in ISO/IEC 22301 for the same concept as MTD — the maximum time the disruption of a function can be tolerated before the consequence becomes unacceptable.

Minimum Business Continuity Objective (MBCO)

The minimum level of service that must be maintained during disruption — expressed in terms of service capacity, coverage, or functionality. The MBCO defines what continuity must deliver while recovery is ongoing.

Recovery Time Actual (RTA)

The actual time taken to restore the function or system — measured during testing or during a real disruption. The RTA is compared with the RTO to determine whether the recovery capability meets the requirement.

The relationship between the objectives

The relationship is: the MTD defines the outer bound; the RTO defines the recovery target within it; the RPO defines the acceptable data loss; and the MBCO defines what continuity must deliver while recovery is ongoing. All four are derived from the business impact analysis — from the business's assessment of the consequence of disruption.

Deriving recovery objectives

Recovery objectives are derived from the business impact analysis:

• MTD from impact over time. The point at which the impact of disruption becomes unacceptable — the point at which the enterprise can no longer operate or can no longer meet its obligations.
• RTO within the MTD. The RTO must be less than the MTD — because the MTD includes detection and invocation time, which are not part of recovery. In practice, RTO is frequently 50–75% of MTD, leaving time for detection and for the recovery to be verified.
• RPO from data consequence. The amount of data loss the business can tolerate — determined by the consequence of losing transactions, records, or messages.
• MBCO from minimum service requirements. The minimum service the business requires during disruption — determined by what customers, regulators, and operations require.
• Validated with the business. Recovery objectives are agreed with the business owners — not set by the technology function alone.
• Reviewed periodically. The business changes; the recovery objectives must change with it.

Setting achievable objectives

Recovery objectives are frequently aspirational rather than achievable. The consequence is that the recovery capability is planned against objectives it cannot meet — and the gap is discovered during a real disruption.

Setting achievable objectives requires understanding the cost of meeting them:

The recovery objectives should reflect the consequence of disruption — and the cost of meeting them should be proportionate to that consequence. The objective is not to meet the same RTO and RPO for every system; it is to meet the objectives appropriate to each system's criticality.

Common failures in setting recovery objectives

• Objectives set by technology alone. The technology function sets RTO and RPO without business input — producing objectives that are technically convenient rather than business-appropriate.
• Objectives that are aspirational rather than achievable. An RTO of fifteen minutes is set for a system that can only be restored in four hours — producing a gap that is not discovered until the disruption.
• Uniform objectives across all systems. The same RTO and RPO applied to every system — producing over-investment in non-critical systems and under-investment in critical ones.
• No validation of achievability. The objectives are set without testing whether the recovery capability can meet them — so the gap is discovered during a real disruption.
• No consideration of dependencies. The RTO for a critical system is set, but the systems it depends on have longer RTOs — so the critical system cannot be restored within its objective.
• Objectives not maintained. The objectives are set once and never reviewed — despite the business and technology changing continuously.

06 Business continuity planning

Business continuity planning defines how the enterprise will maintain its critical functions during disruption. It addresses the business dimensions — processes, people, facilities, suppliers — and the manual arrangements through which the enterprise continues to operate while technology is unavailable.

Elements of a business continuity plan

Continuity strategies

Continuity strategies determine how each critical function will be maintained. The principal approaches:

Manual workarounds

Manual workarounds are the most common continuity strategy — and the most frequently neglected. Where the technology is unavailable, the business must be able to operate manually:

• Documented procedures. The manual procedure must be documented — step by step, in a form that can be followed by staff who do not perform the task routinely.
• Forms and templates. The paper or offline forms on which the manual work will be recorded — prepared in advance and stored where they can be accessed when the systems are unavailable.
• Additional staffing. Manual processes frequently require more staff than the automated process — particularly where the volume is high.
• Controls. Manual processes must maintain the controls that the automated process provided — segregation of duties, approval, and oversight. Skipping controls during disruption creates risk and frequently creates compliance failures.
• Reconciliation. The manual work must be reconciled into the systems when they are restored — a process that must be planned and resourced, not improvised.
• Duration. The manual workaround must be sustainable for the duration of the disruption — which may be longer than anticipated.
• Testing. The manual workaround must be tested — through exercises where staff perform the manual process and verify that it works.

Alternate arrangements

Alternate arrangements provide substitutes for the resources the function depends on:

• Alternate locations. Where staff will work if the primary facility is inaccessible — a secondary office, a work-from-home arrangement, or a contracted alternate site. The alternate location must be equipped, accessible, and ready.
• Alternate communications. How staff will be contacted and how they will communicate if the primary systems are unavailable — mobile phones, personal email, or a contracted notification service.
• Alternate technology. Which systems can substitute for those that are unavailable — including cloud services, manual systems, or third-party services.
• Alternate suppliers. Which suppliers can substitute for those that are unavailable — with the arrangements in place before they are needed.
• Alternate data access. How the data required for the function will be accessed without the primary systems — offline copies, printed reports, or cached data.
• Alternate people. Who can substitute for key individuals — through cross-training, through documented procedures, or through contracted support.

Dependencies and single points of failure

Continuity planning addresses the dependencies identified in the BIA — and particularly the single points of failure:

• Single points of failure. A dependency where the failure of one component disrupts the entire function — a single system, a single supplier, a single individual, or a single facility.
• Key person dependencies. Functions that depend on specific individuals — who may be unavailable, who may leave, or who may be unreachable during a disruption.
• Supplier concentration. Functions that depend on a single supplier — who may fail, may be unable to provide the service during a wider disruption, or may themselves be affected by the incident.
• Geographic concentration. Functions and resources concentrated in a single location — where a single event (natural disaster, power outage, or facility loss) can disrupt them all simultaneously.
• Technology concentration. Functions that depend on a single system or platform — which becomes a single point of failure for all of them.
• Mitigation. Single points of failure are mitigated through redundancy, through diversification, through cross-training, and through documented procedures that reduce dependence on specific individuals.

07 Disaster recovery planning

Disaster recovery planning defines how the enterprise will restore its technology and infrastructure after disruption. It addresses the technology dimensions — systems, applications, data, and infrastructure — and the recovery objectives that the business impact analysis established.

Elements of a disaster recovery plan

Recovery priorities

Recovery priorities determine the order in which systems are restored. Priorities are derived from:

• Business criticality. The systems that support the most critical business functions are restored first — based on the business impact analysis.
• Recovery time objectives. Systems with shorter RTOs are restored first — because the business can tolerate their disruption for less time.
• Dependencies. Systems that other systems depend on are restored before the systems that depend on them — infrastructure before applications, identity before services.
• Recovery complexity. Systems that take longer to restore may need to be started earlier — even if their RTO is longer — because the restoration itself takes time.
• Resource constraints. Where resources are limited, the priority determines the allocation — but the priority must be derived from business need, not from technical convenience.
• Verification requirements. Systems that require extensive verification before being returned to service may need to be restored earlier to allow time for verification.

Recovery procedures

Recovery procedures must be documented in sufficient detail to be followed under pressure:

• Prerequisites. What must be in place before the procedure can begin — access, credentials, backups, infrastructure.
• Steps. The step-by-step procedure — with specific commands, configurations, and settings where appropriate.
• Decision points. Where the procedure branches, and on what basis the decision is made.
• Verification. How the restoration is verified — what to check, and what constitutes success.
• Rollback. What to do if the restoration fails — the procedure for returning to the prior state.
• Escalation. Who to contact if the procedure cannot be completed as documented.
• Dependencies. What must be completed before this procedure can begin — the systems and services this procedure depends on.
• Time estimates. How long each step and the procedure as a whole should take — so that progress can be tracked against the RTO.

Documentation requirements

Recovery documentation must be accessible when the primary systems are unavailable:

• Offline copies. Printed or offline copies of critical recovery documentation — so that it is available when the systems are not.
• Secure storage. The documentation must be stored securely — it contains information that would be useful to an adversary.
• Current. The documentation must be current — outdated recovery procedures are worse than no procedures.
• Accessible. The documentation must be accessible to the people who will use it — at the location and in the form they will need.
• Version controlled. The documentation must be version controlled — so that the current version is unambiguous.
• Distributed. Copies must be held by the recovery team — so that the documentation is not lost with the systems it describes.

Cloud and third-party considerations

Where the enterprise depends on cloud services and third parties, the disaster recovery plan must address:

• Provider disaster recovery. The provider's own recovery capability and commitments — what the contract guarantees, and what it does not.
• Provider outage. What happens when the provider's service is unavailable — how the enterprise continues to operate, and how it recovers.
• Provider compromise. What happens when the provider's environment is compromised — how the enterprise protects its data and its access.
• Multi-cloud and multi-region. Where the enterprise uses multiple providers or regions, how the failover between them is managed.
• Data portability. The ability to retrieve the enterprise's data from the provider — and the format in which it is provided.
• Contractual protections. The contractual provisions that support recovery — service levels, notification obligations, assistance commitments, and termination rights.
• Exit planning. The plan for moving away from the provider if required — including data retrieval, service transition, and timeline.

08 Recovery strategies and technology

Recovery strategies determine how the enterprise will restore its systems and infrastructure. The strategies range from simple backup and restore through to active-active architectures — with cost increasing substantially as recovery time and data loss decrease.

The recovery strategy spectrum

Data replication strategies

• Backup and restore. Data is backed up periodically and restored when required. The RPO is determined by the backup frequency.
• Asynchronous replication. Data is replicated to a secondary location with a delay — the RPO is the replication lag. Suitable for longer distances and where some data loss is acceptable.
• Synchronous replication. Data is written to both primary and secondary locations simultaneously — the RPO is near-zero. Suitable where no data loss is acceptable, but limited by distance and by performance impact.
• Continuous data protection. Every change is captured and can be restored to any point in time. Provides very low RPO but requires significant storage and processing.
• Snapshot replication. Point-in-time copies of data are taken periodically and replicated. The RPO is the snapshot frequency.
• Log shipping. Transaction logs are shipped to the secondary location and applied. The RPO is the shipping frequency.

Selecting recovery strategies

The appropriate recovery strategy depends on the recovery objectives, the criticality of the system, and the cost:

• Derive from the BIA. The recovery objectives come from the business impact analysis — the strategy is selected to meet them.
• Match cost to consequence. The investment in recovery capability should be proportionate to the consequence of disruption.
• Diversify by system. Different systems require different strategies — the same RTO and RPO are not appropriate for every system.
• Consider dependencies. A system with a short RTO that depends on systems with longer RTOs cannot be restored within its objective — dependencies must be considered.
• Consider the threat. The recovery strategy must address the scenarios in the risk assessment — including the scenarios where the primary and secondary are affected simultaneously.
• Consider operational complexity. A complex recovery strategy requires more rehearsal and more skill to execute successfully under pressure.
• Test the strategy. The strategy is only proven when it has been tested — assumptions about recovery time and data loss must be verified.

The cloud and recovery

Cloud services have changed the recovery landscape — but have not eliminated the challenges:

• Infrastructure on demand. Cloud infrastructure can be provisioned in minutes rather than the weeks or months required for physical infrastructure — reducing the cost and time of recovery.
• Geographic distribution. Cloud services are available in multiple regions — permitting recovery in a different geography without building a secondary data centre.
• Managed services. Cloud providers offer managed backup, replication, and disaster recovery services — reducing the enterprise's operational burden.
• But: provider dependence. The enterprise's recovery depends on the provider's availability — and the provider's outage affects all of its customers simultaneously.
• But: configuration complexity. Cloud recovery requires configuration — identity, networking, security, and data — which must be documented and tested.
• But: data egress cost. Restoring large volumes of data from the cloud can be slow and expensive — and the egress cost may be significant.
• But: shared responsibility. The provider is responsible for the cloud; the enterprise is responsible for what it puts in the cloud — including its recovery configuration.

Recovery for different platform types

09 Backup and restoration

Backup and restoration is the foundation of recovery capability. Every recovery strategy depends on the ability to restore data — and the most common cause of extended recovery in documented incidents is that backups could not be restored when they were needed.

Backup fundamentals

• What to back up. Data, configurations, applications, and system state — with a defined scope for each system.
• How often. Determined by the RPO — the amount of data loss the business can tolerate.
• Where to store. Offsite and offline — so that the backups survive the incident that affects the production environment.
• How long to retain. Determined by regulatory requirements, by contractual obligations, and by the scenarios the enterprise is protecting against.
• How to verify. Backups must be verified — through integrity checks, through periodic test restorations, and through verification that the restored data is complete and correct.
• Who is responsible. A named owner for the backup capability — and a named owner for the restoration procedure.

The 3-2-1 rule

The 3-2-1 rule is the classic backup principle — now frequently extended to 3-2-1-1-0:

• 3 copies of the data. The production data plus at least two backups — so that a single failure or corruption does not destroy all copies.
• 2 different media types. Backups on at least two different storage technologies — so that a vulnerability in one technology does not affect all copies.
• 1 copy offsite. At least one backup stored in a different location — so that a physical event affecting the primary site does not destroy all copies.
• 1 copy offline or immutable. At least one backup that cannot be modified or deleted — so that ransomware or a destructive attack cannot encrypt or destroy it.
• 0 errors on verification. The backups are verified — through test restorations — so that the enterprise knows the backups can actually be restored.

Immutable and air-gapped backup

Ransomware has made immutable and air-gapped backup essential. Where the adversary can reach the backups, they can destroy them — and the enterprise's recovery capability with them.

• Immutable backup. Backups that cannot be modified or deleted for a defined period — through write-once storage, through object lock, or through the backup platform's own immutability features.
• Air-gapped backup. Backups stored on media that is physically disconnected from the network — so that no network-based attack can reach them.
• Offline copies. Copies stored offline — on tape, on removable media, or in an offline cloud account — for the most critical systems.
• Separate credentials. Backup infrastructure should use separate credentials from the production environment — so that compromise of production credentials does not provide access to backups.
• Separate network. Backup infrastructure should be segmented from the production network — so that lateral movement from production cannot reach the backup infrastructure.
• Monitoring. The backup infrastructure should be monitored — so that failed backups, deleted backups, or unusual backup activity are detected.

Restoration capability

Backup is only half the capability — restoration is the other half:

• Documented restoration procedures. The step-by-step procedure for restoring each system — with prerequisites, steps, verification, and escalation.
• Tested restoration. The restoration procedure must be tested — through periodic test restorations, through full-scale recovery exercises, and through validation that the restored data is correct.
• Restoration environment. The infrastructure to which the backups will be restored — whether production, alternate infrastructure, or cloud — must be available and configured.
• Restoration time. The time required to restore each system — measured during testing — must be consistent with the RTO.
• Restoration skills. The people who will perform the restoration must have the skills — and must be available when needed.
• Restoration coordination. The restoration of dependent systems must be coordinated — so that systems are restored in the correct order.
• Restoration verification. The restored system must be verified — through testing, through data validation, and through user confirmation.

Backup failures that recur

• Backups that were never verified. The backups were taken but never tested for restoration — and were found to be incomplete, corrupted, or un-restorable when needed.
• Backups encrypted by ransomware. The backups were accessible from the production environment — and were encrypted along with the production data.
• Backups deleted by the attacker. The attacker gained access to the backup infrastructure — and deleted the backups before deploying the ransomware.
• Backup window exceeded. The backup did not complete within the window — so the most recent backup is older than expected.
• Restoration slower than expected. The restoration took far longer than planned — because the restoration procedure had never been tested.
• Incomplete restoration. The backup contained only part of what was needed — because the backup scope was inadequate.
• Data corruption. The backup contained corrupted data — because the corruption occurred before the backup was taken.
• No backup of the backup infrastructure. The infrastructure required to restore the backups — the backup servers, the catalogue, the configuration — was itself lost.

Backup for specific scenarios

10 Testing and exercising

Testing and exercising is what converts a BC/DR plan into a BC/DR capability. The plan describes what should happen; the exercise demonstrates whether it does. And the exercise frequently reveals that it does not — which is precisely the point.

Types of exercise

The exercise programme

An effective exercise programme combines multiple exercise types across the year:

• Regular component testing. Individual components — backup restoration, failover, alternate site activation — tested on a defined schedule, frequently and routinely.
• Periodic tabletop exercises. Conducted at least annually for each plan — engaging the business, technology, and executive participants.
• Annual full-scale exercise. At least one exercise per year that tests the complete capability — from detection through recovery — with actual failover where feasible.
• Scenario diversity. Exercises cover a range of scenarios — ransomware, data-centre loss, supplier failure, key person unavailability — so that the enterprise is prepared for different types of disruption.
• Executive participation. Executive leadership participates in at least some exercises — particularly those testing the decisions that require executive authority.
• Business participation. The business participates in continuity exercises — testing the manual workarounds, the alternate arrangements, and the communication.
• External participation. Where external parties are part of the response — suppliers, cloud providers, external specialists — they participate in exercises where feasible.
• Progressive difficulty. The exercise programme increases in difficulty over time — building capability and confidence.
• Documentation. Every exercise is documented — what was tested, what was found, what worked, and what did not.
• Action tracking. Findings from exercises are tracked to closure — as rigorously as audit findings.

What exercises reveal

Exercises frequently reveal that the plan does not work as written:

• Contact information is out of date. The people who need to be contacted have changed roles, changed numbers, or left the enterprise.
• Dependencies are unknown or underestimated. The restoration of one system depends on another that no one had identified.
• Recovery takes longer than planned. The restoration that was estimated at four hours takes twelve — because the estimate was theoretical.
• Procedures are incomplete or unclear. Steps are missing, or the procedure assumes knowledge that the people executing it do not have.
• Roles and authority are unclear. No one is sure who is in charge, who makes decisions, or who escalates.
• Manual workarounds do not work. The manual process is impractical, the forms are missing, or the controls cannot be maintained.
• Alternate arrangements are not ready. The alternate site is not equipped, the alternate supplier cannot deliver, or the alternate communications do not reach the people who need them.
• Backups cannot be restored. The backups are incomplete, corrupted, or in an unusable format.
• Coordination fails. The teams do not communicate — the technology team does not know what the business needs, and the business does not know what the technology team is doing.
• Verification is inadequate. The restored system is returned to service before it is verified — and the failure recurs.

Designing effective exercises

• Define the objective. What the exercise is intended to test — the specific capability, decision, or coordination.
• Design the scenario. A realistic scenario that exercises the objective — not so extreme that it is implausible, not so mild that it tests nothing.
• Involve the right participants. The people who would be involved in a real disruption — including the business, technology, and executive leadership.
• Create a safe environment. Participants must feel able to make mistakes, to raise concerns, and to identify problems without consequence.
• Inject realism. The exercise should include the complications of a real incident — incomplete information, time pressure, and competing priorities.
• Observe and document. Observers document what happens — what works, what does not, and what is unclear.
• Conduct a debrief. Immediately after the exercise — what was tested, what was found, and what should change.
• Produce actionable findings. The exercise produces specific, owned, and tracked actions — not merely observations.
• Feed back into the plan. The plan is updated based on what the exercise revealed — and the next exercise tests the updated plan.
• Build capability over time. The exercise programme is sustained — not a one-off event — so that the enterprise's capability improves continuously.

Testing frequency

11 Governance, maintenance, and coordination

BC/DR capability degrades continuously — the business changes, the technology changes, the people change, and the plans become progressively less accurate. Governance and maintenance are what keep the capability current.

Governance

• Executive ownership. A named executive is accountable for the BC/DR programme — typically the COO, the CRO, or the CIO.
• Programme ownership. A named individual leads the BC/DR programme — coordinating the business continuity planning, the disaster recovery planning, and the testing.
• Plan ownership. Each business continuity plan and each disaster recovery plan has a named owner — accountable for its content, its currency, and its testing.
• Governance forum. A committee or forum where BC/DR is governed — reviewing the programme, the testing, the findings, and the improvement actions.
• Board oversight. The board receives regular reporting on BC/DR capability — the testing conducted, the findings, the remediation, and the enterprise's readiness.
• Policy. A BC/DR policy that defines the programme, the responsibilities, the requirements, and the governance.
• Integration with risk management. BC/DR is integrated with the enterprise risk management framework — the disruption scenarios in the risk register inform BC/DR planning, and BC/DR findings inform the risk register.
• Integration with incident response. BC/DR is integrated with incident response — the incident response plan defines when continuity is invoked, and the continuity plan defines what happens while the incident is being resolved.
• Audit and assurance. BC/DR is subject to independent audit — verifying that the capability exists, that it is tested, and that the testing produces improvement.

Maintenance

BC/DR plans and capabilities must be maintained — the enterprise changes continuously:

• Scheduled review. Plans are reviewed on a defined schedule — at least annually — and updated for changes in the business, the technology, and the organisation.
• Change-triggered review. Plans are reviewed when material change occurs — a new system, a new supplier, a reorganisation, a change in the recovery objectives, or a change in the threat landscape.
• Exercise-triggered review. Plans are reviewed after every exercise — updating them based on what the exercise revealed.
• Incident-triggered review. Plans are reviewed after every real disruption — updating them based on what the response revealed.
• Contact information. Contact information is verified regularly — through call tree tests and through review of the contact lists.
• Dependency review. Dependencies are reviewed as systems and suppliers change — ensuring that the dependency map reflects the current reality.
• Recovery objective review. Recovery objectives are reviewed as the business changes — ensuring that the RTO and RPO remain appropriate.
• Version control. Plans are version controlled — so that the current version is unambiguous and so that changes can be tracked.

Coordination with adjacent disciplines

Board and executive reporting

BC/DR reporting should provide the board and executive with the information they need:

• Readiness. Whether the enterprise is prepared — the status of plans, the status of testing, and the status of remediation.
• Testing results. What was tested, what was found, and what was remediated.
• Recovery capability. The enterprise's actual recovery capability — the measured recovery time for critical systems.
• Gaps and remediation. Where the capability falls short of the requirement — and the plan for closing the gap.
• Investment. The investment in BC/DR capability — and the investment required to meet the recovery objectives.
• Risk acceptance. Where the enterprise has accepted gaps in its recovery capability — with the rationale and the authority.
• Integration. How BC/DR integrates with incident response, with risk management, and with the enterprise's governance.
• Trends. Whether the capability is improving — and the actions being taken.

Maturity

12 Common pitfalls

BC/DR programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — No business impact analysis

Operating without a business impact analysis — so the enterprise does not know which functions are critical, what they depend on, or what the consequence of their disruption would be.

Mitigation: Conduct a business impact analysis. Involve the business. Assess impact over time. Identify dependencies. Define recovery objectives. Maintain the analysis as the business changes.

Pitfall 2 — Recovery objectives unachievable

Setting recovery objectives the recovery capability cannot meet — and not discovering it until the disruption.

Mitigation: Validate recovery objectives against the actual recovery capability. Test the capability. Where the objective cannot be met, either invest to meet it or document the acceptance of the gap.

Pitfall 3 — Backups not tested

Backups taken but never tested for restoration — and found to be incomplete, corrupted, or un-restorable when needed.

Mitigation: Test restoration regularly. Verify the integrity of backups. Document the restoration procedure. Measure the restoration time.

Pitfall 4 — Backups accessible from production

Backups stored on the same network, with the same credentials, and accessible from the same systems as production — so they are encrypted, deleted, or corrupted by the same attack.

Mitigation: Implement immutable or air-gapped backup. Use separate credentials. Segment the backup infrastructure. Monitor backup activity.

Pitfall 5 — Plans never tested

Continuity and recovery plans exist on paper but have never been exercised — so the first time they are used is during a real disruption.

Mitigation: Establish an exercise programme. Conduct regular component tests, tabletop exercises, and full-scale exercises. Track findings to closure.

Pitfall 6 — No manual workarounds

The business has no defined way to operate manually while systems are unavailable — so operations stop entirely.

Mitigation: Document manual workarounds. Prepare the forms and templates. Train the staff. Test the workarounds. Plan the reconciliation.

Pitfall 7 — Dependencies unknown

The enterprise discovers during the disruption that critical functions depend on systems, suppliers, or people it had not identified.

Mitigation: Map dependencies comprehensively. Update the dependency map as systems and suppliers change. Address single points of failure.

Pitfall 8 — No communication

Employees, customers, and suppliers do not know what is happening, what to do, or when service will be restored.

Mitigation: Define the communication arrangements. Prepare the templates. Establish the channels. Test the communication as part of the exercise programme.

Pitfall 9 — Plans out of date

Plans describe systems, processes, and organisations that no longer exist — because they were written years ago and never maintained.

Mitigation: Review plans at least annually. Trigger reviews on change. Update after every exercise and every incident. Version control the plans.

Pitfall 10 — Recovery capability assumed

The recovery capability is assumed to exist because the plans exist — without testing whether the plans actually work.

Mitigation: Test the capability. Measure the recovery time. Verify the recovery point. Document the actual capability, not the assumed capability.

Pitfall 11 — BC/DR disconnected from incident response

Incident response and BC/DR operating independently — so that the business is not supported during the response and the response is not informed by operational priorities.

Mitigation: Integrate incident response and BC/DR. Define the coordination. Exercise them together. Establish unified command for significant incidents.

Pitfall 12 — No executive sponsorship

The BC/DR programme lacks executive sponsorship — so it is not resourced, not prioritised, and not taken seriously by the business.

Mitigation: Secure executive sponsorship. Report to the board. Integrate BC/DR with the enterprise risk framework. Make the business accountable for its own continuity.

Pitfall 13 — Testing deferred for operational reasons

Testing is deferred because of operational pressure, because the plan is not ready, or because the last exercise was inconvenient — so the capability is never validated.

Mitigation: Schedule testing in advance. Treat testing as mandatory. Use non-disruptive test methods where full-scale tests are impractical. Track testing completion as a programme metric.

Pitfall 14 — Recovery verification inadequate

Systems are returned to service before the recovery is verified — so the failure recurs, or the restored system does not function correctly.

Mitigation: Define the verification procedure. Verify before returning to service. Include user verification. Monitor closely after restoration.

13 Key concepts

The terms below are used throughout Unit 6. Capture them in your own words as you work through the lesson.

Business continuity

The discipline of maintaining critical business functions at acceptable levels during disruption — addressing processes, people, facilities, and suppliers.

Disaster recovery

The discipline of restoring technology infrastructure and services after disruption — addressing systems, applications, data, and infrastructure.

Business impact analysis (BIA)

The process of identifying critical business functions, assessing the impact of their disruption over time, and identifying their dependencies — the foundation of BC/DR.

Critical business function

A process, service, or activity whose disruption would have significant consequence for the enterprise — requiring continuity and recovery planning.

Dependency

Something a critical function relies on — a system, a supplier, a facility, a person, or another function — whose unavailability would disrupt the function.

Single point of failure

A dependency where the failure of one component disrupts the entire function — a single system, supplier, individual, or facility.

Recovery Time Objective (RTO)

The maximum acceptable time between disruption and restoration of the function or system — how long the business can operate without it.

Recovery Point Objective (RPO)

The maximum acceptable amount of data loss, measured in time — how much data can be lost before the consequence becomes unacceptable.

Maximum Tolerable Downtime (MTD)

The total time the business can tolerate the disruption of a function before the consequence becomes unacceptable — the outer bound that includes detection and invocation time.

Minimum Business Continuity Objective (MBCO)

The minimum level of service that must be maintained during disruption — what continuity must deliver while recovery is ongoing.

Recovery Time Actual (RTA)

The actual time taken to restore the function or system — measured during testing or during a real disruption.

Business continuity plan

The documented plan for maintaining critical functions during disruption — including strategies, manual workarounds, alternate arrangements, resources, and communication.

Disaster recovery plan

The documented plan for restoring systems and infrastructure — including recovery procedures, priorities, alternate infrastructure, data restoration, and verification.

Manual workaround

A documented manual procedure through which a function is performed while systems are unavailable — including forms, controls, and reconciliation.

Alternate site

A secondary facility to which operations can relocate if the primary facility is unavailable — cold, warm, or hot depending on its readiness.

Cold site

An alternate facility with power, cooling, and connectivity but no pre-installed equipment — equipment is installed when required.

Warm site

An alternate facility with pre-installed hardware and some pre-configured systems — data and configuration are restored when required.

Hot site

An alternate facility that is fully equipped and operational, with data replication keeping it current — systems can be activated quickly.

Pilot light

A minimal version of the environment running continuously in the cloud — with the ability to scale up rapidly when required.

Warm standby

A scaled-down but fully functional version of the environment running continuously — with the ability to scale up.

Active-active

Systems running simultaneously in multiple locations, with traffic distributed between them and automatic failover — providing near-zero RTO and RPO.

Asynchronous replication

Data is replicated to a secondary location with a delay — the RPO is the replication lag.

Synchronous replication

Data is written to both primary and secondary locations simultaneously — the RPO is near-zero, limited by distance and performance impact.

3-2-1 rule

The backup principle: 3 copies of data, on 2 different media, with 1 copy offsite — extended in modern practice to include 1 copy offline or immutable and 0 errors on verification.

Immutable backup

Backups that cannot be modified or deleted for a defined period — protecting them from ransomware and destructive attacks.

Air-gapped backup

Backups stored on media that is physically disconnected from the network — so that no network-based attack can reach them.

Restoration

The process of recovering data and systems from backup — which must be tested, measured, and verified.

Tabletop exercise

A discussion-based exercise where the team walks through a scenario — testing the plan, the roles, and the decision-making without the pressure of a live environment.

Component test

Testing an individual component of the recovery capability — a backup restoration, a failover, or an alternate site activation.

Full-scale exercise

An exercise in which the enterprise activates its continuity and recovery capability — staff relocate, systems fail over, and operations continue through the plan.

Live failover

Failing over production systems to the alternate environment — with actual services running from the alternate — providing the most realistic test of recovery capability.

Call tree

The process through which team members are contacted during an incident — tested regularly to verify that the contact information is current.

ISO/IEC 22301

The international standard for business continuity management systems — certifiable, and the reference for BC/DR programme design.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 3. They are not graded, but completing them will substantially improve your preparation.

15 Self-check

Answer the questions below before moving to Lesson 6.9. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined business continuity and disaster recovery — the disciplines through which the enterprise maintains critical functions during disruption and restores its systems afterwards. The essential points are:

• Disruption is inevitable. The question is not whether the enterprise will experience disruption, but whether it can continue operating while the disruption persists and restore its systems afterwards.
• Business continuity and disaster recovery are distinct. Business continuity addresses the business dimensions — keeping critical functions operating; disaster recovery addresses the technology dimensions — restoring systems and infrastructure. They are related and operate together.
• Business impact analysis is the foundation. Identifying critical functions, assessing impact over time, and mapping dependencies — everything else in BC/DR depends on the BIA.
• Recovery objectives translate the BIA into targets. RTO, RPO, MTD, and MBCO define what recovery must achieve — and are derived from the business's assessment of the consequence of disruption.
• Business continuity planning defines how the business keeps operating. Continuity strategies, manual workarounds, alternate arrangements, resources, and communication.
• Disaster recovery planning defines how technology is restored. Recovery procedures, priorities, alternate infrastructure, data restoration, and verification.
• Recovery strategies range from backup and restore to active-active. Recovery time and data loss are purchased — the strategy should be proportionate to the consequence of disruption.
• Backup is the foundation of recovery. The 3-2-1 rule, immutable and air-gapped backup, and — critically — verified restoration.
• Testing converts plans into capability. Regular component tests, tabletop exercises, and full-scale exercises — with findings tracked to closure.
• Governance keeps the capability current. Ownership, maintenance, integration with risk and incident response, and board reporting.
• Common pitfalls recur. No BIA; unachievable recovery objectives; backups not tested; backups accessible from production; plans never tested; no manual workarounds; unknown dependencies; no communication; out-of-date plans; recovery capability assumed; BC/DR disconnected from incident response; no executive sponsorship; testing deferred; inadequate verification.

These ideas prepare for Lesson 6.9, which examines cyber resilience and enterprise recovery — the enterprise's broader ability to withstand and recover from disruption. Lesson 6.10 examines emerging trends, including the evolving resilience landscape and the implications for enterprise security.