A BCMS is not a static collection of documents. It is an operating rhythm — a recurring cycle that keeps BIAs, BCPs, exercises and reviews in motion together. The "BCM lifecycle" is the shorthand for that rhythm. Understanding the lifecycle is the difference between a programme that gets shaped once and decays, and one that improves continuously.
This article walks through the six phases of a working BCM lifecycle. The parent topic is our ISO 22301 implementation pillar.
The six phases
The BCM lifecycle is the BCM-specific instantiation of the broader Plan-Do-Check-Act (PDCA) cycle that ISO management systems share. We use six phases because they map cleanly to the operational artefacts a BCMS produces.
1. Policy and governance. The strategic anchor — BCM policy, BCMS scope, governance structure (BCM committee), roles and authorities. Reviewed annually; refreshed when scope changes materially.
2. Analysis. The BIA (business impact analysis) and risk assessment. What services matter, what dependencies they have, what disruptions they face. Runs as an annual cycle with change-triggered refreshes between.
3. Strategy. The decision phase. For each critical service, decide the continuity strategy — recover, mitigate, transfer, or accept. Approved at BCM committee level for Tier-1 services.
4. Implementation. The plans. BCPs authored to §8.4.4 quality, recovery procedures designed, recovery infrastructure provisioned. Versioned and approved.
5. Validation. The exercise programme. Annual calendar covering every critical plan, mixed exercise types, AARs with improvement actions. The lifecycle's reality check.
6. Improvement. The closure phase. Management review (§9.3), improvement-action register, audit findings tracked to closure. The lifecycle's continuity from one cycle to the next.
Each phase produces inputs to the next, and the cycle as a whole produces inputs to the next iteration. Phase 6 feeds back into phase 1 (does the policy still hold?), phase 2 (does the BIA need refresh?) and so on.
Phase 1: Policy and governance
The foundational phase. Outputs:
- BCM policy. Top-management-approved statement of commitment, scope, principles. One to two pages. Reviewed annually.
- BCMS scope statement. Explicit boundaries — what services, locations, subsidiaries, business lines are in scope. Out-of-scope items called out.
- Governance structure. BCM committee charter — composition, mandate, cadence, decision authority. See our SAMA BCM committee charter article for the working template.
- Roles and authorities. Documented BCM-related roles across the organisation — process owners, incident commanders, BCM lead, secretariat.
Time to first cycle: 30-60 days for a greenfield programme. Cycle cadence: annual review.
Phase 2: Analysis
The BIA and risk-assessment phase. Outputs:
- Impact matrix. Programme-level definitions of Low/Medium/High/Critical across the impact dimensions.
- BIA records per in-scope service. Impact ratings, dependencies, recovery objectives.
- Risk assessment. Disruption scenarios and their likelihood/impact, feeding the strategy decision.
The most calendar-intensive phase. For a mid-market organisation with 20-50 critical services, a first BIA cycle takes 2-4 months. Subsequent refreshes are faster (the methodology is in place; just the data is refreshed).
See the BIA pillar guide and the BIA template article for the working method.
Phase 3: Strategy
The decision phase. For each critical service, the BCM committee decides the strategic response to identified disruptions. Outputs:
- Strategy decision per critical service — recover, mitigate, transfer, accept — with rationale linked to BIA outcomes and risk assessment.
- Resource commitments to enable the chosen strategy (infrastructure, vendor contracts, training, headcount).
Often the most under-invested phase. Strategy decisions are made implicitly during BCP authoring rather than explicitly at committee level. The cost surfaces later — exercises reveal that "recovery" is the strategy in name but not in infrastructure.
Phase 4: Implementation
The execution phase. Outputs:
- BCPs authored to ISO 22301 §8.4.4 quality. See the §8.4.4 article for the field-level requirements.
- Recovery procedures — phased per §8.4.5, executable under stress.
- Recovery infrastructure — IT-DR runbooks, fallback facilities, vendor backup arrangements, manual workarounds. The BCM-vs-DR article covers the IT-DR integration.
- Activation criteria — quantitative and categorical triggers per plan. See the activation criteria article.
Time to first cycle: 3-6 months. Cycle cadence: each plan re-versioned annually; new plans added as scope extends.
Phase 5: Validation
The exercise phase. Outputs:
- Exercise programme document — annual calendar by plan, exercise type, objectives, success criteria.
- Exercise records — what was tested, by whom, with what outcome.
- AARs — see the AAR template article for the working format.
- §8.5 activation log — every exercise and real-world activation captured.
This is the phase that exposes the gaps the analysis and implementation phases missed. A programme that runs phase 5 rigorously will iterate faster than one that treats exercises as compliance theatre.
Phase 6: Improvement
The closure phase that feeds the next cycle. Outputs:
- Management review minutes — see the §9.3 management review article.
- Improvement-action register — every action with owner, due date, status.
- Audit findings (internal and external) tracked to closure.
- Inputs to phase 1-5 for the next cycle — what scope changes are needed, what methodology refinements, what re-prioritisation.
The bridge between iterations. Without an explicit phase-6 close-out, the lifecycle becomes a series of disconnected annual snapshots rather than a continuous improvement loop.
How the phases interact
The phases are not strictly sequential — they overlap in any working programme. The annual rhythm typically looks like:
- Q1: Policy and governance review (phase 1). BCM committee approves the year's posture. Annual BIA refresh begins (phase 2).
- Q2: BIA refresh continues; strategy decisions for any changed services (phase 3). BCP updates begin (phase 4).
- Q3: Exercise programme runs (phase 5). AARs captured. Improvement actions raised.
- Q4: Management review (phase 6). Improvement actions tracked. Next-year planning. Internal audit.
The rhythm is approximate; some phases run continuously (improvement-action tracking, §8.5 logging) rather than in discrete quarters.
Common lifecycle failure modes
One-and-done. The programme completes phases 1-4 in the first year, declares victory, and never returns to phase 2 (BIA refresh) or phase 5 (exercises). Eighteen months later, the BIAs are stale and the plans are untested.
Phase 5 skipped. Exercises are deferred quarter after quarter due to bandwidth pressure. The programme has plans but no validation. First real incident reveals the gaps.
Phase 6 hollow. Management review happens; improvement actions are captured; nobody closes them. The register grows; the actual programme doesn't change.
Disconnected phases. Each phase happens, but the outputs of one don't feed the next. The BIA is updated; the BCPs don't know. Exercises run; AARs are filed; the BCM committee never sees them.
The fix in every case is structural — a connected artefact set where changes in one phase flag the affected items in adjacent phases. This is exactly what a structured platform models. The BCMStack platform ties BIA, BCP, exercise and AAR records into one connected dataset.
In ISO 22301 and SAMA contexts
The lifecycle as described maps onto ISO 22301 clauses 4-10 directly: phase 1 to clauses 4-5, phase 2 to clauses 6 + 8.3, phase 3-4 to clause 8.4, phase 5 to clause 8.5, phase 6 to clauses 9-10. SAMA's expectations follow the same shape with KSA-specific additions covered in the SAMA BCM Framework pillar.
Where to start
If your BCM lifecycle is unclear or partial:
- Audit your current state against the six phases. Which are documented? Which produce outputs that feed the next phase?
- Identify the weakest phase. Most often it is phase 5 (exercises) or phase 6 (improvement).
- Run the next quarter's activities against the full lifecycle, even if imperfectly. Don't wait for a redesign to fix it.
- Capture the connections — every artefact should reference the upstream artefact that drove it and the downstream artefact it feeds.
The lifecycle is the programme. The artefacts are the by-products.