1.7 Business Continuity & BIA
Business Continuity & BIA at a glance
Business Continuity is about ensuring that an organisation can continue delivering its most important products and services when disruption occurs.
The Business Impact Analysis helps determine what is critical, how quickly it must be recovered and which people, technology, facilities and suppliers those activities depend on.
Business Continuity
Maintain critical business activities during disruption.
What must keep working?Business Impact Analysis
Understand how disruption affects the organisation.
What happens if it stops?Recovery Requirements
Determine acceptable downtime and data loss.
How quickly must we recover?What is Business Continuity?
Organisations depend on processes, people, technology, facilities, suppliers and information.
Disruption to any of these can prevent the organisation from delivering important products and services.
Business Continuity focuses on preparing the organisation so that critical activities can continue, or be restored within acceptable timescales, following disruption.
The starting question is not: "Which servers should we recover first?"
The better question is: "Which business activities are most important, and what do they depend on?"
Disruptions can come from many sources
1 Business Continuity vs Disaster Recovery Related concepts with different focus
Business Continuity
Business Continuity focuses on maintaining or restoring critical business activities.
It considers:
Disaster Recovery
Disaster Recovery is more specifically concerned with recovering technology, infrastructure, systems and data following major disruption.
How does the organisation continue delivering critical services?
How do we recover the technology and data supporting those services?
A bank's main payment-processing system becomes unavailable.
Business Continuity considers how customers can continue making essential payments.
Disaster Recovery considers how the failed payment infrastructure and data will be restored.
Disaster Recovery supports Business Continuity.
Business Continuity is broader than IT recovery.
2 Business Impact Analysis Understand what matters before deciding how to recover it
What is a BIA?
A Business Impact Analysis examines important organisational functions and evaluates the consequences if those functions are disrupted.
It helps answer questions such as:
Which products, services and processes must the organisation continue delivering?
What financial, operational, legal, safety and reputational impacts occur?
Is one hour acceptable? Four hours? One day? One week?
Identify systems, people, facilities, information and external suppliers.
Establish business recovery requirements.
Determine acceptable data-loss requirements where relevant.
Recovery priorities should reflect business impact rather than which technology team shouts the loudest.
🔍 The BIA process A practical step-by-step approach
Understand the organisation's important products, services and processes.
Identify which activities are most important to organisational objectives.
Evaluate how the organisation would be affected if each process became unavailable.
Determine how consequences increase as disruption continues.
Determine which people, applications, infrastructure, facilities, information and suppliers support the activity.
Define appropriate downtime and data-loss objectives.
Use business impact to determine which activities and supporting resources should recover first.
Select continuity and recovery capabilities capable of meeting the identified business requirements.
3 Types of business impact Disruption is not measured only in money
A BIA considers how disruption could affect the organisation in different ways.
Lost revenue, compensation, additional operating costs or penalties.
Inability to deliver products, services or internal business processes.
Failure to meet statutory or contractual obligations.
Breach of sector-specific regulatory expectations.
Loss of customer, investor or public confidence.
Potential impact on human health or physical safety.
Customers may lose access to important products or services.
Disruption may prevent the organisation achieving long-term objectives.
A four-hour outage could be inconvenient for one system and catastrophic for another.
📈 Impact grows over time Duration matters
The impact of a disruption often becomes more severe the longer the process remains unavailable.
| Downtime | Example impact |
|---|---|
| 15 minutes | Minor inconvenience |
| 2 hours | Customer delays and operational backlog |
| 8 hours | Material revenue and service impact |
| 24 hours | Major customer, regulatory and operational consequences |
| Several days | Potentially severe organisational impact |
The question is not simply whether disruption is harmful.
The organisation needs to understand when the harm becomes unacceptable.
4 Maximum Tolerable Downtime — MTD How long can the business tolerate the disruption?
What is MTD?
Maximum Tolerable Downtime represents the maximum amount of disruption a business process can tolerate before the consequences become significantly harmful to the organisation.
"How long can this business activity be unavailable before the impact becomes unacceptable?"
A hospital determines that its patient-admission capability cannot be disrupted for more than four hours without creating unacceptable operational and safety consequences.
The continuity solution must therefore recover or replace that capability before that limit is reached.Maximum Allowable Outage
You may also encounter the term Maximum Allowable Outage (MAO) in continuity material.
Terminology can vary between frameworks and organisations, so always understand how the organisation defines the term rather than relying only on the acronym.
5 Recovery Time Objective — RTO How quickly should we restore the capability?
What is RTO?
Recovery Time Objective establishes the target recovery time for a system, service or capability following disruption.
"How quickly must we recover?"
A payment service has an RTO of two hours.
The organisation therefore needs a recovery capability designed to restore the required service within approximately that target.
RTO should fit inside business tolerance
A recovery objective should normally be established early enough that the organisation does not reach its maximum tolerable disruption.
Maximum tolerable disruption: 4 hours
Recovery target: 8 hours
The recovery design cannot satisfy the business requirement.6 Recovery Point Objective — RPO How much data can we afford to lose?
What is RPO?
Recovery Point Objective identifies the point in time to which data must be restored following disruption.
Practically, it describes how much recent data loss the organisation can tolerate.
"How far back can we afford to go?"
A system has an RPO of four hours.
If the system fails at 16:00, the organisation may need data available from approximately 12:00 or later.
Up to four hours of recent data may therefore need to be recreated or otherwise recovered.RPO influences backup design
If a business can tolerate only a few minutes of data loss, a backup performed once every 24 hours is unlikely to satisfy that requirement.
RPO = 15 minutes
Daily backup = potentially almost 24 hours of data loss
The technical recovery capability does not meet the business requirement.RTO vs RPO memory aid
RTO = TIME. RPO = DATA.
Visualising RPO, RTO and MTD
Imagine a critical system fails at 12:00.
👩💼 Technology recovery is not always business recovery Restoring the system may only be part of the job
Restoring a technical system does not necessarily mean the business process immediately returns to normal.
Employees may still need to:
- validate restored information;
- reconcile transactions;
- process accumulated backlogs;
- re-enter data captured manually;
- contact customers;
- verify system functionality;
- restore dependent business processes.
An ordering system is restored after four hours.
During the outage, 2,000 orders were recorded manually.
Employees require another two hours to enter and reconcile those transactions.
Technical restoration occurred before full business recovery.Some continuity methodologies use the term Work Recovery Time (WRT) for the additional time required after technical restoration to return business operations to an acceptable state.
Terminology and calculation methods vary between frameworks, so treat this as a useful planning concept rather than a universal formula.
7 Business dependencies A critical process rarely operates alone
Business processes depend on many supporting resources.
A good BIA identifies those dependencies rather than looking only at the business process itself.
Which employees, teams or specialist skills are required?
Which software systems support the process?
Which servers, networks, identity systems or cloud services are required?
Which data is necessary to operate?
Does the process depend on offices, warehouses, data centres or specialist locations?
Power, telecommunications, water or other utilities may be required.
Which external providers enable the process?
Which internal business activities must operate first?
Recovering an application is useless if the identity provider, database or telecommunications service it depends on remains unavailable.
8 External Dependencies A specific CISSP 1.7 focus
Organisations increasingly depend on external providers for critical capabilities.
Examples include:
The supplier may become part of your continuity risk
An organisation designs its own systems for extremely high availability.
However, customer authentication depends entirely on a single external identity provider.
If that provider fails, customers still cannot access the service.
The external identity provider is therefore a critical dependency.Questions to ask
If an external provider supports a critical business service, the organisation still needs to understand and manage the resulting continuity risk.
1️⃣ Single Points of Failure One dependency can undermine the whole service
What is a single point of failure?
A single point of failure is a component whose failure can cause a larger system or business process to fail because no effective alternative exists.
One database server with no redundant capability.
Only one employee knows how to perform a critical process.
A sole supplier provides an irreplaceable component.
All critical operations occur from one location.
A financial reconciliation process depends on one specialist employee who understands a complex legacy system.
That employee becomes unavailable for several weeks.
Cross-training and documented procedures may be continuity controls.🥇 Criticality and recovery priority Not everything can recover first
Organisations usually have limited recovery resources.
The BIA therefore helps prioritise which activities should recover first.
Tier 1 — Critical
Activities where even short disruption causes severe impact.
Tier 2 — High Priority
Important activities that can tolerate limited disruption.
Tier 3 — Medium Priority
Activities that can operate with longer interruption.
Tier 4 — Lower Priority
Activities that can be restored after critical services are stable.
Tier names vary by organisation.
The important principle is that recovery priority comes from business impact.
🏦 Worked example: online banking Follow a BIA from business process to recovery requirement
Customer payments and transfers.
Customers cannot move money, payments fail, complaints increase and financial and regulatory consequences grow over time.
Assume the business determines that disruption beyond four hours becomes unacceptable.
The organisation targets restoration within two hours.
Transaction data must be recoverable to within five minutes of the disruption.
Payment application, database, identity service, network, authentication infrastructure and operations staff.
Telecommunications, payment networks, cloud providers and other financial institutions.
Instead of saying "make the payment system highly available," the business has defined measurable recovery expectations that technology and suppliers can design against.
🛠️ Business Continuity strategies How can the organisation maintain critical activities?
Once the organisation understands its recovery requirements, it can select appropriate continuity strategies.
Duplicate critical resources to reduce single points of failure.
Provide another location from which important operations can continue.
Allow employees to continue operations when normal premises are unavailable.
Maintain essential functions when technology is unavailable.
Reduce dependence on a single external provider.
Reduce dependence on one specialist employee.
Ensure critical information can be recovered.
Design critical technology to minimise service interruption.
Extremely fast recovery usually requires greater investment.
The BIA helps justify that investment by showing the business impact of downtime.
💰 Recovery cost vs business impact Continuity is a business decision
Recovery capability has a cost.
Generally, demanding shorter recovery times and less data loss requires more resilient and expensive solutions.
RTO: 72 hours
The organisation may be able to use relatively inexpensive recovery arrangements.
RTO: 30 seconds
The organisation may require sophisticated high-availability, replication and automated failover capabilities.
Continuity investment should be aligned with business impact and risk.
Spending £5 million to provide near-zero downtime for an internal system whose three-day outage would cost the organisation £20,000 may not be economically reasonable.
📣 Communications and people Continuity is not only technology
A continuity plan may fail even when technology survives if people do not know what to do.
Continuity planning should consider:
Who makes decisions during disruption?
How will critical people be reached?
What happens if normal email or telephony is unavailable?
How will affected customers be informed?
How will external providers be coordinated?
Are any notification or communication obligations triggered?
📋 Business Continuity Plan Turn analysis into something people can use
The Business Continuity Plan documents how the organisation intends to maintain or recover critical operations following disruption.
A plan may include:
A 400-page document that nobody can locate or understand during an outage may provide little practical value.
🧪 Reviewing continuity assumptions Plans become outdated
Business processes and dependencies change over time.
A BIA performed several years ago may no longer reflect the organisation.
Review may be needed after:
A BIA identifies an internal database as a critical dependency.
Two years later the organisation migrates the entire service to SaaS but never updates the BIA.
The documented dependency no longer reflects reality.Business Continuity exercises help determine whether assumptions, procedures, people and dependencies actually work as expected.
Detailed BC and DR exercise types are covered later in the CISSP Security Operations domain.
⚠️ Common mistakes Continuity concepts people frequently confuse
Disaster Recovery focuses heavily on restoring technology and data. Business Continuity considers the wider organisation and its ability to continue critical activities.
RTO relates to recovery time. RPO relates to the acceptable recovery point for data.
RPO concerns data recovery. RTO concerns recovery time.
Recovery priority should be based on business impact and criticality, not simply technology cost.
Technology criticality should be derived from the business activities it supports.
The provider may recover its service, but the organisation remains responsible for understanding whether that recovery meets its own business requirements.
Backups address only part of recovery. People, facilities, applications, dependencies, communications and business processes must also be considered.
The business may still need to validate information, process backlogs and restore dependent activities.
Technology contributes to the process, but business owners are essential because they understand the business impact of disruption.
Start with the business, not the technology
Continuity questions frequently include technically attractive answers.
Before choosing a recovery technology, understand the business requirements established through the BIA.
📊 BIA clues
⏱️ Recovery clues
🔗 Dependency clues
📝 Practice scenarios Apply Business Continuity thinking
Scenario 1
An organisation wants to decide which applications should recover first after a major outage.
What should primarily drive the decision?
Business impact and criticality identified through the BIA.
Scenario 2
A business service must be restored within two hours.
Which concept does this describe?
Recovery Time Objective — RTO.
Scenario 3
A database can tolerate the loss of no more than 30 minutes of recent transactions.
Which concept does this describe?
Recovery Point Objective — RPO.
Scenario 4
A business process cannot remain unavailable for more than eight hours without causing significant harm.
Which concept does this describe?
Maximum Tolerable Downtime — MTD.
Scenario 5
A critical application has an RTO of four hours, but its external cloud provider contract promises recovery within 24 hours.
What is the problem?
The external dependency's recovery commitment does not meet the organisation's business recovery requirement.
Scenario 6
A security architect wants to purchase an expensive active-active infrastructure solution before the BIA has been completed.
What should happen first?
Determine the business continuity and recovery requirements before selecting the technical solution.
Scenario 7
A critical process depends on one employee who has unique knowledge and no replacement.
What has the BIA identified?
A personnel dependency and potential single point of failure.
Scenario 8
A system has an RPO of one hour but backups are taken only once every 24 hours.
What is wrong?
The backup strategy is unlikely to satisfy the required recovery point.
Scenario 9
An application has been restored, but employees need another three hours to process transactions accumulated during the outage.
What does this demonstrate?
Technical recovery and complete business recovery are not always the same point in time.
Scenario 10
A company outsources its entire customer-support platform.
Can it remove customer support from its BIA?
No. The supplier has become an external dependency supporting the business process.
Business Continuity thinking flow
Quick memory aid
Impact. Time. Data. Dependencies.
The three timing questions
MTD = Tolerance · RTO = Time · RPO = Data
Key takeaways
Business Continuity is about maintaining the organisation's critical business activities during disruption.
Business Continuity is broader than Disaster Recovery because it considers people, processes, facilities, suppliers and communications as well as technology.
The Business Impact Analysis identifies critical activities and evaluates the consequences of their disruption.
The BIA should consider financial, operational, legal, regulatory, reputational, customer and safety impacts.
Impact often becomes more serious as downtime increases.
MTD describes how much disruption the business process can tolerate before significant harm occurs.
RTO describes the target time for recovery.
RPO describes the point in time to which data must be recovered and therefore relates to acceptable data loss.
RTO = recovery time. RPO = recovery point.
Critical processes depend on people, applications, infrastructure, information, facilities and suppliers.
External dependencies are particularly important because an organisation may depend on services it does not directly control.
Recovery priorities should be based on business impact rather than technical preference.
Continuity solutions should be selected only after the organisation understands its recovery requirements.
Most importantly: start with the business requirement, then design the technology needed to meet it.
📚 Sources & Further Reading Authoritative references
- ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline - NIST IR 8286D — Using Business Impact Analysis to Inform Risk Prioritization and Response
View NIST publication - NIST — Business Impact Analysis Glossary
View BIA definition - NIST — Maximum Tolerable Downtime
View MTD definition - NIST — Recovery Time Objective
View RTO definition - NIST — Recovery Point Objective
View RPO definition