Business Impact Analysis: Identifying Critical Business Processes

The question almost no one can answer

Imagine your ERP system goes down tomorrow morning at 8 a.m. Completely. No orders, no inventory management, no invoicing.

How long can you keep working like that before real damage occurs?

...

If you had to hesitate just now, you are in good company. We ask this question regularly in workshops. The answers range from "a few hours" to "I have no idea, IT documented it somewhere." Both are problematic.

The "I have no idea" is obvious. But "a few hours" is not much help either if it turns out you really only have 30 minutes before customer orders are lost.

What is a Business Impact Analysis?

At its core, a Business Impact Analysis (BIA) is a systematic assessment. It answers three questions:

1. Which business processes are truly critical? (Not all of them—only those where an outage would threaten the company’s existence)

2. How long can each process be unavailable at most? (In hours, not in vague terms like "short")

3. What dependencies exist? (Systems, suppliers, people)

That sounds simple. It is. The challenge is not the methodology, but the fact that these questions are never asked systematically in many companies.

Why IT people ask the wrong questions

Classic disaster recovery starts with the IT systems: "We have backups for server X, failover for database Y, an RPO of 4 hours, an RTO of 8 hours."

That sounds professional. And technically, it is.

But here is the problem: If your ERP fails, your customers do not care about your RTO. They want to know: Can I place an order? When will my delivery arrive? Can I get support?

One company we worked with had a perfect IT disaster recovery plan. All systems protected, regular backup tests, everything documented. Then a critical supplier was taken out by a cyberattack. Production came to a standstill—not because its own IT failed, but because no one had thought to plan alternative procurement paths.

The DR plan did not help. Because the problem was not IT. It was a lack of business process redundancy.

The right starting point: Three questions for tomorrow

You do not have to start with a six-month BIA project. Begin with these three questions—ideally tomorrow in your next executive meeting:

The three core questions of a Business Impact Analysis

1. Which three processes generate 80% of our revenue?

Not IT systems. Business processes.

In a retail company, that could be: order entry, warehouse management, shipping. In a software company: platform availability, customer support, billing run.

Most management teams can answer this question after a short discussion. The problem: they have never documented it explicitly.

2. How long can each of these processes be down before real damage occurs?

"Real damage" means: losing customers, paying contractual penalties, suffering reputational damage.

Be specific. "Order entry can be down for 2 hours, after that we lose orders." Or: "Shipping can pause for 24 hours because we have buffer stock in the warehouse, but after that it becomes critical."

These time windows—in technical terms, "Recovery Time Objectives" (RTO)—are the starting point for everything else.

3. What happens if [critical cloud service/supplier/person] is unavailable tomorrow?

This is where it gets uncomfortable. Because the honest answer is often: "Then we have a problem."

• What happens if Microsoft 365 goes down for 48 hours?

• What happens if your main supplier of raw materials can no longer deliver?

• What happens if the one person who knows the critical legacy system gets sick?

These dependencies—internal and external—are often the biggest blind spots.

The 70% rule: Perfect is the enemy of good

Here is a thought that goes against intuition: You do not need 100% availability for critical processes.

What you need is the ability to keep working at reduced capacity.

An example: Your online store normally processes 1,000 orders per hour. If your primary system fails and you can switch to a fallback system within 30 minutes that can handle 700 orders per hour, then you have protected 70% of your revenue.

That is often better than the alternative: waiting 48 hours until the primary system is restored.

We call this "Minimum Viable Operation" (MVO). For each critical process, you should define: What is the absolute minimum needed to keep operating?

The most common mistake: Not testing

Business Impact Analyses are worthless if they gather dust in a drawer.

We have seen companies that performed daily backups for years. But no one ever did a recovery test. When the real emergency came, it turned out the backups were not restorable. Encryption keys were outdated. Software versions were incompatible.

The plan looked good. It just did not work.

A simple test you can do in the next 14 days:

1. Take a non-critical system offline

2. Observe: Who is informed? How quickly? Who makes the decision?

3. Document what happens

This mini-test reveals more weaknesses than any risk analysis on paper.

What a BIA is not (and should not be)

A Business Impact Analysis is not a 100-page document produced by an external consultant that nobody reads afterward.

It is also not a one-time project.

A good BIA is:

• Compact: 5-10 pages are enough for critical processes

• Up to date: Reviewed at least annually, preferably quarterly

• Operational: The results lead to concrete measures

• Tested: Not just documented, but regularly validated

The next step

If you do one thing after reading this article, make it this:

Schedule a 60-minute meeting with your management team for next week. Agenda: The three questions above.

• Which three processes generate 80% of our revenue?

• How long can each process be down at most?

• What happens if [critical dependency] fails tomorrow?

The answers will not be perfect. They do not have to be. The value lies in asking these questions at all—and recording the answers.

This is the first step toward true operational resilience. Not more documentation. But clarity about what really matters.

Further reading

This article is based on the ODCUS white paper "Resilience Engineering for Business Continuity", which addresses the Business Impact Analysis in the context of a complete five-dimensional framework.