Category: Incident & Remediation

Continuity Plan

Also known as: BCP, Business Continuity Plan, Business Continuity Planning

Simply put

A continuity plan is a documented set of procedures and safeguards that helps an organization keep essential operations running, and recover them, during and after a major disruption such as a cyber attack, flood, or supply chain failure. It is prepared in advance so the organization can respond in a structured way rather than improvising during a crisis. In practice, the term is most often used in its business continuity sense (a Business Continuity Plan, or BCP).

Formal definition

A Continuity Plan is a strategic, organization-wide framework that outlines the actions, processes, and safeguards intended to maintain or restore essential operations in the face of disruptive events. As commonly defined, it documents procedures for sustaining stability and recovering critical functions during incidents such as cyber attacks, natural disasters, or supply chain failures. Some templates, such as those issued by FEMA for non-federal entities, frame Continuity Plans within specified guidance and programmatic structures; the scope, required elements, and terminology can therefore vary by sector and by the issuing authority. This entry addresses continuity planning at the organizational/operational level and does not, based on the evidence provided, define AI-specific or model-specific continuity requirements. Note also that a continuity plan reduces and manages disruption risk rather than eliminating it.

Why it matters

A continuity plan matters because disruptions to essential operations are, in practice, a question of when rather than if. Events such as cyber attacks, floods, and supply chain failures can interrupt critical functions with little warning, and an organization that has prepared documented procedures in advance is positioned to respond in a structured way rather than improvising during a crisis. As commonly framed, a Business Continuity Plan (BCP) provides that advance structure, outlining the actions, processes, and safeguards intended to maintain or restore operations.

The distinction that professionals should keep in mind is that a continuity plan reduces and manages disruption risk rather than eliminating it. Having a documented plan does not guarantee uninterrupted operations; it establishes a framework that improves the likelihood of maintaining stability and recovering critical functions when an incident occurs. The scope and rigor of that framework can vary significantly by sector and by the authority issuing any applicable guidance, so the presence of a plan alone is less meaningful than its quality, its alignment with the organization's actual critical functions, and whether it is tested and maintained.

For organizations subject to specific programmatic requirements, continuity planning may be shaped by external guidance. FEMA, for example, issues a continuity plan template for non-federal entities framed within its continuity guidance, which prescribes certain structures and sample elements. This illustrates a broader point relevant to compliance and risk professionals: required elements, terminology, and expectations differ depending on the issuing authority and the sector, so a continuity plan appropriate for one context should not be assumed adequate for another.

Who it's relevant to

Operational Resilience and Business Continuity Managers

These professionals are the primary owners of continuity planning. They are responsible for identifying essential operations, documenting the procedures and safeguards needed to sustain or recover them, and ensuring the plan reflects the disruptions the organization is most likely to face, such as cyber attacks, natural disasters, or supply chain failures.

Compliance Officers and Auditors

Where continuity planning is shaped by external guidance or programmatic requirements, compliance and audit professionals assess whether a plan aligns with the applicable framework and issuing authority. They should note that required elements and terminology vary by sector, so conformance to one authority's expectations does not imply conformance to another's.

Non-Federal Entities Subject to Federal Continuity Guidance

Organizations that fall within FEMA's continuity guidance for non-federal entities may use its continuity plan template, which provides instructions, guidance, and sample text framed within specified programmatic structures. These entities should confirm which guidance applies to their situation rather than assuming a generic BCP structure meets the requirement.

Risk and Leadership Functions

Executives and risk owners rely on continuity plans as a measure that reduces and manages disruption risk to essential operations. They should treat the plan as a mechanism for improving structured response and recovery, while recognizing that it does not eliminate the risk of disruption.

Inside BCP

Business Impact Analysis

An assessment that identifies which AI systems or model-dependent processes are critical, the potential consequences of their disruption, and the tolerable duration of an outage. This typically frames how continuity measures are prioritized, though the depth of analysis varies by organization and sector.

Recovery Objectives

Targets such as recovery time and recovery point objectives that specify how quickly a model or system should be restored and how much data or state loss is acceptable. As commonly defined, these objectives should be tied to the criticality established in the impact analysis rather than set uniformly.

Roles and Responsibilities

Documentation of who is accountable for invoking, executing, and overseeing continuity actions. In many governance frameworks this maps to lines of defense, with business or model owners in the first line and independent oversight functions in the second, without collapsing those distinct roles.

Fallback and Contingency Procedures

Predefined alternatives to a primary AI system, which may include manual processes, a simpler backup model, or a degraded operating mode. These are measures intended to reduce the impact of disruption; they do not eliminate the underlying risk.

Dependency and Third-Party Mapping

An inventory of upstream and downstream dependencies, including data sources, infrastructure, and vendor-provided models or services, so that a disruption in a dependency can be anticipated and addressed. The scope of what is captured often varies with organizational maturity.

Communication and Escalation Protocols

Procedures for internal notification, escalation to accountable owners, and, where applicable, communication to regulators or affected parties. Regulatory notification expectations differ by jurisdiction and sector, so specifics should be confirmed against applicable obligations.

Testing and Maintenance Provisions

Arrangements for periodically exercising the plan and updating it as systems, dependencies, and risks change. A continuity plan is typically treated as a living document rather than a one-time deliverable.

Common questions

Answers to the questions practitioners most commonly ask about BCP.

Is a continuity plan the same as a model risk management control?

Not quite. A continuity plan is an organizational and operational measure focused on maintaining or restoring essential functions when a model or its supporting infrastructure becomes unavailable or unreliable. Model risk management, as commonly framed, concerns identifying, measuring, monitoring, and controlling risks arising from model use. The two overlap—continuity planning can be one control that helps manage the operational consequences of model failure—but they should not be treated as interchangeable. A continuity plan does not, on its own, satisfy broader model risk management expectations, and model risk management does not automatically produce a continuity plan.

Does having a continuity plan mean the risk of model disruption has been eliminated?

No. A continuity plan reduces and manages the impact of disruption; it does not eliminate the underlying risk. Its purpose is to shorten downtime, preserve critical operations, and provide fallback procedures when a model, data pipeline, or dependency fails. Residual risk typically remains—for example, from scenarios the plan did not anticipate, degraded fallback performance, or delays in recovery. Describing a continuity plan as removing risk overstates what such measures can achieve.

What fallback options are typically considered when an AI model becomes unavailable?

Commonly considered fallbacks include reverting to a prior validated model version, switching to a simpler rules-based or manual process, routing decisions to human review, or temporarily suspending the automated function. The appropriate choice generally depends on the criticality of the function, tolerance for reduced performance, and available resources. Plans often document which fallback applies to which scenario, since a single default may not be suitable across all failure modes.

How is a continuity plan typically tested?

Testing approaches often include tabletop exercises, simulated failure scenarios, and, where feasible, live or partial failover tests. The aim is to confirm that fallback procedures work as intended, that responsible parties understand their roles, and that recovery objectives are realistic. Testing frequency and rigor commonly scale with the criticality of the model. Note that testing scope, cadence, and acceptable methods can vary by organization and sector, so there is no single required approach.

Who is typically responsible for maintaining a model continuity plan?

Responsibilities are often distributed across lines of defense. In many frameworks, model owners or the business function operating the model (commonly associated with the first line) hold primary ownership of continuity arrangements, while risk and control functions (often the second line) may set expectations and review adequacy. Independent assurance functions may assess the plan periodically. Exact allocation of responsibility varies by organizational structure and should be defined explicitly rather than assumed.

How often should a continuity plan be reviewed and updated?

Plans are typically reviewed on a defined periodic cycle and also updated in response to triggering events—such as significant model changes, new dependencies, infrastructure migrations, or lessons learned from incidents and tests. Relying only on a calendar-based review can leave a plan out of date if material changes occur between cycles. Review cadence commonly reflects the model's criticality, but specific frequencies vary across organizations and are not standardized.

Common misconceptions

A continuity plan is the same thing as a model risk management control.

Continuity planning is an organizational and operational resilience measure, while model risk management focuses on identifying, measuring, monitoring, and controlling risks arising from a model's design and use. The two overlap where a model's failure triggers continuity actions, but they address different concerns and should not be treated as interchangeable.

Having a documented continuity plan means disruption risk has been eliminated.

A plan is a measure that reduces and manages the impact of disruption; it does not remove the possibility of failure. Residual risk typically remains even where fallback procedures and recovery objectives are defined, and untested plans may not perform as expected.

A single continuity plan applies uniformly across all AI systems and regulatory contexts.

Continuity expectations and their required rigor commonly vary by system criticality, sector, and jurisdiction. What is appropriate for a critical model in a regulated banking context may differ from a general enterprise AI deployment, so plans are generally scoped to the specific system and applicable obligations.

Best practices

Prioritize continuity measures based on a business impact analysis so that the most critical AI systems and model-dependent processes receive proportionate attention.

Define recovery objectives explicitly and tie them to system criticality rather than applying uniform targets across all models.

Assign clear roles for invoking and executing the plan, distinguishing first-line ownership from independent second-line oversight without blurring those responsibilities.

Map dependencies, including third-party data sources, infrastructure, and vendor-supplied models, so that disruptions originating outside the organization can be anticipated.

Test the plan periodically and update it as systems, dependencies, and risks change, treating it as a living document.

Confirm any regulatory notification or reporting expectations against the specific obligations applicable to your jurisdiction and sector, rather than assuming a single standard applies.