Business Continuity Planning for AI Dependencies

Introduction

Modern organizations increasingly embed artificial intelligence into mission-critical operations: fraud detection, customer service chatbots, supply chain forecasting, credit decisioning, medical triage, and cybersecurity monitoring. As these AI systems move from experimental pilots to production dependencies, a critical question emerges: what happens to the business when the AI stops working? Business Continuity Planning (BCP) for AI dependencies is the discipline that answers this question. Within the ISACA Advanced in AI Risk (AAIR) body of knowledge, this topic sits in the AI Risk Program Management domain, reflecting its position as a core governance responsibility rather than a purely technical concern.

This guide explains why BCP for AI dependencies matters, what it is, how it works in practice, and how to approach exam questions on the subject.

Part 1: Why Business Continuity Planning for AI Dependencies Is Important

1.1 AI has become a single point of failure
Many organizations have quietly built operational dependence on AI without updating their continuity plans. A customer service function that once relied on 500 human agents may now rely on a large language model handling 80 percent of inquiries with a reduced human team. If the model becomes unavailable, the organization cannot simply revert to the old staffing level overnight. The AI dependency has become a concentration risk.

1.2 AI fails differently than traditional IT
Traditional disaster recovery assumes a system is either up or down. AI systems introduce new failure modes:
- Silent degradation: the model keeps running but produces increasingly inaccurate outputs due to data drift or concept drift.
- Upstream dependency failure: a third-party foundation model API changes behavior, is deprecated, rate-limited, or taken offline.
- Data pipeline failure: training or inference data feeds break, causing stale or missing inputs.
- Compute scarcity: GPU or specialized hardware becomes unavailable or prohibitively expensive.
- Regulatory or legal shutdown: a regulator orders a model withdrawn, or a court finds the model violates rights.
- Adversarial compromise: model poisoning, prompt injection, or model theft forces the organization to take the system offline.
- Vendor insolvency or acquisition: an AI provider ceases operations or changes licensing terms.
Traditional BCP frameworks were not designed with these scenarios in mind, which is why AI-specific continuity planning is required.

1.3 Third-party and concentration risk
A small number of providers supply the foundation models, cloud compute, and specialized hardware underpinning most enterprise AI. This creates systemic concentration risk. Regulators such as those enforcing the EU Digital Operational Resilience Act (DORA) and banking supervisors increasingly expect firms to identify critical third-party ICT providers, including AI providers, and to maintain exit strategies and substitutability plans.

1.4 Regulatory and framework expectations
Multiple frameworks now expect organizations to address AI resilience:
- NIST AI Risk Management Framework: the MANAGE function calls for mechanisms to respond to and recover from AI incidents and to decommission systems safely.
- ISO/IEC 42001 (AI Management Systems): requires planning for AI system lifecycle events including failure and withdrawal.
- ISO 22301 (Business Continuity Management Systems): the general BCMS standard that AI continuity should integrate with.
- EU AI Act: high-risk systems require robustness, accuracy, cybersecurity, and human oversight, implying fallback and resilience measures.
- DORA and financial sector guidance: ICT third-party risk, exit strategies, and testing of resilience.

1.5 Business and reputational stakes
When AI fails without a continuity plan, consequences include revenue loss, regulatory penalties, safety harm, erosion of customer trust, and in some cases the inability to perform legally mandated functions. The AI risk professional must ensure that leadership understands these stakes and funds appropriate resilience.

Part 2: What Business Continuity Planning for AI Dependencies Is

2.1 Core definitions
- Business Continuity Planning (BCP): the process of creating systems of prevention and recovery to ensure that critical business functions continue during and after a disruption.
- Disaster Recovery (DR): the technology-focused subset of BCP that restores IT systems and data after an incident.
- AI dependency: any business process, decision, product, or control whose performance relies on an AI system, model, dataset, or AI service provider.
- Business Impact Analysis (BIA): the analysis that identifies critical functions, quantifies the impact of their disruption over time, and establishes recovery objectives.
- Recovery Time Objective (RTO): the maximum acceptable time to restore a function after disruption.
- Recovery Point Objective (RPO): the maximum acceptable data loss measured in time. For AI, this extends to model versions, training data snapshots, feature stores, and prompt or configuration repositories.
- Maximum Tolerable Period of Disruption (MTPD) or Maximum Tolerable Downtime (MTD): the point beyond which the disruption threatens the viability of the organization.
- Minimum Business Continuity Objective (MBCO): the minimum level of service acceptable during a disruption. For AI, this often defines an acceptable degraded mode.
- Graceful degradation: designing a system so that when AI components fail, functionality reduces in a controlled manner rather than collapsing entirely.
- Fallback mechanism: an alternative path (manual process, rule-based system, simpler model, cached result, alternate vendor) that takes over when the primary AI fails.
- Exit strategy: a documented plan to transition away from a third-party AI provider in a controlled manner.
- Substitutability: the degree to which an AI service can be replaced by another provider or in-house capability.

2.2 Scope of AI dependencies
A complete AI dependency map covers several layers:
1. Business processes that consume AI outputs.
2. AI models themselves, including version, owner, and criticality.
3. Data dependencies: training data, inference data feeds, feature stores, vector databases, labeling services.
4. Infrastructure: GPUs, accelerators, cloud regions, MLOps platforms, orchestration tooling.
5. Third parties: foundation model providers, API services, data vendors, annotation vendors, open-source components and their maintainers.
6. People and skills: data scientists, ML engineers, and subject matter experts who can maintain or replace the system.
7. Downstream consumers: other systems, customers, or partners that depend on the AI output.

2.3 How AI BCP differs from traditional BCP
Traditional BCP focuses on availability of systems and data. AI BCP must additionally address:
- Correctness continuity: ensuring outputs remain accurate and fair, not just available.
- Model reproducibility: ability to rebuild or retrain a model from versioned data, code, and parameters.
- Behavioral drift of external models: a vendor may update a model silently, changing outputs without an outage.
- Human capacity: the ability to scale human review or manual processing when automation fails.
- Ethical and safety fallbacks: ensuring that degraded modes do not introduce bias or safety harm.

Part 3: How Business Continuity Planning for AI Dependencies Works

An effective AI continuity program follows a lifecycle that mirrors ISO 22301 but is adapted for AI characteristics.

Step 1: Inventory and map AI dependencies
Begin with the AI system inventory or model registry maintained by the AI governance function. For each AI system, document the business processes it supports, the data it consumes, the infrastructure it runs on, the third parties involved, and the downstream consumers. Create dependency maps that reveal shared dependencies, for example multiple critical processes relying on the same foundation model API. Shared dependencies are concentration risks and must be flagged.

Step 2: Conduct an AI-aware Business Impact Analysis
For each AI-dependent process, assess the impact of disruption over time across financial, operational, regulatory, reputational, safety, and customer dimensions. Determine criticality tiers. Establish RTO, RPO, MTPD, and MBCO. For AI, ask specific questions:
- Can the process operate without the AI? For how long? At what capacity?
- What is the impact if the AI produces wrong outputs rather than no output?
- Is there a legal or contractual obligation tied to the AI output?
- Does a human alternative exist, and how quickly can it scale?

Step 3: Perform risk assessment and scenario analysis
Identify threats to each dependency and estimate likelihood and impact. Develop AI-specific scenarios such as:
- Foundation model provider outage lasting 24 hours.
- Vendor deprecates the model version in use with 30 days notice.
- Model performance degrades 20 percent due to data drift.
- Regulator orders suspension of the model.
- Data poisoning discovered in training pipeline requiring model rollback.
- Cloud region hosting GPU clusters fails.
- Key ML engineers leave and no one can retrain the model.
- Open-source library with a critical vulnerability must be removed.
Scenario analysis links the risk register to continuity strategies.

Step 4: Design continuity and resilience strategies
Select strategies proportionate to criticality. Common strategies include:
- Manual fallback: pre-documented manual procedures and trained staff who can take over. Includes surge staffing arrangements.
- Rule-based or heuristic fallback: a simpler deterministic system that provides acceptable, if less optimal, results.
- Shadow or champion-challenger models: a secondary model, possibly from a different vendor or architecture, kept warm and validated.
- Multi-vendor or multi-model abstraction: an abstraction layer that allows switching between model providers with minimal code change, reducing lock-in.
- Cached or precomputed outputs: serving recent results when live inference is unavailable, with appropriate staleness warnings.
- Graceful degradation design: the application disables AI features while preserving core functionality.
- Model and data versioning: immutable storage of model artifacts, training data snapshots, code, and configurations to enable rollback and rebuild.
- Infrastructure redundancy: multi-region deployment, reserved capacity, hybrid cloud and on-premises options.
- Contractual controls: SLAs, deprecation notice periods, escrow of model weights where feasible, audit rights, exit assistance clauses, and data return and deletion commitments.
- Exit strategy: a documented plan with triggers, timelines, and responsibilities for migrating away from a provider.
- Human oversight escalation: predefined thresholds at which human review expands, for instance when confidence scores drop or monitoring detects drift.

Step 5: Develop plans and procedures
Document the continuity plan for each critical AI dependency. Include activation criteria, roles and responsibilities, communication plans, step-by-step fallback procedures, decision authority for switching modes, and criteria for returning to normal operations. Integrate the AI continuity plan with the enterprise BCP, DR plan, AI incident response plan, and third-party risk management program so they do not operate in silos.

Step 6: Implement monitoring and triggers
Because AI can fail silently, continuity plans need monitoring that detects degraded performance, not just outages. Key signals include model accuracy metrics, drift indicators, latency, error rates, confidence distributions, fairness metrics, vendor status notifications, and anomaly alerts. Define thresholds that automatically or semi-automatically trigger fallback modes.

Step 7: Test and exercise
Untested plans provide false assurance. Testing approaches include:
- Tabletop exercises: walk through AI failure scenarios with business, technology, legal, and risk stakeholders.
- Failover drills: actually switch to the backup model or vendor in a controlled environment.
- Chaos engineering: deliberately inject faults such as API timeouts or corrupted inputs to observe system behavior.
- Manual process rehearsals: have staff perform the manual fallback to validate capacity and documentation.
- Rebuild tests: verify the model can be retrained or restored from versioned artifacts within RTO.
Document results, identify gaps, and remediate.

Step 8: Maintain, review, and improve
Review plans when AI systems change, when vendors change terms, after incidents, after tests, and at least annually. Track metrics such as percentage of critical AI systems with tested continuity plans, number of single-vendor dependencies, average time to failover in tests, and open remediation items. Report to the AI governance committee and board risk committee.

3.1 Governance roles
- Board and executive leadership: set risk appetite for AI dependency and resilience; approve investment.
- AI risk or AI governance function: owns the AI dependency inventory, ensures BIA coverage, and integrates AI into enterprise BCP.
- Business process owners: define criticality, RTO, RPO, and MBCO; own manual fallback procedures.
- Model owners and ML engineering: implement technical fallbacks, versioning, monitoring, and rebuild capability.
- Third-party risk management: assess vendor resilience, negotiate contractual protections, maintain exit strategies.
- Business continuity management: integrate AI plans into the BCMS, lead exercises.
- Internal audit: provide independent assurance that plans exist, are tested, and are effective.

3.2 Linkage to the three lines model
First line (business and technology teams) builds and operates fallbacks. Second line (risk, compliance, AI governance) sets requirements, challenges adequacy, and monitors. Third line (internal audit) independently assures. Exam questions frequently test whether a candidate can place a responsibility in the correct line.

Part 4: How to Answer Exam Questions on Business Continuity Planning for AI Dependencies

AAIR exam questions are scenario-based and test judgment, not memorization alone. The following approach helps.

4.1 Identify what is really being asked
Questions often use phrases such as BEST, MOST important, FIRST, PRIMARY, or GREATEST concern. These signal that multiple options may be partially correct and you must choose the one that best reflects risk management principles and sequencing.
- FIRST questions usually point to foundational steps: inventory the AI dependencies, perform a BIA, or understand business requirements before selecting technical solutions.
- MOST important or BEST questions favor the option that addresses the root risk or aligns with business objectives over a narrow technical fix.
- GREATEST concern questions favor the option with the largest potential impact on the business, often concentration risk, untested plans, or lack of a manual fallback for a critical process.

4.2 Apply the risk management mindset
ISACA exams reward answers that:
- Start with business impact and risk assessment before technology.
- Align controls to criticality and risk appetite rather than applying maximum controls everywhere.
- Prefer governance, accountability, and process over isolated tools.
- Emphasize testing and validation over documentation alone.
- Integrate AI into enterprise frameworks rather than creating parallel silos.

4.3 Recognize AI-specific distractors
Wrong answers often apply traditional IT thinking without AI adaptation. For example, an option that says restore the model from backup may be incomplete if the real issue is drift, where the restored model would be equally stale. An option that focuses only on availability may miss correctness continuity. Be alert to options that ignore third-party concentration or human capacity.

4.4 Use elimination
Remove options that are out of sequence, out of scope, overly technical when a governance answer is needed, or that address a symptom rather than the cause. Then compare the remaining options against the key principle being tested.

Part 5: Exam Tips: Answering Questions on Business Continuity Planning for AI Dependencies

Tip 1: The BIA comes first. If a question asks what should be done first when developing continuity plans for AI, the answer almost always involves identifying critical AI dependencies and performing a business impact analysis. Selecting a backup vendor or building redundancy before understanding criticality is premature.

Tip 2: Criticality drives proportionality. Not every AI system needs a hot standby. The best answer matches the continuity strategy to the criticality tier established in the BIA. Watch for options that propose expensive redundancy for low-impact systems.

Tip 3: Think availability AND correctness. AI continuity includes silent degradation. If a scenario describes a model that is running but producing poor outputs, the right continuity response involves drift monitoring thresholds, human oversight escalation, or model rollback, not just uptime measures.

Tip 4: Concentration risk is a top concern. When multiple critical processes depend on a single foundation model provider or a single cloud region, that concentration is typically the GREATEST concern. Remedies include multi-vendor abstraction layers, exit strategies, and contractual protections.

Tip 5: Contracts are controls. SLAs, deprecation notice periods, exit assistance clauses, audit rights, and escrow arrangements are legitimate continuity controls for third-party AI. Do not dismiss contractual options as merely legal matters.

Tip 6: Manual fallbacks must be realistic. A documented manual procedure that requires staff who no longer exist is not an effective control. Look for options that address human capacity, training, and rehearsal.

Tip 7: Untested equals unproven. A plan that has never been exercised offers weak assurance. If a question asks how to gain confidence that AI continuity plans will work, the answer is testing, such as tabletop exercises, failover drills, or rebuild tests, not more documentation.

Tip 8: Versioning enables recovery. For model and data continuity, immutable versioning of model artifacts, training data, code, and configuration is the foundation for rollback and rebuild. Questions about restoring a compromised or drifted model often point here.

Tip 9: Integrate, do not isolate. ISACA favors integrating AI continuity into the enterprise BCMS, DR, incident response, and third-party risk programs. Options proposing a standalone AI continuity program disconnected from enterprise governance are usually wrong.

Tip 10: Know your recovery metrics. Be precise about RTO (time to restore), RPO (acceptable data loss), MTPD or MTD (survival threshold), and MBCO (minimum acceptable service level). For AI, RPO applies to model versions and training data, and MBCO often defines the degraded mode.

Tip 11: Place responsibilities correctly. Business owners define criticality and manual procedures; ML engineering implements technical fallbacks; third-party risk negotiates vendor protections; AI governance coordinates and challenges; internal audit assures independently; the board sets appetite. Questions about who should do something test this structure.

Tip 12: Fallbacks must remain ethical and safe. A degraded mode that introduces bias, removes required human oversight, or creates safety hazards is not acceptable. The best answer preserves regulatory compliance and fairness even in fallback.

Tip 13: Exit strategies are expected for critical vendors. Especially in regulated sectors, maintaining a documented, feasible exit strategy for critical AI providers is a standard expectation. An answer that includes exit planning is often stronger than one that relies solely on SLAs.

Tip 14: Read for the lifecycle stage. Determine whether the scenario is in planning, implementation, testing, or maintenance. The correct action depends on stage. For example, after a vendor announces a model deprecation, the appropriate step is to activate the exit or migration plan and reassess dependencies, not to begin a BIA from scratch.

Tip 15: When in doubt, choose the business-aligned governance answer. If two options seem technically valid, the one that ties back to business impact, risk appetite, accountability, and enterprise integration is more likely to be the ISACA-preferred answer.

Part 6: Sample Question Walkthroughs

Sample 1. An organization relies on a third-party large language model API for its primary customer support channel. Which of the following should be the AI risk manager's GREATEST concern?
A. The API has experienced two brief outages in the past year.
B. No alternative channel or fallback exists if the API becomes unavailable.
C. The vendor contract does not include a penalty clause for downtime.
D. The model occasionally produces verbose responses.
Analysis: Option B represents the absence of any continuity capability for a critical process, which is the fundamental risk. Outages (A) and contract penalties (C) matter, but a penalty does not restore service and brief outages are tolerable if a fallback exists. D is a quality issue, not continuity. Answer: B.

Sample 2. When developing a business continuity plan for AI-enabled processes, which of the following should be performed FIRST?
A. Negotiate multi-vendor contracts for foundation models.
B. Deploy a redundant model in a second cloud region.
C. Identify AI dependencies and conduct a business impact analysis.
D. Schedule a failover test.
Analysis: The BIA establishes what is critical and what recovery objectives apply. Without it, vendor negotiations, redundancy, and testing lack a basis. Answer: C.

Sample 3. A fraud detection model continues to operate but its precision has declined significantly due to changes in transaction patterns. Which continuity measure is MOST appropriate?
A. Restore the model from last week's backup.
B. Activate predefined thresholds that escalate transactions to human review and initiate model retraining.
C. Increase the server capacity for the model.
D. Wait for the vendor to release an updated version.
Analysis: This is silent degradation from drift. Restoring last week's model (A) will not fix drift. Capacity (C) is irrelevant. Waiting (D) is passive. B addresses correctness continuity through human oversight escalation and remediation. Answer: B.

Sample 4. Which of the following provides the BEST assurance that an AI continuity plan will function as intended?
A. The plan has been approved by the AI governance committee.
B. The plan is reviewed annually by the model owner.
C. The plan has been exercised through a failover drill with documented results.
D. The plan references the enterprise BCP framework.
Analysis: Approval, review, and alignment are good practices, but only testing demonstrates that the plan works. Answer: C.

Part 7: Key Takeaways

- AI systems have become critical business dependencies, and their failure modes differ from traditional IT, requiring AI-specific continuity planning.
- The process begins with dependency inventory and an AI-aware BIA, proceeds through risk assessment and strategy design, and is validated through testing and continuous improvement.
- Strategies span manual fallbacks, rule-based alternatives, multi-vendor abstraction, model and data versioning, infrastructure redundancy, contractual protections, and exit strategies.
- Monitoring must detect silent degradation, not just outages, and should trigger predefined fallback and human oversight actions.
- Governance integration, clear accountability across the three lines, and alignment with frameworks such as NIST AI RMF, ISO 42001, ISO 22301, and DORA are expected.
- On the exam, favor answers that start with business impact, match controls to criticality, address concentration risk, treat contracts as controls, prioritize testing, and integrate AI continuity into enterprise risk and resilience programs.

Mastering this topic equips the AI risk professional to ensure that the organization can continue to operate safely, compliantly, and effectively even when the intelligence it has come to depend on is unavailable or unreliable.