A business continuity plan should be reviewed before its scheduled date whenever a material change affects the people, assumptions, dependencies, procedures, locations, obligations, or recovery capabilities the plan relies on.
That does not mean rewriting the entire plan after every organizational change. A change-driven review is a focused, off-cycle check that determines what became inaccurate, which records are affected, who must validate the update, and whether the change also requires a BIA, recovery-strategy review, or exercise.
In short
A change is material when leaving the plan untouched could cause someone to make the wrong decision, contact the wrong person, follow an invalid procedure, depend on an unavailable resource, or miss an obligation during a disruption.
A title change with no effect on responsibilities may require only a contact update. Replacing the person who can authorize a shutdown affects decision rights and requires targeted review. Moving a process to a new application may affect dependencies, workarounds, recovery targets, and testing, which can require broader reassessment.
NIST SP 800-34 Rev. 1 provides a useful, properly limited example. Its scope is US federal information-system contingency planning, not every business continuity program. It says plans should be reviewed when significant changes affect the plan, supported processes, systems, or recovery resources. It also identifies frequently changing content such as contacts, vendors, equipment, facilities, vital records, contracts, licenses, interconnections, recovery strategies, and related plans.
The broader lifecycle principle is consistent with ISO 22301:2019, including Amendment 1:2024, which describes a documented management system that is monitored, reviewed, maintained, and continually improved. Neither source prescribes the exact trigger matrix below.
Use the change as a signal, then examine the plan content and related records most likely to be affected.
| Trigger category | Examples | Examine first |
|---|---|---|
| People and decision rights | Owner departure, role change, missing backup, changed approval authority | Contacts, call trees, escalation paths, role descriptions, approval authority, crisis-team roster |
| Process or service change | New service, retired activity, merger, volume shift, new critical period, changed workaround | Recovery procedures, staffing, dependencies, service commitments, BIA assumptions |
| Technology or data change | Application migration, identity change, network redesign, backup change, new integration | System dependencies, access steps, manual methods, RTO and RPO assumptions, restoration sequence |
| Supplier or contract change | Vendor replacement, SLA change, new logistics model, supplier exit | Vendor contacts, service dependencies, alternate suppliers, contractual obligations, workarounds |
| Facility or work-location change | Office move, site closure, remote-work change, alternate-site change, access restriction | Relocation procedures, site contacts, workspace needs, facility dependencies, access instructions |
| Legal, regulatory, or customer obligation | New rule, contract term, notification duty, reporting deadline | Escalation, communications, recovery targets, evidence retention, approval and reporting steps |
| Incident or near miss | Plan unavailable, role confusion, failed workaround, delayed notification | The sections used during the event, activation criteria, decision paths, access, communications |
| Exercise, audit, or assessment finding | Failed recovery step, missing evidence, unresolved action, incorrect assumption | Tested procedures, corrective actions, affected plan sections, approval status, retest requirement |
This is a starting point, not an exhaustive control set. Industry obligations, internal policy, and the design of the plan may create additional triggers.
Not every trigger belongs in the same review path. Use four possible outcomes:
Five questions help determine the scope:
One “yes” does not automatically require a full rewrite. It does require an accountable decision about what to reopen.
A trigger list has little value if changes still disappear into email. Use a short workflow:
For changes to crisis-team roles and decision authority, the related MHA article on setting up a crisis management team provides the deeper strategic guidance. The BCMMetrics workflow should remain focused on documenting and maintaining the approved structure.
Software does not decide whether an organizational change is material. The program still needs defined triggers, decision rights, and people who understand how the organization operates.
Once the review is opened, BCM Planner can support the execution. It allows teams to build or upload plans, create and edit recovery plans, manage them in one place, use draft, review, complete, and approved statuses, store and share current plans, and record exercise results.
When evaluating the workflow, ask:
BCM Planner supports the controlled work after the trigger is identified. It does not determine materiality, change the BIA automatically, or decide who has approval authority.
Scheduled reviews still matter. They catch gradual drift and confirm that plans remain complete. Change-driven reviews solve a different problem: known inaccuracy between scheduled dates.
The practical rule is simple. If a change could alter decisions, responsibilities, dependencies, recovery actions, obligations, or the ability to execute the plan, assess it now. Reopen only what the evidence requires, but leave a clear record of what was considered and what became current.
For recurring cadence, attestations, and change control, use Plan Maintenance Without Burnout. For governance rhythm and evidence checks, use the BCM Governance Cadence guide.