Three Overlapping Disciplines
Business continuity, crisis management, and incident response are distinct disciplines that operate on the same spectrum of disruption. Incident response handles operational incidents within normal authority structures. Crisis management coordinates senior leadership response to significant events. Business continuity addresses threats to critical business activity. Organizations that treat these as separate programs create dangerous gaps: incidents escalate unchecked to crises; crises escalate unchecked to business continuity events; communication authority blurs; decision-making authority becomes unclear. Integration means defining clear escalation criteria and ensuring that hand-offs between disciplines are explicit.
The Escalation Model
Define escalation explicitly so that decision-makers know when to shift from incident management to crisis management to business continuity activation:
| Level | Description | Response | Activation Trigger | Owner |
|---|---|---|---|---|
| Level 1: Operational Incident | Minor disruption, managed within normal operations | Incident response | Standard operational threshold | Operations Manager |
| Level 2: Crisis | Significant event requiring senior management coordination | Crisis management | Predefined crisis criteria | Crisis Management Team |
| Level 3: Business Continuity Event | Disruption threatens critical business activities | BCP activation | BIA-derived MAO/RTO thresholds | BCMS Manager / Sponsor |
ISO 22301 and ISO 27001 Integration Points
ISO 27001 (Information Security Management) includes specific requirements for incident management planning, assessment, response, and learning. When an information security incident occurs (ISO 27001 Clause 5.24–5.28), the response procedures may trigger business continuity activation. Ransomware is the most common intersection: a security incident (malware infection) that causes business disruption (systems unavailable) that threatens critical activity (sales system down, payroll processing delayed). Organizations must explicitly link their ISO 27001 incident response procedures to their ISO 22301 BCP activation criteria. A security incident that causes business disruption should not navigate two separate governance paths; it should escalate through a unified process.
The Crisis Management Team Structure
When a business continuity event is declared, establish clear authority. The Crisis Management Team (or Incident Management Team) has authority to make real-time decisions about resource allocation, external communications, and operational trade-offs. The BCP Activation Team has authority to execute recovery procedures for specific critical activities. Define command and control explicitly: Who declares the event? Who has authority to stand down the BCP? Who communicates externally? Who makes decisions about regulatory notification? Confusion about authority during a real disruption leads to delayed or contradictory decisions.
BCP Activation Criteria
Document the specific conditions that trigger BCP activation. Criteria should be unambiguous: "Critical systems are unavailable to all users" (activates ICT continuity plan); "Premises are inaccessible due to physical damage" (activates alternate site plan); "Key supplier has notified us of extended disruption" (activates supplier contingency plan). Do not wait for perfect information before activating. Activation criteria should be based on the earliest available indicator that you will exceed your MAO (Maximum Allowable Outage). Pre-authorize activation at defined thresholds so that the BCMS Manager can activate the BCP without waiting for additional approvals.
Deactivation and Stand-Down
The deactivation process is as important as activation. Define stand-down criteria: When is it safe to stop executing BCP procedures and return to normal operations? Deactivation should be explicit and documented—not a gradual drift back to normal where some teams are still executing recovery while others assume normal operations. The stand-down decision should be made by the same authority that declared activation. After deactivation, conduct a post-incident review to document what happened, what the organization learned, and what needs to be improved in the BCP.
Lessons Learned Integration
Every incident, near-miss, and exercise generates lessons that should improve the BCMS:
| Source | Key Lessons | BCMS Update | Timeline |
|---|---|---|---|
| Real incident / BCP activation | Actual operational gaps revealed | BCP revision, BIA review | 30 days |
| Near-miss event | Identified vulnerabilities before activation | Risk register update, preventive action | 60 days |
| Exercise debrief findings | Simulated gaps and process weaknesses | BCP update, corrective action | 90 days |
| External incident (industry peers) | Learning from others' continuity events | Risk scenario review | 90 days |
| KEY IDEA | The escalation from incident to crisis to business continuity event must be pre-defined and practiced. When a real disruption occurs, the question "should we activate the BCP?" should already have been answered by documented criteria, not decided in the moment under pressure. |
| IMPORTANT | Ransomware is now the most common trigger for ISO 22301 BCP activation in Indonesian organizations. The integration between your ISO 27001 incident response process and your ISO 22301 BCP activation criteria is not optional—it is operationally critical. |
| BITLION INSIGHT | Post-incident reviews are where the BCMS proves its value—or where it is found wanting. Organizations that conduct rigorous post-incident reviews and translate findings into BCMS improvements build genuine resilience capability over time, not just certification compliance. |