[BCM] [BT] [E4] [R] [BIA] Report

Business Impact Analysis Report

 Summary for Management Approval

Purpose and Scope

This Business Impact Analysis (BIA) covers our eight critical business functions (CBF-1 to CBF-8). It aims to:

1. Confirm and document these critical business functions to ensure accuracy and consistency.
2. Assess their tolerable downtime, cost and non-financial impacts over time;
3. Identify supporting IT systems, interdependencies, and vital records;
4. Provide input to recovery planning, prioritisation, and resource allocation.

We request management’s review and approval of the findings as the basis for the BCM/recovery strategy as we progress.

Part 1: Identification of Business Functions

Summary & Observations

• Eight functions (CBF-1 through CBF-8) have been validated as “critical” in consultation with business units, based on the principle that prolonged disruption to them would cause an unacceptable financial, legal, operational, or reputational impact.
• For each CBF, a Minimum Business Continuity Objective (MBCO) is defined (i.e. the minimal level of service or throughput required during disruption) as captured in Table P1: Critical Business Functions and Business Unit MBCO.
• Each CBF is described in concise terms (e.g. “Process Customer Orders,” “Claims Processing,” “Regulatory Reporting,” etc.).
• The MBCO ensures that in a degraded mode, the business can still meet essential obligations (e.g. legal/regulatory service levels, customer commitments) even under constrained capacity.

Implications for Planning

These eight functions will be the focus of decision-making (e.g. which to restore first, what interim workarounds are acceptable). Non-critical functions not listed here may be deferred or suspended during major incidents.

Part 2: Impact Area of Business Functions

Summary & Observations

• Using the impact categorisation in Table P2: Impact Area of Business Functions for CBF-1 to CBF-8, each CBF has been assessed across impact dimensions (financial, customer, regulatory, reputation, staff safety, etc.).
• For each function, management has agreed on a Recovery Time Objective (RTO) or tolerable downtime that aligns with the severity of the impact if the function is delayed.
• Some CBFs are designated “immediate” (i.e. must be restored within hours), others are “short-term” (within 1–2 days), and a few are “medium-term” (within several days), reflecting differential criticality.

Key Insights/ Risk Flags

• A few functions have very low tolerance for downtime; e.g. loss beyond a few hours leads to cascading regulatory or customer damage.
• Some interdependencies (e.g., upstream data feeds, core infrastructure) may limit our ability to meet those RTOs if they are not explicitly catered for in planning.

Management should particularly note any CBFs whose assigned RTOs are aggressive and may require investment or pre-positioning of resources.

Part 3: Impact Over Time of Business Functions

Summary & Observations

• Table P3: Impact Over Time captures how both hard (financial) and soft (non-financial) impacts escalate as downtime extends (e.g. 0–4 hours, 4–24 hours, 1–2 days, 3–5 days, >5 days).
• For each CBF, the cost of delay is modelled cumulatively: direct revenue loss, penalty costs, legal liabilities, customer attrition, reputational loss, regulatory fines, compliance costs, and internal recovery costs.
• A typical pattern emerges: in the early phases (the first few hours), the impact is modest; however, beyond 24–48 hours, non-financial impacts (e.g., reputational, regulatory) dominate and escalate steeply.

Highlights to bring to management’s attention

• Some CBFs show nearly exponential cost escalation after a threshold (e.g. 48 hours) — indicating that beyond a certain point, every additional hour is far more damaging.
• For mid-range CBFs, even a 2- to 3-day disruption can seriously threaten viability or competitiveness.
• Predefined “breakpoints” exist where a function shifts from tolerable to intolerable loss; these drive prioritisation.

Recommendation

Use these escalation curves when making go/no-go recovery decisions, rather than relying solely on linear cost assumptions.

Part 4: Supporting IT Systems and Applications

Summary & Observations

• Table P4: Supporting IT Systems and Applications for CBF-1 to CBF-8 lists the key systems, databases, applications, interfaces, and infrastructure components underpinning each CBF.
• For each critical function, we have identified the dependencies: which systems must be operational (or in degraded mode) to support even the MBCO level.
• Also captured are the data flows, integration points, and service dependencies (both internal and external).

Risks & Gaps Identified

• A few legacy systems lack modern redundancy or disaster recovery — their failure could stall dependent CBFs.
• Some CBFs rely on shared infrastructure (e.g., core databases, a messaging bus), meaning a failure in that shared component could cascade across multiple functions.
• Recovery of IT systems themselves may have longer RTOs than the business functions demand, unless mitigated.

Action item

Match IT recovery priorities to business function priorities, and ensure adequate backup, failover, and resilience design accordingly.

Part 5: Inter-Dependencies

Summary & Observations

• Table P5: Inter-Dependencies for CBF-1 to CBF-8 captures the internal and external dependencies among CBFs, supporting functions, third parties, and suppliers.
• Dependencies are categorised as upstream (inputs needed by a CBF) or downstream (outputs consumed by other functions).
• Some CBFs depend on one another (e.g. CBF-3 may depend on output from CBF-1). Others rely heavily on external providers (e.g. data suppliers, regulatory reporting services, third-party hosts).

Key Dependency Risks

• A domino effect is possible: failure in one function or supporting service could block other CBFs even if their own systems are intact.
• External third parties with weaker continuity capabilities are weak links; their failure would jeopardise our service chain.
• Some dependencies are “silent” (less visible in daily operations) but material under duress; these must be stress-tested.

Recommendation

Recovery planning must reflect the dependency graph: prioritising “shared services,” alternate providers, fallback interfaces, and manual workarounds for dependencies.

Part 6: Vital Records

Summary & Observations

• Table P6: Vital Records for CBF-1 to CBF-8 enumerates the critical documentation, master data, operating records, contracts, regulatory filings, audit logs, and backup archives required to sustain or restore each business function.
• For each CBF, the necessary vital records include: data sources, record formats, retention requirements, location (onsite, offsite, archived), and accessibility in the event of a degraded state.
• Records include both electronic databases and hard-copy records (e.g., legally binding contracts, licenses, customer agreements).

Risks & Recommendations

• Some vital records are stored only on primary live systems, with no robust backups or redundancy, which could severely hamper recovery in the event of loss or corruption.
• Physical records stored on-site may be inaccessible after specific incidents (e.g., fire or flood).
• Some records require controlled access (regulatory or security), so their availability during incidents must be carefully planned.

We recommend verifying that vital records are digitised (if not already) and off-site replicated, and that they are included in the recovery (or alternate operations) blueprint.

Overall Findings & Recommendations for Management Approval

Prioritisation & Sequencing

• Based on the RTOs, impact escalation curves, and dependency map, a clear priority ranking emerges among the eight CBFs. We propose that CBFs with high escalation exposure and direct customer or regulatory impact be restored first, followed by mid-critical ones, then lower ones as resources permit.
• Shared infrastructure and “dependency hub” functions (e.g. core databases, transaction processing layers) may need to be recovered even earlier than some business functions to unlock them.

Resource and Investment Implications

• To meet the aggressive RTOs for certain CBFs, additional resilience investments will be needed (e.g. high-availability systems, alternate sites, automated failover).
• Some CBFs may require “pre-seeding” of temporary capacity or buffer resources (such as staff and backup infrastructure) to maintain operations during the transition.
• Testing and drills should validate that dependencies hold under stress, and that vital records are retrievable under degraded modes.

Next Steps (Post Approval)

1. Use this BIA as the basis for a Recovery Strategy Workshop with business & IT stakeholders.
2. Develop Recovery Plans (Phase/Function-level) — workarounds, alternate workflows, manual fallback, IT restoration plan.
3. Prioritise investments and budget allocation based on cost-benefit analysis (cost to improve resilience vs. avoided loss).
4. Run tabletop and full-scale drills to validate assumptions, uncover hidden gaps (especially cross-functional dependencies).
5. Review and refine the BIA periodically (at least annually) or when significant changes occur in processes, systems, or the environment.

Implementing Business Continuity Management for Bandtree: A Practical Guide
eBook 4: Consolidate and Report Your BCM Implementation
BIA Report (Part 1 to Part 6)
BIA Consolidated Report (Part 1 to Part 6)

To learn more about the course and schedule, click the buttons below for the  BCM-300 Business Continuity Management Implementer [BCM-3] and the BCM-5000 Business Continuity Management Expert Implementer [BCM-5].

 

	Please feel free to send us a note if you have any questions.