A business impact analysis should do more than identify which processes are “critical.” It should help the organization understand what happens when important work is interrupted, what that work depends on, how quickly it needs to recover, and which assumptions need to be resolved before recovery plans are built.
A business impact analysis, or BIA, evaluates the effects of disruption over time and establishes the business requirements that should guide recovery priorities.
MHA has facilitated BIAs across a wide range of organizations. One lesson is consistent: the value of the BIA is not the questionnaire itself. The value comes from turning operational knowledge into recovery decisions the organization can explain, validate, and use.
In short
- A BIA identifies the effects of disruption and establishes recovery priorities and requirements.
- It should capture important processes, impacts over time, technology, people, facilities, suppliers, data, and other dependencies.
- Recovery targets should be supported by business impact and validated assumptions, not copied from an older BIA.
- The BIA does not replace a risk assessment. The two answer different questions.
- BIA outputs should influence recovery strategies, continuity plans, technology recovery, exercises, and management decisions.
What Is a Business Impact Analysis?
A business impact analysis examines how disruption affects an organization's activities over time.
It helps answer questions such as:
- Which products, services, and business processes are most time-sensitive?
- What happens as those activities remain unavailable?
- How quickly does the organization need them restored?
- What people, technology, data, facilities, suppliers, and other resources do they depend on?
- What workarounds are available?
- How long can those workarounds realistically support operations?
- What gaps could prevent the organization from meeting its recovery requirements?
The BIA gives the business continuity program the business requirements needed to evaluate recovery strategies and capabilities.
What a BIA Does Not Do
A BIA and a risk assessment are related, but they are not interchangeable.
The BIA asks:
What happens if this operation is disrupted, and how quickly does it need to recover?
A risk assessment asks:
What could disrupt the operation, why is that scenario credible, and what exposure does it create?
A BIA can identify dependencies and conditions that deserve further risk analysis, but it does not replace the risk-assessment process.
For a deeper comparison, see BIA vs. Risk Assessment: What Each One Tells You.
What Information Should a BIA Capture?
The exact fields will vary by organization, but a useful BIA should collect enough information to support recovery decisions.
| BIA Input | What You Need to Understand |
|---|---|
| Process or activity | What the activity does, who owns it, and what business outcome it supports |
| Impacts over time | How operational, financial, customer, legal, regulatory, safety, or reputational consequences change as the disruption continues |
| Recovery requirements | When the activity needs to resume and what level of service is required |
| Technology | Applications, infrastructure, data, communications, integrations, and other technology required |
| People | Required staffing, specialized knowledge, key roles, alternates, and access requirements |
| Facilities and equipment | Workspace, specialized equipment, utilities, and physical resources needed to perform the activity |
| Suppliers and third parties | External providers the process depends on and how quickly their services are needed |
| Workarounds | What alternate methods exist, what they require, and how long they can realistically support the operation |
| Data-loss tolerance | Where applicable, how much data or work can be lost or recreated before the business impact becomes unacceptable |
The Business Impact Analysis Process
The BIA process does not have to be complicated, but it should be deliberate.
1. Define the Scope and Method
Decide which business units, products, services, or processes are included and what information needs to be collected.
Define the impact categories, time periods, recovery terminology, responsibilities, and approval process before asking participants to provide data.
If different interviewers or business units interpret the questions differently, the final results will be difficult to compare.
2. Prepare Participants
Tell participants why the BIA is being performed, what information they need to provide, and how the results will be used.
Pre-work can make the interview more efficient by asking participants to identify basic process information and obvious dependencies before the discussion begins.
For more on preparing participants and organizing the effort, see Preparing for a BIA: It Does Not Have to Be Complicated.
3. Gather the Business Information
The person closest to the work is often the best source of information, regardless of title.
Use people who understand:
- how the activity operates
- what happens if it stops
- what resources it depends on
- what workarounds are available
- what commitments or obligations apply
Questionnaires can provide structure, but important assumptions usually need discussion and follow-up.
For detailed interview guidance, see BIA Interviews That Produce Useful Data: Questions, Evidence, and Red Flags.
4. Validate the Inputs
A completed questionnaire is not automatically a reliable BIA.
Review important answers for inconsistencies, unsupported assumptions, stale information, and missing dependencies.
If a department says it can work manually for several days, ask what the workaround requires and whether it can support realistic volume.
If the process owner proposes a short recovery target, ask what business impact occurs if recovery takes longer.
If the process depends on a supplier or application, confirm that the dependency has actually been captured.
5. Review and Approve the Results
Process owners should review the resulting information and recovery requirements before the BIA is treated as final.
Where the results create significant investment, risk, or capability questions, the appropriate leaders may also need to review the implications.
The purpose of approval is not simply to collect a signature. It is to confirm that the organization understands what the BIA says it needs.
What Should a BIA Produce?
A BIA should produce more than a list of process names and recovery times.
Useful outputs include:
- prioritized business activities
- documented impacts over time
- recovery requirements
- technology and data dependencies
- people and staffing dependencies
- facility and equipment requirements
- supplier and third-party dependencies
- workarounds and their limitations
- assumptions requiring validation
- gaps between business requirements and current recovery capability
- issues requiring management decisions or follow-up
Those outputs should be usable by the people responsible for strategy, plans, technology recovery, exercises, and investment decisions.
How a BIA Establishes Recovery Priorities
A process should not receive a high recovery priority simply because its owner says it is important.
Recovery priority should be supported by the consequences of disruption and how those consequences change over time.
For example, a process may become urgent because an interruption would:
- stop a customer-facing service
- create a safety concern
- prevent another critical process from operating
- cause significant financial loss
- violate a contractual or regulatory obligation
- create a backlog that cannot be recovered later
The reasoning matters because the recovery requirement will eventually influence technology targets, recovery strategies, staffing decisions, exercises, and investment.
Setting RTOs and RPOs From BIA Data
The BIA provides the business justification for recovery requirements, but recovery targets should not be generated mechanically from a questionnaire.
A Recovery Time Objective (RTO) should reflect when an activity needs to resume based on the impact of continued disruption.
A Recovery Point Objective (RPO), where applicable, addresses how much data or work the organization can tolerate losing or recreating.
A tool can help structure the inputs, apply an organization's methodology, and make results easier to compare. It does not eliminate the need for business judgment and validation.
Technology teams also need to compare the business requirement with current technical capability. If the business requires recovery in four hours but the current capability is twelve, the answer is not to quietly change the requirement. The gap needs a decision.
For deeper guidance, see RTO and RPO in Practice: How to Set Defensible Targets.
Dependencies Are One of the Most Important BIA Outputs
A process can look recoverable when it is viewed in isolation and still fail because one supporting dependency is unavailable.
For each important activity, look beyond the process itself.
Ask:
- Which applications must be available?
- Which data or records are required?
- Which employees or specialized skills are needed?
- Which vendors or outsourced services support the work?
- Which facility, equipment, or utility dependencies exist?
- Which other business processes have to recover first?
This dependency view helps connect the BIA to recovery strategy and exposes conflicts between business expectations and actual capability.
How BIA Results Should Influence the Continuity Program
Recovery Strategies
BIA requirements should help determine whether the organization needs alternate facilities, remote work, manual workarounds, redundant technology, alternate suppliers, additional staffing, or another recovery approach.
Business Continuity Plans
Plans should concentrate on the activities, dependencies, procedures, and resources required to support the priorities established through the BIA.
Disaster Recovery
IT should understand which business processes depend on each application and when those processes require the technology to be available.
Exercises
Exercises should test assumptions the BIA depends on, including staffing, workarounds, suppliers, applications, and other critical resources.
Management Decisions
If current capability cannot meet an approved business requirement, the gap should be visible. Management can then decide whether to invest, change the strategy, revise the requirement based on better evidence, or formally address the resulting risk.
What Makes a BIA Useful?
A useful BIA is not necessarily the longest one.
It is one that:
- uses terminology participants understand
- collects information that supports actual decisions
- includes people who understand how the work gets done
- captures important dependencies
- challenges unsupported recovery assumptions
- produces results that business, IT, and leadership can use
The goal is not to check the BIA box. It is to produce recovery requirements the organization can defend and act on.
Frequently Asked Questions
What is the purpose of a business impact analysis?
A BIA evaluates how disruption affects important business activities over time and establishes the recovery requirements and priorities that should guide continuity strategies, plans, technology recovery, and exercises.
What information should a BIA include?
A BIA should capture the activity being assessed, disruption impacts over time, recovery requirements, applications and data, staffing, facilities, suppliers, other process dependencies, workarounds, and important assumptions or gaps.
What is the BIA process?
A practical BIA process includes defining the scope and methodology, preparing participants, gathering business information, validating important inputs, and reviewing and approving the results before using them to guide recovery decisions.
What is the difference between a BIA and a risk assessment?
A BIA examines the consequences of disruption and establishes recovery priorities and requirements. A risk assessment identifies credible threats, vulnerabilities, dependencies, and the exposure they create.
Does a BIA determine RTO and RPO?
The BIA provides the business-impact information needed to establish recovery requirements. RTOs should be supported by the point at which continued disruption becomes unacceptable. RPOs, where relevant, should reflect how much data or work the business can tolerate losing or recreating. Both require validation rather than relying only on automated calculations.
How often should a BIA be updated?
Review BIAs on a defined schedule and after material changes to processes, technology, suppliers, facilities, staffing, products, services, or business obligations. Incidents and exercises should also trigger review when they expose outdated assumptions.
Further Reading
