SC-AI-033 · Security and resilience

Business continuity and fallback for AI

Medium effortCovered by ISO 27001: StrongSatisfies 6 obligations in 5 policies

What it means

  • Plan for AI failing, both loudly (outage, vendor API down) and silently (model quietly getting worse, drift, bad update).
  • Each critical AI process has a fallback: a backup model, a rules-based process, or a manual process with trained staff.
  • You can stop an AI system instantly if it risks significant harm, and keep the business running.
  • ISO 27001 reuse: Partial. ISO 27001 continuity, ICT readiness, backup and redundancy controls give the framework. New for AI: silent degradation triggers, model rollback, sampling of AI decisions and LLM vendor concentration.

Why it matters

  • RBI FREE-AI asks regulated entities to extend BCP to AI failures, including silent degradation, with fallbacks, drills and sample human checks of AI decisions.
  • RBI FREE-AI also expects the ability to shut down an AI system instantly if it risks significant harm.
  • Heavy dependence on one LLM provider is a concentration risk; outages and sudden model changes do happen.

Checklist

  1. Mark AI systems supporting critical services in the inventory and include them in the business impact analysis.
  2. For each, document the fallback (secondary model or provider, rules engine, manual queue) and who switches over.
  3. Set recovery time and capacity targets for the fallback (for example manual processing for 48 hours).
  4. Build the kill switch into the BCP: who decides, how fast, what customers see (SC-AI-026 Human oversight and override).
  5. Define silent-failure triggers from monitoring (drift, error rate, complaint spikes) that invoke BCP (SC-AI-020 Performance monitoring and drift detection).
  6. Sample human checks of AI decisions on a regular schedule to catch silent degradation.
  7. Back up model artefacts, prompts, configurations and vector indexes so a known-good version can be restored.
  8. Assess LLM vendor concentration and exit options (SC-AI-007 Third-party and vendor AI due diligence).
  9. Drill the fallback at least yearly; record results and fixes.

Evidence examples

  • BCP and BIA updated with AI systems and fallbacks.
  • Fallback runbooks and switch-over decision authority.
  • Drill report showing time to switch and issues found.
  • Sample human check records of AI decisions.
  • Backup records of model artefacts and configuration.
  • Vendor concentration assessment for LLM providers.

Common pitfalls

  • Manual fallback exists on paper but the team that knew the manual process has moved on.
  • BCP only covers outages, not a model that keeps running but gives wrong answers.
  • Vendor silently updates the model; no pinned version and no rollback.
  • Kill switch with no plan for what customers experience after it is pulled.

Satisfies

Standards crosswalk

Clause references only. Check the standard itself for the exact wording.

ISO/IEC 42001

  • 6.1.3 AI risk treatment
  • A.6.2.6 operation and monitoring

ISO/IEC 27001

  • A.5.29 information security during disruption
  • A.5.30 ICT readiness for business continuity
  • A.8.13 information backup
  • A.8.14 redundancy of information processing facilities

SOC 2

  • A1.1
  • A1.2
  • A1.3
  • CC7.5
  • CC9.1

Key takeaways

  • Plan for silent failure, not just outages.
  • Every critical AI process needs a tested fallback and a tested kill switch.
  • Reuse your ISO 27001 BCP; add AI-specific triggers and drills.

Find your gaps

Our free compliance gap assessment shows which of these controls you already run.

Start the gap assessment

Have us build it with you

Our AI Governance service implements controls like this one and produces the evidence auditors expect.

Explore AI Governance