A business impact analysis (BIA) is a structured assessment that shows how an interruption to each business function would hurt revenue, operations, and compliance over time. The result is a ranked list of what to restore first and how fast.
Downtime is costly. An ITIC survey found that over 90% of mid-size and large enterprises say one hour of downtime costs more than $300,000.
Whether you run continuity planning for a hospital, a retailer, or a small firm, the method is the same. Here, we’ll break down the key terms, a six-step process, a worked example, and the survey questions that make a BIA usable.
What is a business impact analysis?
A business impact analysis is a process that identifies an organization’s critical functions and measures how much damage losing each one would cause as time passes. It answers three practical questions:
- Which processes matter most?
- How long can each one stop before the harm becomes unacceptable?
- What does it take to bring each one back?
A BIA is the foundation of business continuity planning (BCP), the documented set of actions that keeps a company operating through a disruption. It also feeds the disaster recovery (DR) plan, which restores technology after an outage. Both plans are only as good as the priorities the BIA sets.
Three public references shape how most teams run one. The National Institute of Standards and Technology (NIST) describes a three-step BIA in NIST SP 800-34. The International Organization for Standardization (ISO) publishes ISO/TS 22317, guidelines for designing a BIA process (the 2021 edition replaced the 2015 version). In the US, Ready.gov offers a BIA worksheet for organizations of any size.
Why does a business impact analysis matter?
A BIA matters because it replaces guesses about downtime with numbers the business has agreed on. Without one, recovery order often follows whoever pushes hardest during an outage. The same ITIC survey reports that 41% of enterprises put one hour of downtime between $1 million and $5 million or more.
A completed BIA gives you:
- A ranked recovery order that every department has signed off on
- Recovery targets tied to dollars, not opinions
- A clear case for backup, redundancy, and staffing budgets
- Test criteria for your continuity plan, so exercises measure something real
- Backup schedules matched to how much data each process can afford to lose
- Evidence for auditors, insurers, and customers who ask about your preparedness
How is a business impact analysis different from a risk assessment?
A BIA measures the impact of losing a function, whatever the cause. A risk assessment estimates the likelihood of the threats that could cause the loss. Most teams run the BIA first, so risk work focuses on threats to the processes that matter. For the second half of that pairing, see QuestionPro’s guide to risk analysis.
| Term | Question it answers | Main output |
|---|---|---|
| Business impact analysis | What happens if this function stops, and how fast must it return? | Ranked processes with recovery targets |
| Risk assessment | What could stop it, and how likely is that? | Rated threats and vulnerabilities |
| Business continuity plan | How do we keep operating during a disruption? | Documented procedures and roles |
| Disaster recovery plan | How do we restore systems and data? | Technical recovery runbooks |
| Gap analysis | How far is our current capability from the target? | List of shortfalls and fixes |
The last row matters right after the BIA. Comparing today’s recovery capability against your new targets is a gap analysis exercise.
What do MTD, RTO, and RPO mean in a business impact analysis?
These three numbers are the core output of a BIA. They turn a vague idea like “we can’t be down for long” into targets that engineers can build to and auditors can test.
The three terms at a glance
- Maximum tolerable downtime (MTD): The longest a process can stay down before the harm becomes unacceptable. Business owners set it.
- Recovery time objective (RTO): The target time to restore a specific system or process. It must be shorter than the MTD.
- Recovery point objective (RPO): How much data, measured in time, you can afford to lose. An RPO of 15 minutes means a restore can rewind no further than 15 minutes of work.
How do the three numbers fit together?
Think of MTD as the cliff edge and RTO as the fence you build well short of it. Say an invoicing application has an MTD of 48 hours. Suppose the team needs 6 hours of reprocessing after the system returns. The RTO has to fit inside what remains:
- MTD: 48 hours
- Reprocessing after restore: 6 hours
- Maximum RTO: 42 hours
Shorter RTOs cost more, so set each one as slow as the MTD safely allows. This calculation is an illustration, and your own recovery work will differ.
Step-by-step guide to conducting a business impact analysis
A BIA follows six steps, from agreeing scope to presenting results. Each step produces something the next one needs, so skipping ahead usually means redoing work. The sequence below adapts the three-step method in NIST SP 800-34 for any industry.
Step 1: Set scope and secure sponsorship
- Decide which business units, locations, and systems are in scope
- Name an executive sponsor who can settle disputes between departments
- Pick a time horizon, such as a disruption lasting one week or 30 days
- Agree on how you will rate impact (see Step 4)
- Set a deadline for questionnaire responses
Sponsorship matters more than most teams expect. Department heads answer faster when a senior leader asks.
Step 2: Identify critical business functions
List every function in scope, then break each into the processes that make it work. Sales, for example, includes order entry, pricing, and contract approval. Ask department heads to name processes, not just systems, because one system often supports several processes with different priorities.
Start with processes tied to revenue, legal obligations, safety, and customer commitments. A short, accurate list beats an exhaustive one.
Step 3: Collect data with questionnaires and interviews
Gather impact data from the people who run each process. A questionnaire scales across many departments. Short interviews then fill in the detail behind unusual answers. Use these sources together:
- Questionnaires sent to every process owner
- Follow-up interviews for high-impact or unclear answers, coded with qualitative insights methods
- Financial records, such as revenue per hour or per day
- Contracts and service-level agreements (SLAs) that promise customers a minimum level of service
- IT asset inventories and vendor lists
Ask owners to answer for the worst case within your time horizon, such as an outage during peak season.
Step 4: Rate the impact over time
Score each process on a 1 to 5 scale. A shared table keeps raters consistent across departments.
| Score | Financial | Operational | Legal and regulatory | Reputation |
|---|---|---|---|---|
| 1 | Negligible | Workarounds are easy | None | None |
| 2 | Minor, absorbed in budget | Some delay | Internal notice only | A few complaints |
| 3 | Noticeable loss | Key tasks stall | Possible reporting duty | Customer complaints |
| 4 | Serious loss | Process stops | Likely fines or breach | Public coverage |
| 5 | Threatens viability | Several processes stop | Confirmed violation | Lasting trust damage |
Rate each process at fixed points, such as 1 hour, 8 hours, 24 hours, 3 days, and 1 week. One workable rule sets the MTD at the earliest point where any category reaches 4. Your threshold may differ, so agree on it before scoring starts.
Step 5: Map dependencies
List what each critical process needs to run: people, applications, data, vendors, facilities, and equipment. This mirrors the second step in NIST’s method, and it exposes hidden weak points.
A payroll process, for example, may depend on an HR system, a bank connection, and one specialist. The process inherits the weakest link. If the HR system’s RTO is 72 hours, payroll cannot promise 24.
Step 6: Set recovery priorities and report
Combine the scores and dependencies into a ranked recovery order, then document it. A useful BIA report includes:
- An executive summary that names the processes with the shortest MTDs
- Scope, method, and the people who contributed
- MTD, RTO, and RPO for each process
- Dependencies and single points of failure
- Gaps between current recovery capability and the targets
- Recommended actions with cost estimates
Present findings to senior management in dollars and days, not technical shorthand. Ask for written sign-off so the numbers carry authority.
Business impact analysis example: An online retailer
This example shows what BIA outputs look like for a mid-size US online retailer. The figures are illustrative, not benchmarks.
| Process | MTD | RTO | RPO | Why it ranks here |
|---|---|---|---|---|
| Checkout and payments | 4 hours | 1 hour | 15 minutes | Downtime halts all online revenue |
| Order fulfillment system | 24 hours | 8 hours | 1 hour | Missed shipments trigger refunds and cancellations |
| Customer support platform | 48 hours | 24 hours | 4 hours | Backlogs grow, but workarounds exist |
| Payroll | 5 days | 48 hours | 24 hours | Payday commitments set the limit |
| Internal reporting | 7 days | 72 hours | 24 hours | Decisions slow, but customers are unaffected |
Checkout recovers first because it has the shortest MTD. A gap analysis then compares what the infrastructure can do today against a 1-hour RTO. If failover currently takes 3 hours, the retailer has a 2-hour gap and a funded project to close it.
The same logic works for a clinic, a manufacturer, or a ten-person firm. Only the processes and numbers change.
What questions should a business impact analysis questionnaire ask?
A good BIA questionnaire is short, specific, and answerable by one process owner in a single sitting. Group the questions by what you need to learn, and keep every answer comparable across departments.
Process basics
- What does this process do, and who depends on it?
- How many people work on it?
Impact over time
- If this process stopped for 1 hour, 8 hours, 24 hours, 3 days, or 1 week, how severe would the financial effect be on a scale of 1 to 5?
- What revenue or cost does one hour of this process represent?
Recovery needs
- What is the longest outage you could accept?
- How much recent data could you lose without serious harm?
Dependencies and workarounds
- Which systems, vendors, and people does this process need?
- Is there a manual workaround, and how long can it last?
A matrix question captures the impact-over-time rating in one grid, and rating scales keep answers comparable. QuestionPro’s risk assessment survey template gives you a starting set of questions to adapt.
How do you decide which processes to recover first?
Rank processes by MTD first, then adjust for dependencies, legal duties, and cost. The shortest MTD usually goes first, but four rules can change the order.
- Restore dependencies before the things that rely on them. A database comes before the application server that uses it, even if the application looks more urgent.
- Put life safety and legal obligations ahead of revenue when the two conflict.
- Match recovery spend to the MTD. A payroll system with a 12-hour MTD justifies fast, expensive recovery. A reporting tool with a five-day MTD does not.
- Settle ties with the executive sponsor and record the decision.
How do you measure whether a business impact analysis is working?
A BIA works when recovery tests hit the targets it set and the numbers stay current. Track these five measures.
- Coverage: The share of critical processes with a named owner and a completed questionnaire. Aim for 100%.
- Tested RTO against target: Run a recovery exercise and compare the actual restore time with the documented RTO. Any miss is a gap to fix.
- Data freshness: The age of your newest usable backup compared with the RPO.
- BIA age: Months since the last full review. Review at least once a year and after major changes such as a merger, a new system, or a new site.
- Response rate: The share of process owners who answered on time. Low rates signal weak sponsorship.
What are the most common business impact analysis mistakes?
Most failed BIAs share the same few weaknesses. All of them are avoidable with planning.
| Mistake | What goes wrong | Fix |
|---|---|---|
| Treating the BIA as an IT project | Business priorities get missed | Include finance, operations, and every department head |
| Skipping executive sign-off | Departments dispute targets during a crisis | Get written approval from the sponsor |
| Rating every process as critical | Recovery order loses meaning | Force-rank and cap the top tier |
| Using gut-feel numbers | Targets collapse under audit | Tie financial impact to records |
| Ignoring dependencies | A fast RTO fails because a vendor is slow | Map and test dependencies |
| Filing the report away | Targets drift out of date | Schedule reviews on the calendar |
How does QuestionPro help with a business impact analysis?
The hardest part of a BIA is collecting consistent answers from dozens of process owners. QuestionPro survey software handles that part in three ways:
- Short questionnaires at any scope: Skip logic and piping show each owner only their own processes.
- One grid for impact scores: Matrix and rating-scale questions capture ratings over time side by side.
- Live visibility: Real-time shareable dashboards let you sort processes by shortest MTD and spot departments that have not replied.
Because BIA answers reveal how a business would fail, data security matters too. QuestionPro’s platform is ISO 27001 certified.
Final thought on business impact analysis
A business impact analysis is not a report to file away. It is a set of agreed numbers that decide who gets restored first when something breaks.
Those numbers earn trust when process owners supplied them, executives approved them, and a recovery test proved them. Start with your five most critical processes, gather honest answers, and set MTD, RTO, and RPO for each. Expand from there, and put the next review on the calendar before you close the project.
Frequently Asked Questions (FAQs)
Review it at least once a year and after any major change, such as a merger, a new system, a new location, or a shift in key suppliers. Each change can move a process’s priority or its recovery targets.
Yes, scaled down. A small firm can list its five to ten most important processes, estimate the revenue lost per day if each stops, and name a workaround for each. That still sets clear recovery priorities.
In practice, none. Maximum allowable outage (MAO) is the older NIST term for maximum tolerable downtime (MTD). Both mean the longest a process can stay down before harm becomes unacceptable, so use whichever your standards or auditors prefer.
No. A questionnaire collects consistent data quickly, but interviews and financial records validate it. Follow up on outliers, check revenue figures against accounting data, and confirm dependencies with IT before anyone signs off on recovery targets.
An executive sponsor, such as the COO, CFO, or chief risk officer, should sign off. Their approval gives MTD and RTO targets authority across departments, which prevents disputes over recovery order during a real incident.
