The BCI Horizon Scan 2025 found that 73% of organisations experienced at least one disruption in the past year, yet fewer than half had reviewed their business continuity plans within the same period. The gap between those two numbers is where failures happen: not because the plan was badly written, but because it was written for an organisation that no longer exists.
If you manage a BCM programme, you already know the feeling. You finish a round of plan updates, get sign-off, close the project. Three months later someone mentions that two departments merged, a critical vendor was replaced, and the head of operations left. Your plans still reference the old structure, the old vendor, the old person. They are technically approved and practically fiction.
This is not a discipline problem. It is a design problem. Most BCM programmes are built around periodic reviews: annual cycles, quarterly check-ins, triggered updates that depend on someone remembering to trigger them. The result is plans that are current for a few weeks after each review and increasingly outdated for the rest of the year.
This article explains why business continuity plans decay so quickly, what the real triggers are, and what a maintenance approach looks like when it does not depend on calendar reminders.
What is business continuity plan maintenance?
Business continuity plan maintenance is the ongoing process of keeping your BCM documentation, data, and procedures aligned with the current state of your organisation. It is distinct from the initial plan creation and from periodic testing. A business continuity plan captures how you will respond to disruptions. Maintenance ensures that the plan still reflects reality when a disruption actually arrives.
The lifecycle looks like this: you conduct a business impact analysis, identify critical processes, document recovery strategies, assign roles, and get approval. That is the creation phase. Maintenance is everything that happens after approval to keep those outputs accurate. It includes detecting changes in the organisation, updating the affected plans, re-validating recovery strategies, and confirming that the people named in the plans still hold those roles.
Most organisations treat maintenance as a periodic event: an annual review cycle, sometimes quarterly for high-risk functions. The problem is that organisations do not change on an annual cycle. They change continuously. ISO 22301 recognises this by requiring continual improvement and triggered reviews, not just scheduled audits.
Why keeping plans current is harder than most think
Plan maintenance sounds straightforward: when something changes, update the plan. In practice, three structural problems make it much harder than it appears.
Org changes happen faster than review cycles
A department merges. A business unit is created. A regional office closes. These are not rare events. In a mid-to-large enterprise, organisational restructures happen multiple times per year. Each one can invalidate recovery team assignments, escalation paths, communication trees, and dependency maps across dozens of plans.
When the BCM manager finds out about these changes, it is usually weeks or months after the fact. Nobody sends a notification to the BCM team when an org chart changes. The information surfaces during the next review cycle, during a test that fails, or during an actual incident when the plan references a team that no longer exists. As one BCM lead at a European energy company described it: "Every time we change a department it's a crazy situation."
The data underneath plans is never static
BCM plans are built on business impact analysis data: which processes are critical, what their dependencies are, who owns them, what the RTOs and RPOs should be. That data is collected through interviews, workshops, and surveys. The moment the interviews are finished, the data starts aging.
A new system replaces an old one. A vendor contract expires. A process that was manual gets automated. Each change means the BIA data no longer reflects reality, and every plan that depends on that data inherits the inaccuracy. The compounding effect is severe: if you have 200 processes in your BIA and 15% of the underlying data changes each quarter, within a year roughly half your recovery procedures reference something that has moved, been renamed, or no longer exists.
Nobody owns the update
In most organisations, the BCM team owns the plans but does not own the changes that make plans stale. IT owns system migrations. HR owns org restructures. Procurement owns vendor changes. The BCM manager is downstream of all of these decisions and typically learns about them last.
Without an automated detection mechanism, plan maintenance depends on relationships: the BCM manager asking the right person the right question at the right time. That works when you have a large team with deep organisational knowledge. It does not work when you are a team of one or two managing 50 or more departments. As one buyer described the challenge: "Would be a full time job probably for a whole team of people to keep up to date."
The five triggers that make BCM plans stale
Not all changes carry the same weight. The table below shows the five most common triggers for plan decay, what they affect, how long they typically go undetected, and the impact when a disruption hits before the plan catches up.
| Trigger | What changes in your plans | Typical detection lag | Impact if missed |
|---|---|---|---|
| Organisational restructure | Recovery teams, escalation paths, communication trees, process ownership | 1-3 months | Incident commander role assigned to someone who left or moved. Escalation path leads nowhere. |
| System or application replacement | IT recovery procedures, RTOs, dependency maps, DR runbooks | 1-6 months | Recovery procedure references a system that no longer exists. DR test fails at step one. |
| Staff turnover in critical roles | Named contacts in plans, BIA interview data, approval chains | Weeks to months | Plan lists a recovery lead who left. Nobody else knows the procedure. |
| Vendor or supplier change | Third-party dependencies, SLAs, contact details, alternative sourcing | 1-3 months | Plan assumes a vendor SLA that expired. Backup supplier no longer under contract. |
| Regulatory or compliance update | Scope of BCMS, RTO/RPO targets, audit evidence requirements, reporting obligations | Months to years | Audit reveals non-compliance. Recovery targets do not meet new regulatory minimums. |
The first three triggers are the most damaging because they are the most frequent and the least visible. Regulatory changes at least come with public announcements and transition periods. An org restructure or a system swap can happen without anyone notifying the BCM team. Understanding these triggers is also critical for gap analysis: the gap between your documented plans and your actual organisational state is where risk accumulates.
What to look for in a plan maintenance approach
If your current approach depends on calendar reminders and manual check-ins, the triggers above will always outrun you. Here are the five capabilities that separate effective plan maintenance from the annual review treadmill.
Change detection that does not depend on someone remembering
The most important capability is also the rarest: the ability to detect when something in the organisation has changed that affects a plan, without requiring a human to notice and report it. This means integrations with HR systems, CMDB, vendor management platforms, or at minimum an automated prompt to process owners when their data has not been confirmed in a set period.
The goal is not to automate the update itself. It is to automate the trigger: surface the change so the BCM manager can assess the impact and decide what to update. Detection without action is useless, but action without detection is impossible.
BIA data that stays current without re-interviewing everyone
The business impact analysis is the foundation of every plan. If BIA data is stale, every plan built on it is stale. But re-running a full BIA annually is brutal: scheduling dozens or hundreds of interviews, chasing non-responders, consolidating responses, validating changes. Most BCM teams do not have the capacity to do this more than once a year, which means BIA data is current for perhaps two months out of twelve.
The alternative is incremental BIA collection: targeted re-interviews for functions where a change has been detected, confirmation requests for functions where nothing has changed, and a mechanism that lets process owners update their own data when they know something has shifted. The full annual cycle becomes a validation step, not the only data collection event.
Dependency mapping that updates when systems change
Recovery procedures depend on understanding which systems, people, vendors, and facilities each process relies on. Static dependency maps, whether in spreadsheets or in a legacy BCM tool, go stale the moment a system is replaced or a vendor contract changes. Dependency mapping that connects to live data sources (CMDB, HR directory, vendor management) can flag when a mapped dependency no longer matches reality.
This is especially important for identifying single points of failure that emerge when dependencies shift. A process that had two backup systems might now have one, and nobody noticed because the dependency map was last updated six months ago.
Testing that reveals stale assumptions
Exercises and simulations are the ultimate test of plan currency. A plan that looks correct on paper will fail in a simulation if the named recovery lead has moved to a different role, if the recovery site no longer has the required infrastructure, or if the communication tree references a team that was reorganised.
The key is running exercises frequently enough to catch staleness before a real incident does. Annual exercises are not enough. Quarterly micro-simulations, targeted at recently changed areas of the organisation, catch decay that a full annual exercise would miss entirely because it tests the same scenarios each year.
Audit trail that proves currency
Regulators and auditors do not just want to see that a plan exists. They want to see when it was last reviewed, what triggered the review, who approved the changes, and what evidence supports the current recovery targets. An audit trail that logs every change, every confirmation, and every review decision transforms plan maintenance from a compliance burden into a continuous record.
This matters especially under frameworks like ISO 22301 and DORA, where demonstrating continual improvement is an explicit requirement. A plan that was reviewed once a year and rubber-stamped does not meet the spirit of these standards.
How Fortiv handles it
Fortiv is built around the principle that BCM plans should be living documents, not static files that decay between review cycles. Here is how the platform addresses each of the maintenance challenges described above.
- AI-led BIA interviews run on demand, not once a year.
- Dependency mapping visualises cross-process dependencies across people, technology, vendors, and facilities.
- Plans update when underlying data changes.
- Micro-simulations and exercises run against live plan data.
- Full audit trail logs every change, every review, every approval.
- Migration from spreadsheets, SharePoint, or legacy platforms takes weeks, not months.
Moving away from spreadsheets and annual reviews
The biggest barrier to better plan maintenance is not budget or technology. It is the fear that moving to a new approach means starting from scratch: re-doing every BIA, re-building every plan, re-training every stakeholder. That fear keeps BCM teams on spreadsheets and annual review cycles long after they have outgrown them.
The reality is different. A typical migration follows this path: import existing BIA data and plan documents in week one. Map processes, dependencies, and recovery teams in week two. Run a targeted BIA refresh for the highest-risk functions in weeks three and four. By the end of the first month, the BCM manager has a working system with current data for critical functions and a clear backlog for the rest.
The annual review cycle does not disappear. It becomes a validation step rather than the only maintenance event. Between annual reviews, changes are detected and addressed continuously. The result is plans that are materially current at any point in the year, not just in the weeks after the annual review.
Related articles
Moving beyond periodic business continuity plans
How to conduct a business impact analysis
AI dependency mapping in business continuity
Exercise and simulation in business continuity
ISO 22301: the international standard for business continuity
