Business Impact Analysis: Identifying Critical Business Processes

The Question That Almost No One Can Answer

Imagine your ERP system fails completely at 8 a.m. tomorrow. No orders, no inventory management, no invoicing.

How long can you continue like this before real damage occurs?

...

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

The "no idea" is obvious. But "a few hours" doesn't help if it turns out you actually only have 30 minutes before customer orders are lost.

What Is a Business Impact Analysis?

A Business Impact Analysis (BIA) is essentially a systematic inventory. It answers three questions:

1. Which business processes are truly critical? (Not all – only those where a failure would be existentially threatening)

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

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

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

Why IT People Ask the Wrong Questions

Traditional disaster recovery starts with the IT systems: "We have backups for Server X, failover for Database Y, RPO of 4 hours, RTO of 8 hours."

That sounds professional. And it is – technically speaking.

But here's the problem: When your ERP fails, your customers aren't interested in your RTO. They want to know: Can I order? When will my delivery arrive? Will I get support?

A company we worked with had a perfect IT disaster recovery plan. All systems secured, regular backup tests, everything documented. Then a critical supplier was hit by a cyberattack. Production came to a halt – not because their IT failed, but because no one had thought to plan alternative procurement routes.

The DR plan didn't help. Because the problem wasn't IT. It was a lack of business process redundancy.

The Right Start: Three Questions for Tomorrow

You don't need to start with a 6-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.

For a trading company, this could be: order entry, inventory management, shipping. For a software company: platform availability, customer support, billing cycle.

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

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

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

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

These timeframes – technically known as "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 fails for 48 hours?

• What happens if your main raw material supplier suddenly can't 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's a counterintuitive thought: You don't need 100% availability for critical processes.

What you need is the ability to continue working with reduced capacity.

For 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 handles 700 orders per hour – then you've protected 70% of your revenue.

This is often better than the alternative: Waiting 48 hours for the primary system to be restored.

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

The Most Common Mistake: Not Testing

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

We've seen companies that have done daily backups for years. But no one ever conducted a recovery test. When the time came, it turned out: The backups weren't restorable. Encryption keys were outdated. Software versions were incompatible.

The plan looked good. It just didn't 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 decides?

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 created by an external consultant that no one reads.

It is also not a one-time project.

A good BIA is:

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

• Current: Reviewed at least annually, better quarterly

• Operational: The results lead to concrete actions

• Tested: Not only documented but regularly validated

The Next Step

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

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

• Which three processes generate 80% of our revenue?

• How long can each process fail at most?

• What happens if [critical dependency] fails tomorrow?

The answers won't be perfect. They don't have to be. The value lies in asking these questions at all – and recording the answers.

This is the first step towards 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 Business Impact Analysis in the context of a complete 5-dimension framework.