Clause 4 is the foundation of the entire BCMS. Everything that follows — the scope, the objectives, the strategies, the plans — is derived from the analysis required at Clause 4. If you do not understand your organisation’s context accurately, you will build a BCMS that is either insufficient to cover critical risks or so broad that it is unmanageable. Getting Clause 4 right is the prerequisite to building a BCMS that is proportionate and effective.
The context of the organisation includes both internal factors — the way the organisation is structured, its technology dependencies, its contractual obligations to clients and suppliers — and external factors — the regulatory environment, market conditions, natural disaster exposure, geopolitical risks, and the threat landscape. The BCMS must address the organisation as it actually operates, accounting for the constraints and opportunities that context presents.
ISO 22301 Clause 4 is not a one-time compliance exercise. As the organisation changes — new technology platforms are introduced, new regulatory requirements emerge, the supply chain shifts, key talent moves, or the business pivots into new markets — the context analysis must be updated. The management review cycle (Clause 9) is the mechanism through which the organisation ensures its context understanding remains current.
What Clause 4 Requires
Clause 4 has four sub-clauses, each addressing a distinct aspect of context. Clause 4.1 requires the organisation to determine the internal and external context — the factors that affect the organisation’s ability to achieve its objectives. Clause 4.2 requires the organisation to identify interested parties and their requirements relevant to the BCMS. Clause 4.3 requires the organisation to determine the scope of the BCMS — what organisational units, processes, sites, systems, and suppliers are included. And Clause 4.4 requires the organisation to establish the BCMS and determine how its processes interact with other business processes.
These four sub-clauses together establish the boundary and the foundation of the BCMS. They answer the questions: What is our context? Who are our stakeholders? What goes in scope? How does the BCMS operate as a system? No other clause in ISO 22301 can be properly addressed without first answering these questions.
Importantly, Clause 4 does not require a perfect or permanent analysis. It requires a documented analysis that is kept current. The analysis is revised at planned intervals (management review) and when significant changes occur in the organisation or its environment. This iterative approach means that organisations can start with a reasonable assessment of context and refine it over time as they learn.
Understanding the Organisation and Its Context (4.1)
The internal context of the organisation encompasses the organisational structure and culture, governance arrangements, decision-making authority, the technology platforms on which critical activities depend, the human resources and key personnel, the existing business continuity maturity, contractual and financial constraints, and the supplier and partner ecosystem. An organisation cannot develop an effective BCMS without understanding how it is structured, what it depends on, and what constraints or capabilities it brings to continuity planning.
The external context includes the regulatory environment — in Indonesia, this means OJK POJK 11/2022 for financial services, Bank Indonesia directives for banking, the Personal Data Protection Law (UU PDP) for data handling, and BSSN cybersecurity standards. It also includes market conditions, competitive pressures, natural disaster exposure (Indonesia’s location on the Pacific Ring of Fire and monsoon patterns), geopolitical risks, supply chain geography, technological trends that create new dependencies, and the cyber threat landscape.
The distinction between internal and external context matters because it determines the control options available to the BCMS. Internal factors are often within the organisation’s control (e.g., cross-training, technology architecture choices, supplier selection). External factors are often not (e.g., regulatory requirements, natural disaster exposure, geopolitical events). An effective BCMS addresses internal factors through design choices and external factors through adaptation and resilience strategies.
| Context Category | Examples for Indonesian Organisations | BCMS Implication |
|---|---|---|
| Organisational structure | Multi-site operation in Jakarta and regional offices; matrix reporting lines; outsourced IT support; shared service centres | BCMS must define which units are in scope; decision-making authority for continuity decisions must be clear across structure |
| Technology dependencies | Core banking systems hosted on local or regional cloud; legacy ERP with limited alternative providers; integrations with payment networks; mobile app infrastructure | BCMS must ensure technology recovery capability matches RTO; supplier agreements must include BCM commitments; technology alternatives must be identified |
| Key personnel | Subject matter experts with no cross-training; single points of knowledge in critical processes; key decision-makers; dependence on regulatory relationships | BCP must address personnel unavailability through cross-training or documented procedures; succession planning is a continuity requirement; remote working capability must be tested |
| Financial constraints | Limited capital budget for alternate recovery facilities; constraints on insurance premiums; budget cycles that do not align with continuity needs | BCMS must identify recovery strategies achievable within financial reality; business case for continuity investment must be made to leadership |
| Existing BCM maturity | Some departments may have business continuity plans; others may have none; IT disaster recovery may exist but is not integrated with business continuity | BCMS scope must address maturity gaps; integration of existing plans into the BCMS is a scoping decision; capability building plan must be sequenced |
| Indonesian regulatory requirements | OJK POJK 11/2022 BCM obligations; BI regulations for payment system resilience; BSSN cybersecurity requirements; UU PDP data protection and breach reporting | Every regulatory obligation must be mapped to BCMS scope and documented; regulatory requirements inform RTO, RPO, and recovery strategy; regulatory examination findings drive BCMS improvements |
| Natural disaster exposure | Earthquake and tsunami risk in Sumatra and Java; flooding in Jakarta and Kalimantan during rainy season; volcanic activity in central Java | Geographic diversification of critical resources must be evaluated; alternate site location must account for natural disaster geography; business continuity must address multi-site failures; insurance and recovery capacity must account for region-wide events |
| Cyber threat landscape | Ransomware targeting Indonesian financial institutions; supply chain compromise through shared vendors; DDoS attacks on banking infrastructure; credential theft and business email compromise | Cybersecurity measures must be integrated into BCMS; incident response and BCM activation must be coordinated; backup and recovery procedures must account for compromise scenarios; cyber insurance scope must align with BCM strategy |
| Supply chain geography | Critical suppliers located in a single location; logistics dependencies on transport corridors subject to disruption; international suppliers subject to border delays; dependencies on shared infrastructure providers | BIA must identify supplier dependencies and recovery impact; supplier BCM requirements must be established; alternative suppliers or just-in-time inventory trade-offs must be analysed; supply chain mapping must be current |
| Client contractual requirements | Service level agreements that specify uptime guarantees; regulatory obligations contracted to clients; contractual liability for service failure; client audit rights over BCM capability | SLA requirements must be translated into RTO/RPO targets; contractual BCMS obligations must inform scope; capability demonstration (exercises, certifications) must be delivered to clients; non-compliance risk must be assessed |
| KEY IDEA | Context analysis is not a one-time documentation exercise. The internal and external context changes — new regulations emerge, new technology dependencies are introduced, new suppliers are added, organisational restructuring occurs, natural disasters happen, the threat landscape evolves. ISO 22301 requires the organisation to determine its context and keep it current. The management review cycle is the mechanism for ensuring context understanding remains valid. An outdated context document produces a BCMS scope that does not reflect the organisation as it actually operates and will fail under a real disruption. |
Understanding Interested Parties and Their Requirements (4.2)
An interested party, in ISO 22301 terms, is any entity whose needs and expectations can affect the organisation’s ability to achieve the BCMS objectives. This is broader than stakeholders — it includes regulators, clients, employees, supply chain partners, insurance providers, and in some cases the general public or community. Each interested party has BCM-related requirements that must be identified, documented, and addressed in the BCMS.
Regulators (OJK, Bank Indonesia, BSSN) have explicit BCM requirements — recovery time objectives, testing frequency, disaster simulation exercises, incident reporting timelines. Clients have requirements embedded in service level agreements and contractual terms. Insurers have requirements related to how the organisation manages risk and demonstrates recovery capability. Employees have safety and continuity expectations. Supply chain partners have BCM dependencies — they need the organisation to remain operational because they depend on its services.
The process of identifying interested parties and their requirements is systematic. Identify each interested party, determine their connection to the organisation, understand their specific BCM requirements or expectations, and evaluate whether those requirements affect the BCMS scope. For example, if a critical supplier requires the organisation to maintain 2-hour recovery capability, that requirement becomes a BCMS objective. If a financial regulator requires simulation exercises twice annually, that becomes a BCMS operational requirement.
Determining the Scope of the BCMS (4.3)
The scope of the BCMS defines what goes in and what stays out. In principle, the scope should cover all activities whose disruption could cause unacceptable impact to the organisation — the critical activities. In practice, scope is often limited by resources, maturity, and practical constraints. The correct approach is to scope the BCMS around genuinely critical activities in the initial phase and expand scope incrementally as the programme matures.
Common scoping errors include scope that is too narrow — failing to include activities that should be critical but are not included because they are managed by a supplier or a different department — and scope that is too broad — including every process, every system, and every site because the organisation wants to be thorough, resulting in a BCMS programme that takes years to build and struggles to maintain. Scope creep is the enemy of certification timelines. An organisation that includes everything will certify nothing.
The scope statement must clearly define: which organisational units are in scope and which are out (e.g., “All financial services delivery units based in Jakarta and Surabaya; IT and operations support functions; excluded: regional branches in outlying areas”); which processes and services are critical (e.g., “Payment processing, client data access, core trading systems”); which sites and locations are covered; which ICT systems and infrastructure are critical; which suppliers’ continuity affects the in-scope activities; and which regulatory or contractual obligations drive the scope.
| Scope Decision | Correct Approach | Common Error |
|---|---|---|
| Organisational units | Identify units whose disruption would cause unacceptable impact; include units responsible for critical activities; be explicit about which units are excluded and why (e.g., advisory divisions, back-office consolidation in progress) | Including all units regardless of criticality; excluding units whose activities are actually critical; inconsistency between stated scope and actual BCP coverage |
| Processes and services | List specific processes that are critical to the organisation’s objectives: “payment processing”, “client onboarding”, “risk management reporting” — not blanket inclusions like “all processes” | Defining scope in functional terms (“finance”, “IT”) rather than process terms; failing to prioritise between processes; including processes that are important but not critical |
| Sites and locations | Identify which physical locations are critical (head office, main data centre, disaster recovery site); justify exclusions (satellite offices, small branches); note geographic redundancy or single-point-of-failure risks | Assuming all offices are equally critical; excluding office locations that turn out to be critical; failing to account for natural disaster geography (e.g., excluding Sumatra office while building alternate site in Bandung) |
| IT systems | List specific systems critical to continuity (core banking, payment processing, client database, email); prioritise by RTO; identify system interdependencies; note where cloud or third-party infrastructure creates dependencies | Listing all systems; treating all systems as equally critical; failing to document system dependencies; missing cloud or SaaS dependencies |
| Suppliers | Identify critical suppliers whose continuity affects in-scope activities; establish BCM requirements in supplier agreements; assess supplier BCM capability; plan for supplier unavailability | Including all suppliers; failing to distinguish between critical and non-critical suppliers; assuming suppliers will self-manage their continuity without contractual requirements |
| Regulatory obligations | Map relevant regulations to BCMS scope: OJK POJK 11/2022, BI regulations, BSSN requirements, data protection obligations — each regulation informs scope and objectives | Treating compliance as separate from BCM; missing regulatory obligations; failing to translate regulatory requirements into BCMS scope |
| IMPORTANT | Scope creep is the enemy of certification timelines. Organisations that include every process, every system, and every site in the initial BCMS scope build a programme that takes years to certify and struggles to maintain currency. The correct approach is to scope the BCMS around critical activities — those whose disruption would cause unacceptable impact — and expand scope incrementally as the programme matures. A certified BCMS covering 80% of critical activities is far more valuable than an in-development BCMS intended to cover 100% of activities but never completed. |
The BCMS and Its Processes (4.4)
Once the context is defined, scope is determined, and interested parties are identified, the organisation must establish the BCMS itself as a managed system. This means determining the processes that make up the BCMS, how they interact with each other, how they integrate into the organisation’s broader operational and governance processes, and where decision-making authority lies. The BCMS is not a separate system running in parallel to the business; it is embedded in how the organisation operates.
The BCMS includes processes for context analysis and review, risk assessment and business impact analysis, strategy development, plan creation and maintenance, training and awareness, exercise and testing, monitoring and performance evaluation, management review, and continuous improvement. These processes interact: the results of the business impact analysis inform the continuity strategy; the strategy informs the plans; the plans are tested through exercises; exercise findings drive improvements to the strategy and plans. The BCMS management review is the governance process that ensures all of these are working together and are kept current.
| BITLION INSIGHT | Indonesian organisations frequently underestimate the importance of regulatory context mapping at Clause 4.1. The external context for an Indonesian financial institution includes at minimum OJK POJK 11/2022 on business continuity management, Bank Indonesia regulations on payment system resilience, BSSN obligations for critical infrastructure and cybersecurity, and applicable UU PDP requirements for data protection. Each of these has specific BCM obligations that become BCMS requirements. Mapping them explicitly at Clause 4.1 ensures they are captured in the scope and addressed in the operational business continuity plans — not discovered during a regulatory examination or, worse, after a disruption event. |