How to Conduct a Business Impact Analysis (BIA): Step-by-Step Template and Guide

Most business continuity programs fail before they start — because they skip the one step that makes every other step possible.

That step is the business impact analysis. And most organizations either do it wrong, do it once and forget it, or mistake a spreadsheet of system names for an actual BIA. TSB Bank spent over £330 million learning this lesson the hard way. In April 2018, a botched IT migration left millions of customers locked out of their accounts for weeks. The FCA and PRA fined TSB £48.65 million in 2022, citing operational risk management and governance failures — including inadequate management of outsourcing and IT risks. A rigorous BIA process would have mapped those dependencies and surfaced the recovery gaps before the migration went live.

This guide walks you through how to actually do a business impact analysis — not just what it is, but what to collect, who to ask, how to score impact, and how to translate findings into RTO/RPO targets your recovery plan can actually use.

TL;DR

A BIA identifies your critical processes, their dependencies, and the cascading impact of disruption — it’s the foundation your entire BCP is built on

You need to quantify impact across four dimensions: financial, operational, reputational, and regulatory

The output is prioritized recovery objectives (RTO/RPO) for each critical process — not just a list of systems

What Is a Business Impact Analysis (And Why It’s Not Optional)

A BIA is the process of identifying how disruptions affect your operations — and by how much, and over what timeframe. It’s not a risk assessment (that’s about likelihood). It’s about consequences.

The FFIEC’s Business Continuity Management booklet is explicit: management must develop a BIA that identifies all business functions, prioritizes them by criticality, analyzes interdependencies, and assesses disruption impact through established metrics. During exams, regulators look at whether your BIA covers critical function identification, interdependency mapping, recovery objective reasonableness, and whether results were actually communicated throughout the organization.

Skip the BIA and your BCP is built on guesswork. You won’t know which systems to recover first, which vendors to call at 2 AM, or whether your 4-hour RTO is achievable.

Step 1: Identify Critical Business Processes

Start with processes, not systems. Systems support processes — processes drive revenue, serve customers, and keep regulators happy.

Who to interview: Department heads, operations leads, compliance officers, IT managers. Anyone who knows what actually keeps the lights on.

What to ask:

What does your team do every day that, if it stopped, would immediately hurt the business or a customer?
What are the time-sensitive deadlines you have to hit? (regulatory filings, payment settlements, batch jobs)
What happens if your team can’t function for 2 hours? 8 hours? 24 hours? 5 days?

Output: A ranked list of business processes, from most to least critical.

Priority	Process	Department	Owner
1	Payment processing	Treasury/Operations	CFO
2	Customer authentication	IT/Security	CISO
3	Regulatory reporting	Compliance	CCO
4	Loan origination	Lending	COO
5	General ledger	Finance	Controller

Step 2: Map Dependencies (Systems, Vendors, People, Data)

This is where most BIAs fall apart. People list the process and stop. But the BIA needs to capture everything that process depends on.

For each critical process, map four dependency categories:

Systems & Technology

Core applications (name them specifically — “loan origination system” is not enough; “Encompass 360 hosted on AWS us-east-1” is)
Internal infrastructure (servers, network, authentication platforms)
Data feeds and integrations

Third-Party Vendors & Services

Cloud providers, SaaS platforms, data processors
Outsourced service providers (payment rails, print/mail, call centers)
Utilities (connectivity, power)

People

Minimum staffing needed to run the process
Key person dependencies (what happens if the one person who knows this system is unavailable?)
Location requirements (on-site vs. remote-capable)

Data

What data is required?
Where is it stored and backed up?
What’s the maximum tolerable data loss? (This feeds directly into your RPO)

The FFIEC handbook specifically requires that your BIA identify “resources on which these functions and processes depend and exposures that would warrant further protective measures.” This is that section.

Step 3: Quantify the Impact of Disruption

Here’s where precision matters. Vague descriptions (“it would be bad”) don’t drive recovery prioritization. Dollar figures and regulatory deadlines do.

Score impact across four dimensions for each process:

Financial Impact

Direct revenue loss per hour of downtime
Transaction penalties or settlement failures
Customer refunds or credits
Increased labor costs (overtime, manual workarounds)

Operational Impact

Downstream processes that break if this one fails
Customer-facing service degradation
Manual workaround feasibility and cost

Reputational Impact

Customer notification triggers (data loss, service unavailability)
Media or social media exposure likelihood
Impact on customer trust and retention

Regulatory Impact

Reporting deadlines that would be missed
Regulatory notifications required (SAR, breach notification, etc.)
Fines or supervisory actions at risk

Impact Scoring Matrix:

Impact Level	Financial (per day)	Operational	Reputational	Regulatory
Critical (4)	>$500K	Core service failure	Media coverage likely	Mandatory regulator notification
High (3)	$100K–$500K	Major degradation	Customer escalations	Deadline breach possible
Medium (2)	$10K–$100K	Partial service impact	Internal complaints	Minor SLA breach
Low (1)	<$10K	Minor inconvenience	Negligible	No deadline impact

Score each process across all four dimensions. The highest score wins — don’t average them. A process with low financial impact but Critical regulatory impact is still Critical.

Step 4: Set RTO and RPO Targets

The BIA output isn’t a report that lives in a drawer. It’s recovery objectives that your team has to actually meet.

Recovery Time Objective (RTO): Maximum acceptable time to restore a function after disruption.

Recovery Point Objective (RPO): Maximum acceptable amount of data loss, measured in time (e.g., “we can tolerate losing no more than 4 hours of data”).

For each critical process, derive RTO and RPO from your impact analysis:

Process	Impact Score	Assigned RTO	Assigned RPO
Payment processing	Critical	2 hours	15 minutes
Customer authentication	Critical	1 hour	0 (real-time)
Regulatory reporting	High	4 hours	1 hour
Loan origination	High	8 hours	4 hours
General ledger	Medium	24 hours	4 hours

These targets need to be validated against your actual recovery capabilities. If your backup restoration takes 6 hours but your RTO is 2 hours, you have a gap — and your BIA just found it. That’s the point.

For a deeper dive on setting these objectives, see the RTO vs RPO guide.

Sample BIA Questionnaire

Use this to structure your interviews. Adapt it to your organization.

Section A: Process Overview

Describe your department’s core business function(s).
List the top 3–5 processes your department performs that are time-sensitive.
What would happen if your team could not perform these functions for: 2 hours? 24 hours? 1 week?

Section B: Dependencies 4. List all applications and systems your team uses daily. 5. Which of these are required to perform your most critical functions? (rank them) 6. Do you rely on any third-party vendors or service providers? List them with a brief description of what they provide. 7. Are any functions dependent on a single individual? If that person were unavailable, what happens? 8. What data does your team require access to, and where is it stored?

Section C: Impact 9. Estimate the financial impact of a 24-hour disruption to your core processes. (Revenue lost, penalties incurred, overtime costs) 10. Are there regulatory or legal deadlines your team is responsible for? List them with frequency and consequences for missing them. 11. What customer commitments or SLAs could be breached during an outage?

Section D: Recovery 12. What is the minimum number of staff needed to perform critical functions in a degraded state? 13. Could your team operate remotely? For how long? What would they need? 14. What manual workarounds exist for your critical systems? How long can you operate that way? 15. What recovery time would be acceptable before business impact becomes severe? 16. What is the maximum amount of data loss your team could tolerate?

What the FFIEC Actually Wants to See

If you’re in financial services, your BIA isn’t just a best practice — it’s an exam requirement. When regulators review your BCM program, they’re looking at:

Whether you’ve identified critical business functions (not just IT systems)
Whether interdependencies are mapped across business units, not siloed by department
Whether recovery objectives are reasonable — meaning they’re based on actual impact analysis, not wishful thinking
Whether BIA results have been communicated to management and the board
Whether management reviews and updates the BIA regularly — especially after significant changes

The FFIEC handbook is explicit that the BIA must cover “financial and other resource costs (e.g., the loss of business, and exposure to legal and regulatory consequences) needed to recover and restore business functions and processes.” If your BIA doesn’t address regulatory impact, it’s incomplete by definition.

This is also where examiners find gaps between what you documented and what you’ve actually tested. A BIA that says “RTO: 4 hours” but has never been validated in an exercise is a liability, not an asset.

Common BIA Gaps (And How They Get Organizations in Trouble)

Gap 1: Confusing IT asset inventory with BIA Listing servers and applications is not a BIA. The BIA starts with business processes and works backward to the technology. Many organizations have it backwards — they inventory their tech stack and assume that covers it.

Gap 2: No third-party dependency mapping TSB’s £48.65 million fine from the FCA and PRA specifically called out failures in outsourcing risk management. If your BIA doesn’t map vendor dependencies for every critical process — including what happens if that vendor goes down — you have a blind spot that regulators will find.

Gap 3: Single-point-of-failure people Most BIAs map systems. Few map people. If one person holds the institutional knowledge to run a critical process and they’re unavailable, your RTO becomes theoretical. The BIA questionnaire above surfaces this directly.

Gap 4: Stale BIAs A BIA done in 2021 doesn’t reflect the cloud migration you did in 2023, the new fintech partnership you added in 2024, or the third-party processor that now handles your payment settlement. BIAs need to be updated at least annually and after any significant change.

Gap 5: No board-level visibility FFIEC requires communication of BIA results throughout the entity — including management. If your BIA lives in a compliance folder and has never been presented to the board or senior leadership, that’s an exam finding waiting to happen.

So What?

The BIA is not a document. It’s a decision-making tool. It tells you what to protect, in what order, with what resources, within what timeframes — so that when something breaks (and it will), your team has a playbook instead of a panic attack.

Done right, a business impact analysis template gives you:

A prioritized recovery sequence your team can actually follow
RTO/RPO targets anchored in real impact, not gut feel
Documented dependency maps that survive staff turnover
An audit trail that satisfies FFIEC examiners and your own board

Skip it, and your business continuity plan is a story you’re telling yourself about how prepared you are.

For a practical starting point on building your full BCP from BIA findings, see the business continuity plan template guide.

Start with the BIA template. The Business Continuity & Disaster Recovery Kit includes a ready-to-use BIA template, impact scoring worksheets, RTO/RPO calculators, and a full BCP framework — everything you need to build a program that holds up under pressure and scrutiny.

Frequently Asked Questions

How long does a business impact analysis take to complete?

It depends on your organization’s size and complexity. A smaller business with 5–10 core processes might complete a BIA in 2–3 weeks of interviews and analysis. A mid-size financial institution with multiple business lines might take 2–3 months. The mistake most organizations make is rushing to finish rather than doing it thoroughly — a BIA done in a week that missed key dependencies is worse than no BIA at all because it gives false confidence.

How often should a business impact analysis be updated?

At minimum, annually. More importantly: after any significant change — a new technology platform, a major vendor relationship, a merger or acquisition, a significant staffing change, or a real disruption event. The FFIEC expects BIAs to reflect your current operating environment, not the one you had two years ago.

What’s the difference between a BIA and a risk assessment?

A risk assessment looks at likelihood — what threats could disrupt us, and how probable are they? A BIA looks at consequences — if a disruption happens, what’s the impact and how quickly do we need to recover? They’re related but distinct. The risk assessment feeds the threat scenarios you use to stress-test your BIA. The BIA output feeds the recovery strategies in your BCP. Both are required under FFIEC BCM guidance.