How to Conduct a Business Impact Analysis: Four Steps That Set Your Recovery Order

How many days of payroll can you lose? What about the system your customers order through, or the VPN your remote staff depend on? An hour? A day? Two weeks? A business impact analysis (BIA) answers those questions, and most organizations that skip one find out the answer during the outage.

The BIA is the first thing we do with a new business continuity client. Not because a standard says so, but because every decision after it depends on it: what you recover first, what you spend money on, and what your plans actually protect. Without it, you are guessing.

Here is how to conduct a business impact analysis that produces a recovery order your executives will stand behind.

What Is a Business Impact Analysis?

ISO 22301, the international business continuity standard, defines a business impact analysis as the “process of analysing the impact over time of a disruption on the organization.” In plain terms: what would a disruption do to your revenue, your expenses, your operations, and your reputation, and how fast does that damage grow?

The words “over time” matter most. Losing your order system for ten minutes is an annoyance. Losing it for three days is a different company. The BIA measures that curve for every critical process.

You will also see it called a business impact assessment. Same thing. Same output.

That output is a recovery time objective (RTO) for every critical process and the systems, people, and suppliers it depends on. We define an RTO as the overall length of time a business process can be disrupted before that disruption becomes unacceptable to the organization. Some organizations use maximum tolerable period of disruption (MTPD) or maximum acceptable outage (MAO) instead. I don’t really care what you call it. Pick one metric and use it consistently across the organization.

With RTOs in hand, you have a recovery order. That order is the foundation of every plan you write.

Why a Business Impact Analysis Comes First

Disruptions rarely hit one thing. When a data center goes down, customers may be locked out, payroll may be down, and the intranet may be gone, all at once. Organizations that haven’t done a BIA try to recover every system and every business process at the same time. They have no way to prioritize, and that mistake costs real money and real reputation.

Payroll is a good test. It needs to come back quickly: people won’t work for long unpaid, and you have legal obligations. But it doesn’t necessarily need to come back within an hour, or ahead of the systems that bring in revenue. A BIA lets you make that call before the outage instead of during it.

The second reason is money. If you are struggling to win executive investment in your program, you probably haven’t done a thorough BIA. The BIA gives you financial and operational evidence, not opinions. “We need a second data center” is a request. “Our top revenue process loses this much per day, and our current recovery takes seven days” is a decision.

A BC director at a financial services firm put the cost of skipping this work plainly after a tabletop exercise earlier this year: “We don’t know when we can recover what in what order.” That sentence is the problem a BIA solves.

And watch for this one: “We already know what’s critical.” I’ve heard it from a board that had complete business continuity documentation and no BIA. When the BIA was done, it surfaced critical teams and systems that weren’t in any of their plans. At a long-term SaaS client, executives handed us 12 to 14 areas to plan for. A company-wide BIA a year later found more than 25 teams and dozens of critical processes.

Your executives’ list of critical processes is usually half the real list. A plan without a BIA is a guess.

How to Conduct a Business Impact Analysis in Four Steps

Every BIA is different. A nonprofit, a utility, and a healthcare network need different questions. The method stays the same.

Step 1: Scope the need

Decide which parts of the organization are in scope and what you need to learn from them. Then define what “critical” means for your organization. One company might call anything that needs recovery within 30 days critical. Another might draw the line at 72 hours. The definition matters less than having one.

Anchor every process in scope to something the business cares about: a revenue stream, a customer commitment, or a regulatory obligation. If a process can’t be tied to any of those, ask whether it belongs in the BIA at all.

A short criticality survey up front narrows the BIA to the processes that truly need fast recovery, so you don’t spend interview time on the ones that can wait a month.

Step 2: Prepare your stakeholders

Schedule the interviews and send short pre-work, so people arrive having thought about the questions. Five questions do most of the work:

• What does your team do?
• In two or three sentences, what does a disruption look like for you?
• How does that disruption affect the rest of the organization?
• What disruptions have you lived through, and what happened?
• Which systems, suppliers, and people are you most dependent on?

Pick the right people. You want the leader who owns the process and the person who actually knows how the work gets done. Those are often different people.

Step 3: Conduct the BIA interviews

This is where the real findings come from. Our interviews run 45 minutes to two hours. Spreadsheets and survey tools can collect data, but they don’t ask the follow-up question.

Cover two things in every interview.

First, the impact over time. For each critical process, walk through what happens at set intervals after it stops. We use a grid: impact categories down the side, time across the top. Here is an illustrative example for an online order process (not client data):

Where the impact first becomes unacceptable is your RTO. In this example, somewhere between 4 and 24 hours. Use shorter intervals (1, 2, 4, 8, 12, and 24 hours) for fast-moving processes, and stretch the grid to 30 days for slower ones.

Second, the dependencies. Plan for consequences, not scenarios. Every disruption, whatever the cause, ends up as one or more of four consequences: loss of people, loss of a facility, loss of technology, or loss of a critical third party. Ask about each. Which systems does the process run on? Which suppliers? Which people, and how many of them could do the work?

This is where BIAs earn their keep. One systems engineer told us losing Active Directory was “no big deal.” A more experienced head of systems engineering named Active Directory and the single sign-on platform as the two failures that would put them “in a world of trouble.” Meanwhile the business leader in the room said he could just work from home. He couldn’t. His login ran through the same platform. Most businesses don’t see these dependencies until a BIA puts them on the table.

In 2026, add one question to every interview: which AI tools or agents does this process rely on, and what do you do if they disappear tomorrow? I wrote about why in Your AI Agent Is Now Part of Your Incident.

Finally, challenge the RTOs. Every process owner wants to be critical. If a proposed RTO looks out of line with the impact grid, say so in the interview and work it out.

Step 4: Validate and report

Aggregate the interviews into a short report: the impacts by category, an RTO for every in-scope process, and the dependencies between them. Then validate it with senior leaders before you publish anything. Work with an executive who represents a broad business area, usually a direct report of the CEO, and confirm the priorities match how they run the business. Expect them to move things. That is the point.

Then share the results. A BIA that only the BC team can read loses credibility fast. Keep the inputs, the scoring, and the RTOs visible to the people who supplied them.

I walked through this process on Managing Uncertainty, Episode 112: The Business Impact Analysis (BIA), and the BIA section of our Ultimate Guide to Business Continuity shows where it sits in the full program.

Where Business Impact Analysis Goes Wrong

The same failures show up in program after program.

• Not challenging RTOs. When every application is critical, every RTO is four hours or less, and nobody can rank the top 10, the BIA hasn’t done its job. When you protect everything equally, you protect nothing well.
• Skipping executive validation. An unvalidated BIA is the BC team’s opinion. Executives will override it during the event, so get their input before the event.
• Making it a black box. Complex scoring formulas nobody can explain, results nobody gets to see. Business leaders stop trusting the numbers, and the program loses credibility with them.
• Interviewing the wrong people. The leader knows the business priority. The person doing the work knows the dependency that will break it. You need both.
• Letting it go stale. A BIA from three reorganizations ago describes a company that no longer exists.

What the BIA Feeds

A finished business impact analysis isn’t a document to file. It drives four things.

Recovery strategies. For each consequence (people, facility, technology, third party), you now know how fast you need a workaround, which tells you what the workaround can cost.

Business continuity plans. Plans follow the recovery order. Teams with short RTOs get detailed plans first.

IT disaster recovery. This is where the gap usually hides. We’ve seen IT recovery plans built to bring critical systems back in seven days when the business needed them in 24 hours. Business needs and IT capability drift apart unless the BIA drives DR. More on that in Business Continuity and IT Disaster Recovery.

Investment decisions. BIAs don’t only justify spending. One client’s first comprehensive BIA showed it could shrink its on-premises data centers, move to the cloud, and avoid a legacy system upgrade. The BIA paid for itself.

The BIA Is a Starting Point, Not a Verdict

Before founding Bryghtpath, I was part of the response when a leak in an ice machine’s water line flooded about three and a half floors of a Target headquarters building in Minneapolis in 2013. Few of the affected teams met our BIA criticality criteria, so none of them had alternate space. By the next business day, leadership had decided those teams were critical anyway. Kim Hirsch and I wrote up the lessons in When a Drip Becomes a Flood.

The lesson isn’t that the BIA was wrong. It’s that executives call the shots during the event, and the BIA is the best information they’ll have when they do. Plan for that conversation.

Two more limits to keep in mind:

• BIAs look backward. They describe how the business runs today. The strategic bets in flight (the new product line, the acquisition, the platform migration) are often the least protected things in the company, and the things your CEO cares about most. Ask about them.
• BIAs age. Update yours every year, and mid-year after any material change: a reorganization, an acquisition, a major system migration, a new critical vendor. Larger programs split the organization in half and refresh each half on alternate years.

Business Impact Analysis FAQ

What is a BIA?
A business impact analysis is the process of measuring how a disruption’s impact on your organization grows over time, so you can set a recovery time objective for each critical process and recover in the right order.

Is a business impact assessment the same as a business impact analysis?
Yes. The terms are used interchangeably. Both produce criticality, impact over time, dependencies, and recovery objectives.

What’s the difference between a BIA and a risk assessment?
A risk assessment asks what could happen and how likely it is. A BIA asks what happens to the business if a process stops, regardless of the cause. You need both. The BIA tells you what to protect; the risk assessment tells you what to protect it from.

How long does a business impact analysis take?
It depends on scope. Each interview runs 45 minutes to two hours; the calendar time goes to scheduling, follow-up, and executive validation. Scope tightly in step 1 and the rest moves faster.

Do we need software?
Not to start. A well-built spreadsheet with drop-down lists for consistency works for most first BIAs, and our Business Continuity Plan Template Package includes an Excel BIA tool with RTO and impact scoring. Dedicated BC software earns its cost once you’re maintaining hundreds of BIAs and plans.

How often should we update the BIA?
At least annually, and after any material change to the business.

You can’t recover everything at once, and you shouldn’t try. A business impact analysis tells you what comes first, and gives your executives the evidence to agree.

Keep Going

A few ways to go deeper if this was useful.

• Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Business Continuity.
• Get help with your BIA. Our Business Continuity services include BIA facilitation, from scoping through executive validation.
• Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap.
• Talk to us. Set up a call to think through your program with us.