Business Impact Analysis (BIA) explained

A Business Impact Analysis helps you understand which parts of your business are most critical - and what happens if they stop working. This article covers the key concepts and terminology you'll encounter when working with BIA in Kertos.

What is a Business Impact Analysis?

A BIA is a structured process for evaluating how disruptions affect your business. Instead of guessing which systems or processes matter most, a BIA gives you a clear, documented picture of what's critical and how quickly it needs to be restored.

The core idea is simple: for each of your business processes, you assess the impact of it being unavailable across different time periods and damage categories. The result tells you how long each process can be down before the consequences become unacceptable - and that drives your recovery planning.

A BIA does not ask why something failed (that's what risk analysis is for). It only asks: what happens to the business if this process is unavailable for X hours, X days, or longer?

Why does BIA matter?

Without a BIA, recovery decisions happen under pressure with incomplete information. Teams may restore the wrong systems first, over-invest in protecting non-critical processes, or underestimate how quickly damage escalates.

A completed BIA gives you:

• Prioritized recovery order - you know which processes must come back first

• Justified investment - you have evidence for where to spend on redundancy, backups, or contingency plans

• Regulatory compliance - frameworks like NIS2 and ISO 27001 require you to demonstrate that you understand your critical processes and have planned for disruptions

• Audit-ready documentation - your BIA results serve as evidence during certification audits

Which frameworks require BIA?

NIS2 - Article 21(2)(c) requires business continuity measures including backup management, disaster recovery, and crisis management. A BIA is the standard method for identifying which processes need continuity planning.

ISO 27001 - Control A.5.30 (ICT readiness for business continuity) expects organizations to plan and test ICT continuity based on business continuity objectives. A BIA defines those objectives.

DORA - Chapter II requires financial entities to identify critical functions and assess the impact of severe disruptions, which maps directly to a BIA.

BSI Standard 200-4 - Germany's federal cybersecurity authority (BSI) provides a detailed methodology for conducting a BIA as part of its emergency management framework. Kertos aligns with this standard.

Even if your current framework doesn't explicitly mandate a BIA, conducting one is considered best practice for any organization that depends on IT systems to operate.

Key terminology

Business process

A business process is an activity your organization performs to deliver its products or services. Examples include payroll processing, customer onboarding, order fulfillment, or software deployment.

In Kertos, business processes are a type of primary asset. Your BIA is performed at the business process level - you assess the impact of each process being unavailable.

Impact categories

Impact categories define the different types of damage your business could suffer if a process goes down. Common categories include:

• Financial - revenue loss, penalties, contractual fines

• Legal & Regulatory - violations of laws or regulations, missed reporting deadlines

• Reputational - loss of customer trust, negative media coverage

• Operational - cascading effects on other processes, inability to serve customers

You can customize these categories in Kertos to match your organization's risk framework. Most companies use between 3 and 6 categories.

Impact levels

Impact levels describe the severity of damage within each category. A typical scale might be:

• Low - minor or negligible consequences

• Medium - noticeable but manageable consequences

• High - serious consequences requiring significant effort to recover

• Very High - severe consequences that threaten the organization's viability

You define your own impact levels in Kertos, including how many levels to use (typically 3 to 5) and what each one means for your organization.

Time frames

Time frames represent the periods of unavailability you're assessing against. For each business process, you evaluate the impact at different intervals - for example: up to 4 hours, up to 1 day, up to 3 days, up to 1 week.

The point is to understand how damage escalates over time. A process might have low financial impact after 4 hours, but very high impact after 3 days. These escalation patterns are what make BIA results actionable.

Maximum Tolerable Impact Level

This is a company-wide threshold you set in your BIA configuration. It defines the impact level at which the consequences become unacceptable. For example, if your threshold is set to "High," then any process where the impact reaches "High" within a given time frame is considered to have breached the tolerance limit - and that time frame becomes the basis for calculating the MTPD.

MTPD - Maximum Tolerable Period of Disruption

The MTPD is the longest time a business process can be unavailable before the consequences become unacceptable. It's the central output of a BIA.

In Kertos, the MTPD is calculated automatically based on your impact assessment. The system looks at when any impact category first breaches the Maximum Tolerable Impact Level - and that time frame becomes the MTPD.

Example: If you assess "Payroll Processing" and the financial impact reaches "High" at the "up to 3 days" time frame, and your threshold is set to "High," then the MTPD for payroll processing is 3 days.

RTO - Recovery Time Objective

The RTO is the target time within which a process or system should be restored after a disruption. It's a planning target - it tells your IT team how fast they need to get things back up.

The critical rule: RTO must always be shorter than MTPD. If your MTPD says "this process must be back within 3 days," your RTO should be set well below that - for example, 1 day - to give yourself a safety margin.

In Kertos, you set the RTO on your systems and supporting assets. This lets you compare what your business needs (MTPD from BIA) against what your IT team plans to deliver (RTO).

RPO - Recovery Point Objective

The RPO defines the maximum acceptable amount of data loss, measured in time. It answers the question: "If we have to restore from a backup, how much data can we afford to lose?"

An RPO of 4 hours means your backup strategy must ensure that you never lose more than 4 hours of data. An RPO of zero means no data loss is acceptable - which typically requires real-time replication.

Like RTO, the RPO is set on systems and supporting assets in Kertos.

BIA status

Every business process in Kertos has a BIA status that tells you where it stands:

• Not Started - the BIA hasn't been initiated yet

• In Progress - the impact assessment has been started but not completed (or was reopened because of a configuration change)

• Completed - all impact ratings have been filled in and the MTPD has been calculated

• Needs Review - the BIA was previously completed, but something has changed (e.g., new impact categories were added, linked assets were modified) and it should be reviewed for accuracy

How BIA connects to other areas

BIA doesn't exist in isolation. It's the starting point for several downstream activities:

Asset management - Your BIA results are linked to your primary assets, supporting assets, and systems. The RTO and RPO values on your systems should align with the MTPD values from your BIA.

Risk management - Risks linked to critical business processes (those with short MTPDs) may need higher treatment priority. Your BIA helps you justify why certain risks require more attention.

Business continuity planning - BIA results feed directly into your continuity and recovery plans. The MTPD and RTO define the targets, and your plans describe how to meet them.

Who should be involved in a BIA?

A BIA requires input from people who understand the business impact of disruptions - not just the technical details. Typical participants include:

• Business process owners - the people who best understand what happens when a process stops (e.g., Head of Finance for payroll, Head of Operations for logistics)

• IT / Security team - to assess dependencies on systems and provide RTO/RPO data

• Compliance or risk managers - to ensure the BIA meets regulatory requirements and aligns with the organization's risk framework

• Management - to validate the Maximum Tolerable Impact Level and approve the resulting priorities

In smaller companies, one or two people may cover multiple roles. In larger organizations, the BIA is typically coordinated by the compliance or risk team with input from each department.

Frequently asked questions

Do I need to assess every single business process? You should assess every process classified as a primary asset in Kertos. Not all will turn out to be critical - the point of BIA is to separate the time-critical processes from those that can tolerate longer downtime.

How often should I review my BIA? At minimum, once a year. You should also review after significant changes - such as adding new systems, restructuring departments, or experiencing a major incident. Kertos supports review periods and creates tasks to remind BIA owners when a review is due.

What if I don't know how to rate the impact? Start with what you know. Think about what would happen in practical terms: Would you lose revenue? Would you miss a legal deadline? Would customers leave? If you're unsure, involve the process owner - they usually have a clearer picture of the real-world consequences than anyone else.

Is a BIA the same as a risk assessment? No. A BIA asks "what happens if this process goes down?" without considering the cause. A risk assessment asks "what could cause this process to go down, and how likely is it?" They complement each other: BIA tells you what to protect, risk assessment tells you what to protect it against.

What's the difference between MTPD and MTD? They mean the same thing. MTPD (Maximum Tolerable Period of Disruption) and MTD (Maximum Tolerable Downtime) are used interchangeably in different standards. Kertos uses MTPD, which aligns with BSI Standard 200-4 and ISO 22301.