Clause 6 is the most technically demanding planning clause in any ISO management system standard because the Business Impact Analysis methodology is genuinely complex. The BIA is not a simple risk register or a process documentation exercise. It is a structured analysis of the impact that would result from the disruption of specific business activities. BIA quality determines the validity of everything built on top of it — the continuity strategy, the recovery objectives, the plans themselves, and the resource allocation decisions.
If the BIA is weak — conducted superficially, based on assumptions rather than analysis, missing critical dependencies, or not validated with process owners — the resulting continuity strategy will be misaligned with actual business requirements. Plans built on a weak BIA may look complete but will fail under an actual disruption. Conversely, a rigorous BIA, conducted through structured interviews with process owners and validated through workshop discussion, produces BCMS outputs that reflect how the business actually operates.
This article addresses the Business Impact Analysis methodology, the risk assessment process specific to business continuity, the establishment of BCMS objectives, and how to translate analytical outputs into strategy decisions. It is the most detailed of the Clause sections because the processes it describes are foundational to everything that follows.
The Structure of Clause 6
Clause 6 has three principal sub-clauses: 6.1 addresses actions to address risks and opportunities relevant to the BCMS itself (not the BIA — this is the risks that could prevent the BCMS from achieving its objectives); 6.2 is the largest sub-clause, addressing the Business Impact Analysis, risk assessment for business continuity, and BCMS objectives; and 6.3 addresses planning to achieve those objectives.
The logical flow is: Identify the business context and critical activities (Clause 4); identify risks and opportunities that affect the BCMS programme (6.1); conduct a detailed BIA to understand the impact of disruption (6.2); assess the threats to critical activities and their likelihood (6.2); establish continuity objectives and strategies to address those risks (6.2); and plan the actions needed to implement the strategy (6.3). This sequence ensures that strategy and plans are grounded in evidence, not assumption.
Actions to Address Risks and Opportunities (6.1)
Clause 6.1 addresses risks and opportunities to the BCMS programme itself — risks that could prevent the BCMS from achieving its objectives. These are distinct from the business risks that the BCMS is designed to address. Examples include: insufficient resources allocated to the BCM programme (risk), lack of competence in BIA methodology (risk), resistance from departments that view continuity as overhead (risk or opportunity to improve engagement), or emerging technology capabilities that enable new recovery approaches (opportunity).
The process is to identify such risks and opportunities, evaluate them, and plan actions to address them. This is captured in a document and reviewed as part of the BCMS management process. It is not a comprehensive risk assessment of the business (that is addressed in Clause 6.2); it is a focused assessment of what could affect the BCMS programme’s ability to function.
The Business Impact Analysis (6.2)
The Business Impact Analysis is the central analytical process of the BCMS. It is a structured process to identify all activities that support the organisation’s products and services, determine the impact that would result from the disruption of each activity, identify the dependencies that support each activity (personnel, premises, technology, suppliers, information), and establish the recovery time objective and data loss tolerance for each critical activity.
The BIA methodology is: (1) Identify all activities that support the organisation’s products and services — this typically involves process mapping or workflow documentation; (2) For each activity, determine what impact would result from disruption — financial impact, regulatory impact, reputational impact, impact on other activities; (3) Determine how long the organisation can tolerate disruption before impact becomes unacceptable — the Maximum Acceptable Outage (MAO); (4) Identify the dependencies that support each activity — who needs to be involved, what technology needs to be running, what information is needed, what suppliers must continue delivering; (5) Establish the Recovery Time Objective (RTO) — how quickly the activity must be restored to meet the MAO — and Recovery Point Objective (RPO) — the maximum acceptable data loss; (6) Establish Minimum Business Continuity Objective (MBCO) — what the reduced or alternate service level looks like during recovery; and (7) Prioritise the sequence in which activities must be recovered.
The BIA is typically conducted through a combination of process owner interviews, workshops with cross-functional teams, and analysis of existing documentation (process maps, system diagrams, organisational charts). The interviews are structured around specific questions: What products and services does your area deliver? What would happen if those services were unavailable for 4 hours? For 8 hours? For 1 day? What people are essential? What systems are essential? What information is essential? What suppliers are essential?
| BIA Requirement | What ISO 22301 Specifies | Common Implementation Error |
|---|---|---|
| Identify activities supporting products/services | Identify all activities that support the organisation’s products, services, and regulatory obligations | Only identifying “big” activities; missing back-office activities that are essential (e.g., compliance, risk management, financial close) |
| Determine impact of disruption on those activities | Analyse what happens if the activity stops: financial impact, client impact, regulatory impact, operational impact, reputational impact | Estimating impact as a binary (critical/not critical) without quantifying financial or timeline impact; failing to identify knock-on impacts (e.g., if payment processing fails, customer complaints follow within hours) |
| Establish MAO for each critical activity | Determine the maximum time the activity can be disrupted before impact becomes unacceptable | Setting MAO without business justification; using round numbers (4 hours, 8 hours) without analysis; failing to distinguish between different activity criticalities |
| Identify dependencies (people, premises, technology, suppliers) | For each critical activity, identify who must be involved, what systems must run, what physical location is required, what suppliers must continue delivering | Identifying “the IT system” without naming the specific system; missing single points of failure (e.g., one person who understands a critical process); assuming dependencies without validation |
| Establish RTO | Determine how quickly the activity must be recovered to avoid crossing the MAO; distinguish between different activities (core function vs. support function) | Assuming RTO = MAO (in reality, recovery takes time, so RTO should be shorter than MAO to provide a buffer); setting RTO without considering recovery execution time |
| Establish RPO | Determine the maximum data loss tolerance: can the activity operate with yesterday’s data or does it need real-time data; how frequently must backups occur | Assuming RPO = RTO (different concepts: RTO is time to restore service; RPO is data currency); failing to quantify (e.g., “minimal data loss” is not a valid RPO specification) |
| Establish MBCO | Define what “reduced service” means for the activity during recovery — is it 50% capacity, manual workarounds, or alternate suppliers; what service level is acceptable temporarily | Conflating MBCO with normal operations (MBCO is by definition reduced); failing to document what MBCO operationally means (which transactions are processed, which are queued, how long are customers waited) |
| Prioritise recovery sequence | Determine the order in which activities should be recovered: which first, which second, accounting for dependencies between activities | Prioritising all activities equally (not possible in a disruption); failing to account for dependencies (e.g., cannot recover trading system until data centre is operational) |
| KEY IDEA | The BIA is not a risk assessment. It assesses the impact of disruption — what happens when an activity stops — not the likelihood of the disruption occurring. Risk assessment is a separate process (Clause 6.1 and the BC-specific risk assessment described below in Clause 6.2) that identifies threats to critical activities and informs the continuity strategy. The Business Impact Analysis asks: “If this activity stopped, what would happen?” Risk assessment asks: “What could cause this activity to stop, and how likely is it?” Conflating BIA and risk assessment produces an analysis that does neither correctly and obscures the connection between threat likelihood and impact severity. |
Risk Assessment for Business Continuity (6.2 continued)
The risk assessment for business continuity is the complement of the BIA. The BIA identifies what activities are critical and what the impact of disruption would be. The risk assessment identifies threats to those critical activities and assesses the likelihood that those threats would occur. Together, the BIA and risk assessment inform the strategy — investment in recovery capability is justified when there is a significant threat to an activity with severe impact.
Threats to business activities fall into several categories: natural disasters (earthquakes, flooding, volcanic activity, weather events), technology failures (system outages, data centre failures, network failures, cyber incidents), personnel unavailability (illness, key person departure, mass casualty events), supplier failures (key supplier bankruptcy, service interruption), premises unavailability (building access denial, damage, loss), utilities failures (power outages, water supply disruption), and deliberate acts (sabotage, terrorism, civil unrest).
The risk assessment process is to identify relevant threats (based on geography, industry, technology environment, and threat landscape), estimate the likelihood of each threat (rare, unlikely, possible, likely, almost certain), estimate the consequence if the threat occurs (from the BIA), evaluate the risk (likelihood × consequence), and determine whether the risk is acceptable or requires treatment. For example, if an organisation has a critical system that would fail catastrophically if power is lost for more than 30 minutes, and the location experiences power outages that last on average 4 hours twice per year, the risk is high (high consequence, possible likelihood) and treatment is required (backup power, alternate site, etc.).
| Threat Category | Example Scenarios for Indonesian Organisations | BIA-Linked Impact |
|---|---|---|
| Natural disaster — Earthquake/tsunami | Sumatra and Java are on the Pacific Ring of Fire; significant earthquakes occur periodically; tsunami risk affects coastal areas; recent major events: 2004 Indian Ocean earthquake, 2018 Palu earthquake, 2022 Fukuoka earthquake | If head office in Jakarta or alternate site in Bandung is damaged, can the organisation operate from regional offices or a third location? How long can disruption be tolerated before business impact is unacceptable? |
| Natural disaster — Flooding | Jakarta experiences regular monsoon flooding affecting ground-floor offices and street-level access; Kalimantan flooding disrupts regional operations; climate change increasing flooding frequency | Access to physical location may be blocked for hours or days; data centre cooling systems may be affected; staff may be unable to commute; recovery strategy must account for geographic isolation |
| Cyber incident — Ransomware | Ransomware targeting Indonesian financial institutions has caused multi-week service disruptions; supply chain compromise common; backup systems may be encrypted alongside primary systems | Encrypted data is unrecoverable without decryption key; off-site backups must be maintained independently; recovery relies on isolated, tested backup copies; business decisions required on ransom negotiation and notification timelines |
| Supplier failure — Cloud provider outage | Single SaaS provider failure; regional data centre outage; API failure affecting multiple integrated systems; no geographic redundancy; dependent suppliers also fail | If the cloud provider fails, the organisation loses access to customer data, email, transaction systems; recovery time depends on provider capability; contractual recovery commitment from provider is essential; alternative suppliers may not exist |
| Personnel — Mass illness / pandemic | COVID-19 pandemic severely disrupted Indonesian operations; potential for future pandemic; key personnel concentrated in single location | If critical staff are unavailable, can processes continue with reduced staff? Can remote working be activated? Are decision-makers reachable? Do documented procedures exist that do not require subject-matter-expert knowledge? |
| Premises — Building access denial | Facility damage, building lockdown, security incident preventing access, civil unrest or curfew preventing travel, fire in building affecting access even if office space remains usable | If staff cannot physically access the office, does remote working capability exist? Can operations move to alternate site? What functions can continue remotely and which require physical presence? |
| Technology — Legacy system failure | Core banking system no longer supported by vendor; specialised system with single point of knowledge; limited alternative vendors; expensive replacement or upgrade | If the legacy system fails, what is the recovery time? Does a workaround process exist? Is there alternate technology capable of sustaining the activity? Recovery may require manual processes pending system restoration |
| Utilities — Extended power outage | Power outages lasting hours to days are common in some regions; extended power disruptions affecting entire cities during peak demand or natural disasters | Without power, technology systems fail; diesel generators require fuel and maintenance; cooling systems fail affecting technology infrastructure; recovery time depends on utility restoration; critical systems require UPS or generator backup |
BCMS Objectives and Planning to Achieve Them (6.3)
Based on the BIA, risk assessment, and the organisation’s risk appetite, the organisation establishes measurable BCMS objectives. These are not the same as business objectives (revenue, market share); they are objectives for the BCMS programme itself. Examples include: “Achieve 95% or greater RTO attainment rate in annual exercises”, “Continuity plans for all critical activities updated within 12 months”, “All personnel in critical recovery roles trained annually”, “Risk assessment for critical activities reviewed annually and updated when significant changes occur”.
The objectives must be measurable (with a clear target and metric), achievable (given organisational resources and constraints), relevant (addressing the most significant risks and impacts identified in the BIA and risk assessment), and time-bound (achieve by X date). They must also be communicated to relevant people in the organisation and monitored during the management review process.
| IMPORTANT | RTO targets set without BIA evidence are guesses. An organisation that sets a 4-hour RTO for its core banking system without a BIA that analyses actual financial impact, regulatory impact, and customer impact over time has no basis for that number. It may be too conservative, wasting recovery investment, or too generous, failing to meet regulatory or contractual obligations. ISO 22301 Clause 6.2 is explicit: Maximum Acceptable Outage and Recovery Time Objective must be determined through the Business Impact Analysis process, not assumed or set arbitrarily. Auditors examine the chain: BIA identifies impact over time; MAO is set based on that impact analysis; RTO is derived from the MAO with a safety margin. Objectives without this evidence trail are findings. |
| BITLION INSIGHT | The most valuable BIA outputs in Indonesian BCMS implementations are the ones that surface dependencies that were assumed but never documented. Repeatedly, the BIA interview process reveals that a critical business process depends on a single supplier’s API, that the organisation’s entire customer database is held by a single cloud provider with no contractual recovery commitment, that three critical processes share one key subject-matter expert who has never cross-trained a successor, or that the technology infrastructure depends on a single telecommunications provider. These discoveries are the most operationally important outcomes of the BIA — and they are only possible if the BIA is conducted through structured interviews with process owners, not by circulating a template and asking people to fill it in. Invest time in the BIA process. |