Business Impact Analysis: What It Is and How to Do It

A business impact analysis (BIA) is the process of identifying which business processes are critical to your organisation’s operations, assessing what would happen if each were disrupted, and establishing the recovery requirements — time, resources, and dependencies — needed to restore them. For financial institutions, the BIA is not background planning work. It is the analytical foundation that tells you which risks actually matter, which vendors and systems sit inside critical processes, and therefore where your risk management effort needs to concentrate. Without it, your risk register is a catalogue of theoretical threats. With it, your risk register reflects the real exposure of the real organisation. This guide covers what a BIA involves, how to conduct one, how it connects to DORA, ISO 27001, and business continuity planning, and what distinguishes a BIA that satisfies regulators from one that does not.

What a Business Impact Analysis Is — and What It Is Not

A BIA is not a risk assessment. The two are often confused or merged, but they answer different questions. A risk assessment asks: what could go wrong, how likely is it, and how bad would it be? A BIA asks: which of our processes are critical, and what does recovery look like if they fail?

The BIA comes first. It identifies the processes that matter and the dependencies — systems, vendors, people, data — that those processes rely on. The risk assessment then applies threat and vulnerability analysis to the assets and processes the BIA has identified as critical. Without the BIA, the risk assessment has no principled basis for determining which risks to prioritise.

The outputs of a BIA are:

A criticality ranking of business processes. Which processes, if disrupted, would cause the most significant harm — financial, operational, regulatory, or reputational? Criticality should be scored against defined criteria so the ranking is defensible rather than intuitive.

Recovery Time Objectives (RTOs). The maximum period of time within which a process must be restored following a disruption before the harm becomes unacceptable. RTOs are set per process based on the BIA findings, not as a blanket organisational policy.

Recovery Point Objectives (RPOs). The maximum amount of data loss that is acceptable, measured in time — how far back can the system be restored from backup before the loss of data creates unacceptable harm? RPOs drive backup frequency requirements.

Dependency mapping. Which systems, vendors, people, and external services does each critical process depend on? Dependency mapping is what connects the BIA to third-party risk management and to the ICT asset register.

Minimum Business Continuity Objective (MBCO). The minimum level of service that must be maintained during a disruption for the organisation to remain viable — the floor below which disruption becomes critical.

Why Financial Institutions Need a BIA

For a financial institution, the case for a rigorous BIA is regulatory as well as operational.

DORA — the Digital Operational Resilience Act — requires financial institutions to maintain ICT business continuity policies and plans (Article 11). Those plans must be based on a documented impact analysis that identifies critical ICT systems and functions, the dependencies between them, and the recovery requirements for each. The ICT Risk Report that DORA-regulated entities owe their regulator must reflect this analysis. A BIA that is not connected to the ICT risk register or the ICT business continuity plan is not a DORA-compliant BIA — it is a document that exists in isolation.

ISO/IEC 27001:2022, through control A.5.30 (ICT readiness for business continuity), requires organisations to plan, implement, maintain, and test ICT continuity based on business continuity requirements and the results of an impact analysis. The BIA is the required input to A.5.30 — without it, the control cannot be evidenced.

NIS2 — Directive (EU) 2022/2555 — requires essential and important entities to implement measures for business continuity, including backup management, disaster recovery, and crisis management. The BIA provides the documented analysis that underpins those measures.

The regulatory alignment across DORA, ISO 27001, and NIS2 means that a well-executed BIA satisfies requirements across all three frameworks simultaneously — provided it is documented, connected to the risk register and continuity plans, and kept current.

How to Conduct a Business Impact Analysis

Step 1: Define Scope and Assemble Stakeholders

The BIA scope should match your ISMS scope if you are pursuing ISO 27001 certification, or your DORA in-scope entity if you are conducting the BIA for regulatory purposes. Define the scope before beginning — which business units, functions, and geographic locations are included.

The BIA requires input gathered through interviews and surveys with process owners and other key stakeholders across the organisation, including operations, finance, technology, legal, compliance, functional representatives, and service leads. A BIA driven entirely by the security or IT function will miss critical business processes that are not primarily technology-dependent. The goal is a picture of the business as a whole — which functions generate revenue, meet regulatory obligations, maintain customer commitments, and sustain operations.

Step 2: Identify and Catalogue Business Processes

Use a systematic process to list and catalogue every business process within scope. For each process, capture: the business function it supports, the team or unit responsible, the systems and applications it relies on, the data it processes, the internal and external dependencies involved, the external vendors or third parties it depends on, and the regulatory or contractual obligations it fulfils. The goal is identifying critical functions and essential business functions before assessing disruption impact. Different various business units may describe processes differently, so normalise the inventory across the organisation.

The level of granularity matters. “Payment processing” is too broad to be useful as a single BIA entry. “Intraday settlement of domestic card transactions” is the right level — specific enough that disruption can be meaningfully assessed and recovery requirements can be defined.

Step 3: Assess Disruption Impact and Set Criticality

For each process, assess the potential consequences of a disruptive event across four dimensions of business operations:

Financial impact: Revenue loss per hour or day of downtime, including lost sales, delayed sales, contractual penalties, penalties under service level agreements, regulatory fines, and other broader financial implications.

Operational impact: Inability to meet customer commitments, backlog accumulation, manual workaround burden, and, in severe cases, damage to the organisation’s ability to maintain operations.

Regulatory impact: Whether disruption triggers a mandatory notification — under DORA, a payment downtime event above defined thresholds must be reported within four hours; under GDPR, a breach affecting personal data within the disrupted process triggers a 72-hour notification obligation.

Reputational impact: Customer-facing disruption that generates complaints, media coverage, regulatory scrutiny, erosion of customer trust, or damage to business reputation.

Score each dimension against a defined scale (1 to 5 or equivalent) and aggregate to a criticality rating. The assessment should identify which disruptions would have a significant impact and therefore help prioritize recovery efforts. The criticality rating determines the RTO: processes rated critical receive the most demanding RTOs; processes rated standard may tolerate longer recovery periods.

Step 4: Define RTOs and RPOs

For each process rated critical or important, define the RTO and recovery point objective as the core recovery objectives for that process. The recovery point objective sets the maximum acceptable data loss for the process. RTOs and RPOs should be grounded in the impact assessment — not set by technology capability or what seems achievable, but by what the business can tolerate. The Maximum Tolerable Period of Disruption (MTPD) indicates how long an activity can be offline before causing damage and should inform RTO and RPO setting.

If your payment processing team’s assessment shows that four hours of downtime would trigger a DORA notification, the RTO for that process must be set below four hours. If your trading system’s RPO is set at 24 hours but a one-hour data loss would cause unreconcilable positions, the RPO needs to be set at one hour and the backup infrastructure adjusted accordingly.

RTOs and RPOs that are set by IT capacity rather than business requirements are a consistent audit finding. The BIA is how you establish recovery strategies and recovery efforts on the basis of business requirements first, not IT convenience.

Step 5: Map Dependencies

For each critical process, map the full dependency chain: the ICT systems and other technology resources it relies on, the data flows that support it, the internal teams and key personnel whose inputs it requires, the critical systems it depends on, and the other business components and external vendors or third-party services without which it cannot function.

Dependency mapping connects the BIA to third-party risk management by helping assess potential threats and external factors that could disrupt critical business operations. A critical payment process that depends on a single cloud provider without a documented failover arrangement is a concentration risk that must appear in the risk register. A regulatory reporting process that depends on a data vendor whose contract contains no business continuity obligations is a gap that the BIA surfaces — and that the risk treatment plan must address.

Mapping those dependencies is what allows organisations to establish recovery strategies for critical operations based on actual constraints. Under DORA, the dependency mapping also feeds the Register of Information: the BIA identifies which ICT third-party service arrangements support critical or important functions, which determines the enhanced due diligence and contractual requirements that apply to those arrangements under Articles 28 to 30.

Step 6: Validate with Process Owners and Document

A BIA that is produced by the compliance function and filed without validating the outputs of the business impact analysis questionnaire with the process owners it describes is not a compliant BIA. Process owners must review and confirm the criticality ratings, RTOs, RPOs, and dependency maps for their functions. Their sign-off is both an accuracy control — they know their processes better than anyone — and an accountability mechanism that regulators and auditors will look for.

Document the BIA in a formal business impact analysis report. The bia report should include: the scope and methodology, an executive summary, the process inventory with criticality ratings, the RTOs and RPOs for each critical process, the dependency maps, the findings and identified gaps between current recovery capabilities and required RTOs/RPOs, and the sign-off from process owners and senior management.

Step 7: Connect the BIA to Risk Management and Business Continuity Planning

A BIA that produces a report but does not connect to the disaster recovery plan, the business continuity plan, or wider business continuity management activities is incomplete. The value of the BIA is realised when its outputs help develop strategies, prioritise recovery efforts, and ensure business continuity. The aim is to support business resilience by restoring essential functions and critical business functions first:

• Critical business functions with RTOs that current infrastructure cannot meet generate risk register entries requiring treatment
• Dependencies on third parties without adequate continuity provisions generate vendor risk findings
• Gaps between RPOs and current backup frequency generate ICT remediation requirements
• The criticality ranking of processes determines the scope and priority of business continuity and disaster recovery planning

These outputs also inform resource allocation and mitigation strategies across recovery planning.

The BIA outputs should be formally referenced in the business continuity plan, the ICT continuity plan, and — for DORA-regulated entities — the ICT Risk Report.

Maintaining the BIA

A BIA is not a one-time document; it needs ongoing review to maintain resilience against business disruptions and potential disruptions. Business processes change, systems change, vendors change, and regulatory thresholds change. The BIA must be reviewed and updated:

• At least annually as part of the regular ISMS management review cycle
• When significant changes occur to critical processes, systems, vendors, or external factors such as regulatory or supply-chain shifts
• Following a business continuity or disaster recovery test, where test results reveal gaps between assumed and actual recovery capability
• After a significant incident, where actual disruption reveals dependencies or recovery timelines that were not accurately reflected in the BIA

Under DORA, the ICT business continuity policy must be reviewed at least annually and after significant ICT changes or incidents. The BIA review should be synchronised with this cycle.

A business impact analysis is the document that connects compliance to operational reality. Frameworks like DORA, ISO 27001, and NIS2 all require it because regulators understand that risk management without a principled view of what is critical is not risk management — it is documentation. The BIA is how an organisation establishes that principled view, and the quality of everything downstream — the risk register, the continuity plan, the vendor assessments, the ICT Risk Report — depends on the quality of the BIA that feeds them.

How Copla Supports Business Impact Analysis

In Copla, the BIA is the starting point of the compliance programme — not a document that arrives after months of workshops. When a new client onboards, Copla’s AI generates a draft BIA from a company URL or imported files, helping organisations gain insights from it by identifying the organisation’s likely business processes, essential business functions, critical business functions, and ICT dependencies based on publicly available and provided information. The client reviews the draft, adjusts the process inventory and criticality ratings to reflect their operational reality, and confirms the output.

That confirmed BIA feeds directly into two things: the risk register — because the BIA defines which assets and processes are critical, and therefore which risks matter — and the ICT Risk Report that DORA-regulated entities owe their regulator, supporting the organisation’s ability to maintain operations during disruption. The dependency mapping from the BIA populates the vendor register, connecting the criticality of each process to the third-party arrangements that support it and flagging the enhanced due diligence requirements that apply under DORA Articles 28 to 30.

It also helps establish recovery strategies for critical business operations and informs the disaster recovery plan.

The result is a BIA that is not a standalone compliance document. It is the analytical layer that gives the entire Copla programme its structure — the difference between a risk register that reflects the real organisation and one that lists generic threats against generic assets.

Schedule a call with Copla to walk through how this would work for your organisation.