The Business Impact Analysis is the most technically demanding activity in BCMS implementation. It is also the activity that most often produces unreliable outputs — because the BIA is information-intensive, politically sensitive, and dependent on the quality of interviews with process owners who may not have time or motivation to participate fully. The BIA requires the BCM team to ask difficult questions: if this activity is unavailable, what exactly is the impact on revenue, operations, regulatory standing, and reputation? How does the impact change over time? At what point does the impact become catastrophic? What minimum resources are needed to recover the activity within the target timeframe? These are questions that process owners may not have considered before; they do not have prepared answers, and they may be uncomfortable discussing the implications.
A weak BIA produces weak BCPs. If the BIA has not accurately identified the critical activities, the BCP programme will either leave actual critical activities unplanned or will create plans for activities that are not actually critical. If the BIA has not accurately assessed impact, the RTO and RPO targets will be either too relaxed (allowing unacceptable downtime) or too tight (requiring unachievable recovery speed and resources). If the BIA has not identified resource requirements, the BCPs will assume resource availability that will not materialise during an actual disruption.
This article is a practitioner guide to conducting a BIA that produces reliable, audit-ready outputs. The guidance assumes a medium-sized financial services organisation in Indonesia (500–5,000 employees, multiple sites, complex IT infrastructure, regulatory requirements) and is structured around the four-step BIA methodology: process discovery and critical activity identification, impact assessment over time, target-setting (MAO, RTO, RPO, MBCO), and resource requirements.
BIA Methodology: The Four Steps
The BIA is a structured process that progresses through four stages, each building on the outputs of the previous stage. The process typically spans 6–10 weeks of active work (depending on organisational complexity) and requires dedicated effort from a BIA team (typically 1–2 BCM staff plus 1–2 external facilitators if external support is engaged) and time contributions from process owners across the organisation.
Each of the four steps has specific inputs, a defined methodology, and documented outputs that feed into the next step. The outputs of each step are validated with stakeholders before the team moves to the next step; validation workshops (typically 2–3 per step) are where inflated assumptions or incomplete analysis are identified and corrected. The BIA process is iterative — for example, the initial impact assessment may identify a resource requirement that changes the RTO, which then requires re-assessment of whether the new RTO is achievable with the resources identified. This iteration is normal and should be expected.
Step 1 — Process Discovery and Critical Activity Identification
The first step of the BIA is to create a complete inventory of business processes and to identify, from that inventory, which activities are critical to the organisation’s survival and continuity. Critical activities are defined by impact: an activity is critical if its unavailability, sustained for a defined period, would result in financial loss, operational paralysis, regulatory breach, or significant reputational damage. An organisation with 200+ processes may have only 15–30 critical activities.
Process discovery begins with interviews with department heads and business unit leaders. The BCM team asks: what processes does your business unit own, what do these processes accomplish, who are the customers of each process (internal and external), and what inputs and outputs does each process have? The outputs of this discovery are documented in a process inventory — a spreadsheet or database listing each process, its owner, its inputs, outputs, and primary dependencies. The process inventory is the master list from which critical activities are identified.
Critical activity identification is then performed by applying criticality criteria to the process inventory. Criticality criteria typically include: financial impact (does the process generate revenue, and if it is unavailable, how quickly does revenue loss occur?), operational impact (does the process support other critical activities, and what is the cascading impact?), regulatory impact (are there regulatory obligations that depend on this process?), and reputational impact (would the customers of this process be aware of its absence, and would they interpret the absence as a service failure?). For each process in the inventory, the team assesses it against these criteria and makes a criticality determination: critical, important, or non-critical. A four-cell matrix (High Impact x High Likelihood) helps identify processes that are critical by multiple dimensions.
Step 2 — Impact Assessment Over Time
Once critical activities have been identified, the BIA team works with process owners to assess the impact of disruption, measured over time. The impact assessment asks: if this activity is unavailable for 4 hours, what is the impact? For 24 hours? For 72 hours? For a week? The impact is assessed across four dimensions: financial (revenue loss, cost increases, penalties), operational (degradation of service, backlogs, manual workarounds), regulatory (approaching notification obligations, breaches of regulatory commitments), and reputational (customer complaints, escalations, media attention).
The impact assessment produces an impact-over-time matrix that shows how impact increases over the duration of disruption. For most critical activities, impact is non-linear: there may be minimal impact in the first 4 hours (staff can work around the disruption), but impact accelerates in hours 8–24 (manual workarounds reach capacity), and becomes catastrophic by 72 hours (backlogs are unmanageable and cannot be recovered). The shape of the impact curve varies by activity: some activities (e.g., payments processing) have almost immediate financial impact, while others (e.g., customer communications) may have delayed reputational impact that is not felt until days later.
Maximum Acceptable Outage (MAO) is derived from the impact-over-time assessment. MAO is the time point at which the impact crosses from “significant but survivable” to “potentially catastrophic”. For a payment processing function, MAO might be 4–8 hours; for a customer communications system, MAO might be 24–48 hours. The identification of MAO is a business decision, not a technical decision — it requires the involvement of department heads and (often) executive leadership, because it establishes the acceptable threshold of business impact.
| Impact Dimension | 4 Hours | 24 Hours | 72 Hours | 1 Week |
|---|---|---|---|---|
| Financial impact | Revenue loss: Rp 200M | Revenue loss: Rp 1.2B | Cumulative loss: Rp 4B | Contract penalties triggered: Rp 10B+ |
| Operational impact | Manual processing possible with degradation | Manual processing at capacity limit | Manual processing fails; backlogs unmanageable | Operational paralysis |
| Regulatory impact | Notification obligation approaching | OJK notification required | BI reporting obligation triggered | Regulatory investigation initiated |
| Reputational impact | Internal only | Client awareness beginning | Media attention possible | Significant reputational damage |
| Customer/stakeholder impact | Delays noticed | Complaints escalating | Client escalations to senior management | Contract reviews initiated |
| KEY IDEA | MAO is determined by the point at which the impact crosses from “significant but survivable” to “potentially catastrophic”. For each critical activity, the BIA team must assess impact across all four dimensions — financial, operational, regulatory, reputational — and identify the time point at which any one dimension reaches an unacceptable threshold. That time point is the MAO. RTO must be set shorter than MAO to provide a recovery margin. |
Step 3 — Determining RTO, RPO, and MBCO
RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are derived from the impact assessment, not invented from technical convenience. RTO is the maximum acceptable time to restore the critical activity to a minimum viable operating state. RPO is the maximum acceptable data loss measured in time — e.g., ""we can accept that the last 4 hours of transactions will be lost"". For most activities, RTO must be shorter than MAO to provide a recovery margin; if MAO is 8 hours and actual recovery takes 7 hours, there is no safety margin.
Setting realistic RTO and RPO requires stakeholder dialogue. Process owners often initially provide optimistic estimates (""we need 2 hours"") based on what they believe the business should tolerate, rather than realistic estimates of what the process can actually deliver at minimum viable operating level. Validation workshops, where impact assessment is reviewed and RTOs are challenged, often reveal that initial RTO estimates are not achievable with the resources available. The resolution is either to increase resources (and cost) to achieve the stated RTO, or to revise the RTO upward to reflect the realistic recovery time with available resources. This negotiation happens in Step 3; it cannot be left for later when BCPs are being written.
MBCO (Minimum Business Continuity Objective) is the minimum scope of the activity that must be restored by RTO. MBCO is not always “all operations at normal capacity”; often it is “80% of transaction capacity” or “customer-facing services only, not internal reporting”. Defining MBCO clearly prevents BCPs from attempting to restore full capacity on the unrealistic timescale of RTO; instead, BCPs focus on restoring the minimum scope required by the business.
Step 4 — Resource Requirements at RTO
The final step of the BIA is to identify the minimum resources required to operate each critical activity at MBCO by the RTO. Resource requirements are assessed across five categories: people (who must be available, what skills are required, who can substitute), premises (where the activity can be performed if primary site is unavailable), technology (which systems and data must be available), suppliers (which external suppliers are critical), and vital records (what documents and data must be accessible). The resource assessment is forward-looking: it assumes the disruption is real, primary resources are unavailable, and only backup resources or alternate arrangements are available.
For each critical activity, the BIA team documents a resource requirements summary that lists minimum staffing, preferred working location, critical systems, supplier dependencies, and vital records. This summary is not “what we have” but “what we need at RTO to operate at MBCO”. The gap between what we need and what we have available (or what we can procure in advance) becomes the scope of the BC strategy: what will be pre-positioned, what will be contractually committed, what will be procured on-demand.
| Resource Type | Questions to Ask | BIA Output | BCP Application |
|---|---|---|---|
| People | Who are the minimum staff to operate this activity? What skills are essential? Who can substitute? | Minimum staffing at RTO; key-person dependencies; succession requirements | BCP activation team list; cross-training requirements; succession procedures |
| Premises | Where can this activity be performed if primary premises are unavailable? What space is required? | Alternate working location requirements; minimum space specification | Alternate site strategy; work-from-home policy; equipment pre-positioning |
| Technology | Which systems must be available to perform this activity? What is the minimum viable technology configuration? | Technology dependencies; RPO per system; minimum viable configuration | ICT continuity plan scope; recovery priority; DR architecture requirements |
| Suppliers | Which external suppliers are essential to this activity? Do they have BCM programmes? | Critical supplier list; supplier dependency mapping | Supplier BCM requirements; dual-sourcing decisions; contractual BCM clauses |
| Information / Data | What data and documents are needed to operate this activity? Where are they stored? | Vital records list; data location mapping | Backup requirements; offsite storage; physical document access during disruption |
BIA Governance and Validation
BIA outputs must be validated by the people who will live with them. The validation process includes two formal workshops: a mid-BIA validation (end of Step 2, once critical activities and impact assessment are complete) and a final BIA validation (end of Step 4, once all resource requirements are determined). Each workshop gathers department heads, process owners, and executive leadership to review the BIA findings, challenge assumptions, and correct any errors or omissions.
BIA governance includes decisions about which stakeholders must sign off on critical outputs. Typically, critical activity determination is approved by executive leadership; impact assessment and MAO are approved by process owners and their department heads; and final BIA approval is given by the executive sponsor of the BCMS programme. Requiring sign-off at each stage ensures that the BIA reflects business realities and that stakeholders are committed to the RTO and resource requirements they have agreed to.
BIA review cycles should be scheduled before the BIA project is closed. BIA reviews are triggered by organisational change (significant business change, restructuring, acquisition), technology change (system replacement, retirement), supply chain change (loss of a supplier, addition of a critical supplier), and BCP exercise findings. A scheduled annual BIA review ensures that the document is refreshed at least once per year; a change-triggered review ensures that major changes do not leave the BIA stale.
| IMPORTANT | BIA outputs must be validated by the people who will live with them. A BIA conducted entirely by the BCM team, without validation workshops with department heads and process owners, produces targets that reflect BCM team assumptions rather than operational reality. The validation workshop is where inflated RTOs (”we said 2 hours but actually we could manage 24”) and underestimated resource requirements (”we said 3 people but we need 8”) are corrected before they become embedded in BCPs that cannot be met. |
| BITLION INSIGHT | In Indonesian financial services BIAs, the most consistently underestimated resource at RTO is people — specifically, the people who know the manual workarounds. Core banking systems have detailed ICT recovery plans. The operational workarounds that keep the business running while the system is being recovered — manual transaction processing, paper-based reconciliation, phone-based customer service — depend on staff who know how to do things without the system. Identifying these people in the BIA, and ensuring they are in the BCP, is the difference between a business continuity plan and a system recovery plan. |