Conducting a Business Impact Analysis (BIA): Evaluating Business Processes

What the BIA achieves and why it comes first

When you build a business continuity management system, the Business Impact Analysis stands at the very beginning. Not because a regulation says so (although ISO 22301 and NIS2 require it), but because without a BIA, all further decisions are based on assumptions instead of facts.

The central question of the BIA is: What happens when a business process goes down - after one hour, after one day, after one week? And which processes must therefore run again first?

These questions sound simple, but the answers rarely are. A machine builder with 150 employees may have 30 identifiable business processes. Which of them are truly business-critical? Sales would say: order entry. Production: manufacturing control. Accounting: payment processing. And they are all somewhat right. The BIA brings structure to this discussion and delivers a fact-based prioritization that all stakeholders can understand.

Without a BIA, the following happens: In an emergency, whoever shouts loudest or happens to be first in the office the next morning decides the restoration order. IT might restore the mail server first because complaints come fastest there, while production planning is down and EUR 50,000 in revenue is lost every day.

BIA vs. risk analysis - the difference

A common confusion: The BIA is not the same as a risk analysis. Both methods are part of an ISMS or BCM, but they answer different questions.

The BIA does not ask whether something will happen, but what happens when it happens. It considers impact in isolation from probability. For considering probabilities, you need a separate risk assessment. A process can have very high impact even if the probability of failure is low. This is precisely what makes the BIA valuable: It uncovers dependencies and impacts that can get lost in a pure risk assessment.

In practice, both methods complement each other. The risk analysis shows you which threats are realistic. The BIA shows you what impact these threats have on your business. Together, they provide a complete picture.

Step 1: Identify business processes

The first step of the BIA is the systematic capture of all relevant business processes. This sounds like busywork but is decisive, because what you forget here will not appear in any recovery plan later.

How to find business processes

A top-down approach works most effectively: You start with business areas and work down to individual processes.

Example for a machine builder:

Granularity: How deep must you go?

The right granularity matters. Too coarse ("Production" as one process) does not help with prioritization. Too fine ("Mill part X on machine Y") makes the analysis unwieldy and adds no value.

A good rule of thumb: Each process should be assignable to a clearly identifiable responsible person and depend on an identifiable set of IT systems. If you have three different responsible persons for a process, it is probably too coarse. If you have 50 processes in a business area, you are probably too fine.

For a mid-market company with 100 to 300 employees, you typically end up with 20 to 40 business processes. That is a manageable number for further analysis.

Data collection: Workshops and interviews

You cannot identify the processes alone at your desk. You need the knowledge of the business units. Two methods have proven effective:

Workshops: Invite the heads of business areas to a joint workshop. Advantage: Everyone sees the complete list and can identify gaps. Disadvantage: Workshops take long and scheduling is challenging.

Individual interviews: Speak with each area head individually, 30 to 45 minutes per conversation. Advantage: Deeper insights, less group dynamics. Disadvantage: You must consolidate the results yourself.

In practice, a combination works best: Interviews for collection, a joint workshop for validation and prioritization.

Step 2: Assess outage impact

Now it gets concrete. For each identified business process, you assess what impact an outage has - across different time periods.

Impact categories

The impacts of an outage are rarely only financial. A BIA typically considers four to six categories:

Time-staged assessment

The special aspect of the BIA: You assess impacts not globally but over time. The outage of a system has different consequences after one hour than after three days.

Typical time intervals:

Calculating outage costs per hour

Quantification in euros makes the BIA tangible for executive management. Not every damage can be precisely quantified, but a well-founded estimate is better than no number.

Direct costs:

• Lost revenue per hour: Annual revenue / working hours per year
• Personnel costs for idle time: Affected employees x hourly rate
• Contractual penalties for delivery delays: Derived from customer contracts
• Costs for external help: IT service providers in emergency mode (often double the hourly rate)

Indirect costs:

• Overtime for rework: Accumulated orders must be processed
• Customer churn: Hard to quantify, but real
• Reputational damage: Long-term impact on order volume

Calculation example for a machine builder:

Annual revenue:          EUR 25,000,000
Working days:            250 per year
Revenue per day:         EUR 100,000
Revenue per hour:        EUR 12,500 (at 8h working day)

Outage of order processing (ERP):
- Hour 1-4:     Personnel idle time, approx. EUR 2,000/h (40 affected employees x EUR 50/h)
- Hour 5-8:     + Lost revenue, approx. EUR 14,500/h
- Day 2-3:      + Contractual penalties (estimated EUR 5,000/day) + express delivery costs
- Day 4-7:      + Customer complaints, beginning churn
- > 7 days:     + Reputational damage, possible termination of framework contracts

These numbers are estimates, and that is fine. The goal is not accounting precision but a reliable order of magnitude that enables prioritization decisions. If the outage of order processing costs EUR 14,500 per hour and the outage of the internal wiki costs EUR 500 per day, the priority is clear.

Step 3: Determine RTO, RPO, and MTD

From the impact assessment, you derive three central metrics that drive the entire subsequent BCM process.

Recovery Time Objective (RTO)

The RTO specifies how long a business process (and the IT systems supporting it) may be down at most before the damage becomes unacceptable. "Unacceptable" is defined together with executive management - typically the point at which impacts shift from "painful but manageable" to "seriously damaging to the business."

The RTO determines how quickly you must recover. It is the central requirement for your recovery plan.

Recovery Point Objective (RPO)

The RPO specifies how much data loss is tolerable, measured in time. An RPO of 4 hours means: You may fall back at most to the data state from 4 hours ago. The RPO directly determines your backup strategy. If the RPO for accounting is 1 hour, you need at least hourly backups or continuous replication.

Maximum Tolerable Downtime (MTD)

The MTD is the absolute upper limit: the point at which the outage becomes existentially threatening. The MTD always exceeds the RTO. The RTO is the target value, the MTD the hard boundary.

Relationship of the three metrics:

|------ RPO ------|------------ RTO ------------|--- WRT ---|
                  ^                              ^           ^
            Last backup              System restored    Validated, normal ops

|-------------------------------- MTD -----------------------------------|
                                                                         ^
                                                            Absolute pain threshold

Example RTO/RPO determination

*Email in the cloud: RPO 0h through provider redundancy

How to determine RTO and RPO

The determination is a negotiation process between business and IT. The business unit says what it needs. IT says what is technically and financially feasible.

What the business unit contributes:

• From when does the outage become critical for business operations?
• How much data loss can be tolerated before manual rework becomes overwhelming?
• Are there contractual obligations (SLAs with customers)?

What IT contributes:

• What recovery times are realistic with the current infrastructure?
• What backup frequency is technically achievable?
• What would it cost to meet the RTO/RPO targets?

Often this discussion reveals a gap: The business unit wants an RTO of 2 hours, but the current backup and recovery infrastructure can manage 8 hours at best. This gap is an important BIA result, and ISMS Lite automatically calculates the GAP analysis between target RTO and actual recovery capability from your inputs. It shows where investment is needed and makes the investment requirement understandable for executive management.

Step 4: Define criticality levels

Not every business process needs the same level of protection. Criticality levels simplify prioritization and make BIA results manageable.

A proven model with four levels:

Level 1: Critical

• RTO: up to 4 hours
• RPO: up to 1 hour
• Impact of outage: Immediate, significant financial damage. Core business at a standstill.
• Examples: ERP system, production control, online shop (for e-commerce)
• Backup/Recovery requirement: High availability or rapid recovery, possibly redundant systems

Level 2: High

• RTO: 4 to 24 hours
• RPO: 1 to 4 hours
• Impact of outage: Significant impairment of daily operations. Employees partially unable to work.
• Examples: Email, payment processing, CRM, VPN for field sales
• Backup/Recovery requirement: Daily full backup, tested restore procedure

Level 3: Medium

• RTO: 1 to 3 days
• RPO: 4 to 24 hours
• Impact of outage: Noticeable limitation, but core business continues. Workarounds possible.
• Examples: Warehouse management, quote creation, document management
• Backup/Recovery requirement: Daily backup, recovery within defined timeframe

Level 4: Low

• RTO: 3 to 7 days
• RPO: 24 hours
• Impact of outage: Low impact on business operations. Inconvenient but not business-critical.
• Examples: Internal wiki, time tracking, archive systems
• Backup/Recovery requirement: Regular backup, no special recovery requirements

The criticality level derives from the impact assessment in Step 2. It is not a gut feeling but is based on the analysis of financial, operational, and regulatory consequences.

Step 5: Uncover dependencies to IT assets

Here it gets technical. Every business process depends on IT systems, and these IT systems in turn depend on each other. Uncovering this dependency chain is one of the most valuable contributions of the BIA.

Process-to-asset mapping

For each business process, you document which IT assets are needed:

Asset-to-asset dependencies

The second level is at least equally important: Which IT assets depend on which others?

Network (Switches, Firewall, DNS)
  +-- Active Directory
       |-- ERP System (SAP B1)
       |    |-- MES System (interface)
       |    +-- Banking Software (interface)
       |-- File Server
       |-- VPN / Remote Access
       +-- Internal Web Applications
  +-- Internet Connection
       |-- Exchange Online
       |-- Cloud Backup
       +-- Banking Software (online banking)

This mapping reveals dependency chains that are not obvious at first glance. When Active Directory goes down, it is not just authentication that fails - all systems that use AD for authentication also go down. A maintained IT asset management provides the data basis for this mapping. This makes AD a single point of failure that may need to be designed with redundancy.

Why dependencies are so important

The dependency analysis delivers three decisive insights:

1. Recovery sequence: You cannot restore the ERP system before Active Directory is running. The dependencies dictate the sequence in the recovery plan.

2. Single points of failure: Systems that many others depend on and that are not redundant pose a particular risk. The BIA makes them visible.

3. Cascade effects: A failure at a deep level (e.g., storage) can affect all systems above it. The BIA quantifies this effect.

Practical example: BIA for a machine builder

Let us walk through a BIA exemplarily. Our fictional machine builder has 150 employees and EUR 25 million in annual revenue.

Starting situation

• Local data center with VMware virtualization
• SAP Business One as ERP system
• MES system for production control
• Exchange Online for email
• Veeam backup to local NAS + weekly offsite tape
• 60% of employees work remotely part-time (VPN)

BIA result: Process assessment

Insights from the example

Several points stand out in this fictional example:

1. Manufacturing control causes more cost per hour than order processing. This is typical for a manufacturing company. When production stops, 80 employees stand idle in the hall, and ongoing costs (personnel, machines, material provisioning) accumulate quickly.

2. Email has an RPO of 0 hours because Exchange Online runs in the Microsoft cloud and Microsoft itself provides redundancy. This significantly simplifies backup planning for this asset.

3. The gap between RTO and actual recovery capability is the real finding. If IT realistically needs 8 to 12 hours for the ERP restore but the business demands an RTO of 4 hours, investment is needed - e.g., in instant VM recovery, a standby environment, or faster storage systems.

4. Outage costs make the business case for investments. When the outage of manufacturing control costs EUR 100,000 per day, the investment of EUR 30,000 for a redundant system is put into perspective.

Conducting the BIA in practice: The process

Preparation (1-2 weeks)

• Define scope: Which areas of the company are analyzed?
• Inventory of business processes (rough, refined in interviews)
• Prepare interview guide
• Schedule appointments with business area heads
• Compile IT asset list (from CMDB, inventory, or manually). The protection needs assessment complements the BIA with the security perspective

Collection (2-4 weeks)

• Interviews with all business area heads (45-60 minutes each)
• Questions: Which processes do you own? Which IT systems do you need for them? What happens in case of outage after 1h/8h/1day/3days? Are there manual workarounds?
• Interview IT department: Dependencies, backup status, realistic recovery times
• Gather financial data: Revenue per day, personnel costs, known contractual penalties

Analysis (1-2 weeks)

• Consolidate and plausibility-check results
• Assign criticality levels
• Derive RTO/RPO/MTD per process
• Map dependencies between processes and IT assets
• GAP analysis: Desired RTO vs. actually achievable RTO

Validation and approval (1 week)

• Present and validate results in a workshop with business area heads
• Inform executive management about results, especially identified gaps
• Finalize and approve the BIA report
• Derive measures (input for recovery plan, backup strategy, investment planning)

Total duration

For a mid-market company with 100 to 300 employees, a complete BIA typically takes 4 to 8 weeks. This is not a full-time project - the actual effort is 40 to 80 person-hours, distributed across the period. The biggest time consumer is scheduling meetings with the business units.

Common mistakes in the BIA

Mistake 1: IT conducts the BIA alone

The BIA is not an IT project. IT can contribute the technical dependencies and recovery times, but the assessment of business impact must come from the business units. Only the sales manager knows what contractual penalties are incurred for delivery delays. Only the production manager can quantify what a day of production standstill costs.

Mistake 2: Impacts are estimated too optimistically

Business units tend to underestimate the impact of an outage because they have never experienced one. Working with concrete scenarios helps: "Imagine your ERP fails completely tomorrow morning. Your 40 employees in order processing cannot work. No access to customer data, no order entry, no delivery notes. What happens after 4 hours? After one day?"

Mistake 3: Dependencies are treated superficially

"The ERP needs a server" - yes, but which one exactly? And what other services does that server need? Active Directory? DNS? Storage? If you stay too superficial with dependencies, you lack the foundation for a meaningful recovery sequence.

Mistake 4: The BIA is done once and then forgotten

Companies change. New systems are added, old ones are retired, business processes evolve. A BIA created two years ago may no longer reflect current reality. Plan an annual update and update the BIA on an ad-hoc basis for significant changes.

Mistake 5: No management buy-in

Without executive management support, the BIA becomes a paper tiger. Business area heads only make time for interviews and workshops when the topic is prioritized from the top. And the investments resulting from the BIA GAP analysis need executive management approval.

From BIA results to recovery plan

The BIA is not an end in itself. Its results flow directly into several operational documents and decisions:

Recovery plan: The BIA provides the prioritized list of business processes and IT assets, the RTO/RPO specifications, and the dependencies. The recovery plan translates these specifications into concrete recovery steps.

Backup strategy: The RPO values determine the required backup frequency. If a system has an RPO of 1 hour, at least hourly backups must run. The BIA thus provides the requirements for the backup strategy.

Investment planning: The GAP analysis (target RTO vs. actual recovery time) shows where investments are needed. Outage costs per hour provide the business case for these investments.

Emergency handbook: The BIA results flow into the emergency handbook, which serves as the overarching document bundling all relevant information for emergencies.

Risk management: The single points of failure and critical dependencies identified in the BIA feed into the risk analysis as risks.

BIA and regulation

Both NIS2 and ISO 27001 require a BIA - directly or indirectly.

NIS2: Article 21 requires "business continuity" and "crisis management." A solid BIA is the prerequisite for meaningfully implementing this requirement. Without a BIA, you do not know which processes to prioritize.

ISO 27001 / ISO 22301: ISO 22301 (Business Continuity Management) explicitly requires the BIA in Section 8.2.2. ISO 27001 references through Annex A.5.29 and A.5.30 the need to analyze the impact of disruptions and create continuity plans based on them.

BSI Standard 200-4: The German BSI standard for Business Continuity Management describes the BIA as a central element and provides a detailed methodology.

Next steps

After the BIA, you have a solid foundation for your entire BCM. The next steps:

1. Create a recovery plan - based on the BIA results, you define the concrete recovery steps per asset.
2. Review backup strategy - do backup frequency and method match the RPO requirements?
3. Build the emergency handbook - BIA results flow in as the foundation for the overarching emergency handbook.
4. Implement GAP measures - where the current recovery level does not match the RTO, investment is needed.
5. Schedule annual updates - the BIA only lives if it is maintained.

Further reading

• Creating a recovery plan: Guide with template for SMEs
• IT asset management for the ISMS: Inventory, criticality, and classification
• Protection needs assessment: Evaluating confidentiality, integrity, and availability
• Risk assessment in the ISMS: Methodology, matrix, and practical example
• IT emergency handbook: Structure, content, and PDF template

In ISMS Lite, you can conduct the BIA directly in the application. Business processes, IT assets, and dependencies are captured in a structured interface, the system calculates criticality levels and RTO/RPO values based on your inputs, and the finished BIA report can be exported as PDF.