A Business Continuity Plan is an operational document, not a strategic document. Its purpose is to provide clear, actionable guidance to the people who must activate it during a disruption event — when they are stressed, under time pressure, and unable to ask clarifying questions. A BCP that is written for the author (""restore systems"") will fail when activated by someone who does not know the author’s assumptions. A BCP that is written for the user (""call the DR coordinator at +62-21-XXXX, provide the incident reference, request failover to the Bandung site"") can be executed by anyone on the activation team.
Most BCPs fail not because the strategy is wrong but because the procedures are written at the wrong level of detail, the contact lists are out of date, the assumptions about resource availability are unrealistic, or the procedures have not been tested. The difference between an effective BCP and an unusable BCP is often the difference between someone who took time to write procedures that work versus someone who wrote something that satisfied a compliance requirement. BCPs that have been validated with process owners, exercised regularly, and refined based on exercise findings are generally usable; BCPs that are written once and never refreshed are generally not.
This article covers the mandatory elements of a compliant BCP, the common errors that make BCPs unusable, and the governance and validation processes that ensure BCPs remain current and effective.
What a Compliant BCP Must Contain
ISO 22301 Clause 8.4 specifies that BCPs must address: (a) identification and selection of the activities to be recovered and their resources; (b) purpose of the plan; (c) scope; (d) mobilisation, notification, and activation procedures; (e) roles, responsibilities, and succession arrangements; (f) recovery procedures for each critical activity; (g) communication procedures; (h) reference material and appendices (contact lists, facility details, system configurations, etc.); (i) document control information (version, date, approver, review date); (j) action lists and checklists for rapid activation.
These requirements define the structure and content of a compliant BCP. However, compliance is not the same as usability. A BCP can contain all required elements and still be unusable if the procedures are vague, the contact information is out of date, or the assumptions are unrealistic. The quality standard for a BCP is whether it can be activated by someone who has never seen it before, without needing to ask clarifying questions.
| BCP Section | Purpose | Common Errors |
|---|---|---|
| Document control (version, owner, review date) | Ensures the plan is current and authorised | Missing version number; no review date; no approval signature — means the plan may be outdated without anyone knowing |
| Scope and applicability | Defines which activities, sites, and systems are covered | Too broad (covers everything) or too narrow (misses dependencies); not linked to BIA scope |
| Activation criteria and triggers | Specifies what must happen before the BCP is activated — prevents premature or delayed activation | Vague triggers (“when a significant disruption occurs”); no clear decision authority; activation threshold not linked to MAO |
| Activation authority and roles | Who can declare a continuity event; who does what during activation | Multiple people with authority but no tiebreaker; roles assigned to job titles not named individuals plus backups |
| Recovery procedures — step by step | The operational instructions for recovering each critical activity | Procedures written at policy level (”restore systems”) not operational level (“call the DR hotline at +62-21-XXXX, provide incident reference, request failover to DR site”) |
| Resource requirements at RTO | Minimum people, premises, technology, and suppliers needed at RTO | Resource list not updated after BIA; lists full-capacity requirements instead of RTO-minimum requirements |
| Communication scripts and contacts | Who to call, what to say, in what order | Contact list not updated (wrong numbers); no scripts for external communication; no escalation path |
| Stand-down criteria | How and when to declare the continuity event over and return to normal | Missing entirely — plans that have no end condition create confusion about when BCP is still active |
Writing Procedures That Work Under Pressure
The most common error in BCP procedures is writing at the wrong level of abstraction. A procedure that says ""restore IT systems"" is not a procedure — it is a goal. A procedure must tell the person activating it exactly what to do: who to call, what number to dial, what to say, what to do if that person does not answer, what the backup plan is. The test of a good procedure is whether someone who has never seen it before and who is not an expert in the domain can follow it correctly under stress.
Effective procedures use action-oriented language with numbered steps. Instead of ""Business Continuity Manager will coordinate with IT to restore systems"", a procedure says: ""1. BC Manager calls Senior IT Manager at +62-21-XXXX (mobile: +62-812-XXXXXX). 2. BC Manager says: ‘We are activating the BC plan. Please initiate failover to the Bandung data centre.’ 3. Senior IT Manager confirms failover status and provides ETA for system availability. 4. BC Manager logs response time and ETA in the incident log (Appendix C)."" The second version tells the person activating the procedure what to do at each step; the first version does not.
Procedures should include decision trees for branching scenarios. For example: ""If Senior IT Manager does not answer within 2 minutes, call Deputy IT Manager at [number]. If both are unavailable, contact IT Duty Officer through the paging system [number]. Do not wait more than 5 minutes for an answer; move to contingency step 2."" Decision trees prevent activation teams from getting stuck waiting for a person who is unavailable; they keep the procedure flowing forward.
Activation and Escalation Procedures
Activation procedures must define: what constitutes a disruption event that requires BCP activation (activation triggers), who has the authority to declare a continuity event and activate the BCP (activation authority), what the escalation chain is if the primary decision-maker is unavailable, and what the first actions are once BCP activation is declared. Clear activation authority prevents either under-activation (a disruption event occurs but no one activates the BCP because the authority is ambiguous) or over-activation (the BCP is activated for minor disruptions that do not require full activation).
Activation triggers should be specific. ""Activate the BCP if a system is unavailable for more than 4 hours"" is specific; ""activate when a significant disruption occurs"" is not. Activation triggers should be linked to RTO: if the RTO is 4 hours, the trigger should be something like ""if the activity has been unavailable for 2 hours and recovery is not expected within the next 2 hours, activate the BCP to shift to the alternate procedure"". This ensures that the BCP is activated with sufficient time remaining to meet the RTO.
Communication Sections of the BCP
Communication procedures are often the weakest section of a BCP, yet they are often the most critical to the success of the continuity event. Communication must address: internal notification cascade (who in the organisation needs to know immediately), operational staff communication (deployment of activation team members), client communication (notification that services are affected and timeline for recovery), regulator communication (notification of OJK/BI/BSSN as required), and media/public communication (if the disruption is visible externally).
Pre-written communication scripts reduce the time and error rate of notification. Instead of each person drafting their own message during a stressful event, the BCP includes templates: ""Internal Leadership Notification: ‘A [describe incident] occurred at [time]. The following services are affected: [list]. We are activating continuity procedures. Expected recovery is [time]. Next update at [time]. Incident reference: [reference number].’"" Templates ensure consistency and prevent misinformation.
| Communication Audience | Timing | Key Messages and Script Elements |
|---|---|---|
| Executive leadership / incident command | Immediate — within 30 minutes of activation | Incident description; critical activities affected; BCP activated; initial RTO estimate; resource needs; next update time |
| Operational staff (BCP activation team) | Immediate — within 1 hour | Their specific role; reporting location or remote working instructions; contact cascade; system status; first actions required |
| Clients (priority-graded) | Within 2–4 hours — after situation is stabilised | Acknowledgment of disruption; impact on their service; expected resolution timeline; interim arrangements; single point of contact |
| Regulators (OJK/BI/BSSN as applicable) | Per regulatory obligation — often within 24 hours | Nature of incident; scope of impact; BCP activation status; recovery timeline; regulatory SLA impact; contact for follow-up |
| Suppliers and partners | Within 4–8 hours | Impact on their service commitments; any requests for emergency support; contact for coordination |
| Media / public | Only if disruption is visible externally — after executive approval | Prepared statement only; no speculation; refer to single spokesperson; focus on customer impact and resolution |
BCP Validation with Process Owners
BCPs must be validated with the process owners who will activate them. Validation workshops (typically 90 minutes per BCP) bring together the BCP author, the process owner, and the crisis management lead responsible for the activity. The team walks through the BCP step by step: Does this procedure reflect how you actually operate? Are the contact numbers current? Is the resource list realistic for RTO conditions? What is missing or incorrect? Validation workshops identify errors (wrong phone numbers, procedures that describe outdated systems, resource lists that include staff who have left) before the plan is published.
BCPs should be treated as living documents that are updated whenever the organisation changes. BCP review triggers include: organisational change (significant restructuring, acquisition, divestiture), technology change (system replacement, retirement, major upgrade), supplier change (loss or addition of a critical supplier), staff change (departure of someone with critical knowledge, if not replaced), and exercise findings (identifying gaps or inaccuracies). A BCP that was validated 24 months ago and has not been reviewed since is likely to have become stale; the contact list is probably out of date (staff have changed roles or left), the procedures may reference systems that have been replaced, and resource assumptions may no longer be realistic.
| IMPORTANT | The contact directory is the most time-critical element of a BCP. When a continuity event is declared at 2am on a Saturday, the person activating the plan needs accurate phone numbers for every key role — names, mobile numbers, backup contacts, and escalation paths. Contact directories that are maintained by the BCM team in isolation from HR systems become stale within months as staff change roles, leave, and join. The BCP contact directory must be connected to a live data source — HR system, Outlook directory, or a maintained contact management process — and verified at every BCP review cycle. |
| BITLION INSIGHT | The single most common reason Indonesian BCPs fail in exercises is that they are written in the past tense of the organisation’s operations — they describe how things worked when the plan was written, not how they work now. A BCP written 18 months ago that has not been reviewed may reference systems that have been replaced, suppliers that have changed, staff who have left, and premises arrangements that have lapsed. BCP review triggers — organisational change, technology change, supplier change, staff change, exercise findings — must be embedded in the change management process so that BCPs are updated as the organisation changes, not just on an annual review cycle. |