What the governing body should require for AI resilience and continuity

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

When an organization builds AI into its services, the model service, the retrieval store, and the model provider become operational dependencies of the business, alongside the applications and suppliers the organization already plans around. The continuity and disaster recovery policy places AI systems that support critical operations expressly inside its scope. Disruption to such an AI dependency falls within the continuity assessment the corpus already defines. It is not a novelty outside the plan.

The corpus does not treat AI resilience as a separate programme. It runs AI through the organization's existing continuity discipline (impact analysis, recovery objectives, backup, testing) and adds AI-specific controls where AI fails differently: a model can degrade rather than stop, a provider can retire a model version, and the safest containment can be to switch a capability off. The governing body's role is not to operate any of this; it is to require that AI dependencies are inside the continuity programme and to receive the evidence that they are. That single-programme reading is synthesized across the sources below; see the limitations.

• AI continuity is a policy requirement. The continuity and disaster recovery policy expressly places AI system continuity and supplier or cloud continuity inside its section 3 policy statements; use that section for the matters each must address. The executive consequence is that management must show AI dependencies inside the continuity programme.
• Proportionate controls and documented recovery objectives. The continuity and disaster recovery standard sets the AI continuity-control, recovery-objective, and dependency-mapping requirements in its section 2 (its sections 2.8, 2.2, and 2.3); use those sections for their contents. The specific objective values, schedules, and service tiers are set by the adopting organization, and this brief does not restate any value.
• AI dependencies enter through the impact analysis. The business impact analysis procedure requires the assessment to consider AI systems that the assessed process relies on (its "AI and data considerations"), and it defines the recovery objectives at its Step 5. The analysis is a dependency of the downstream continuity decisions: it is where the organization learns which services stop when an AI dependency fails. That reading is composite; see the limitations.
• AI artefacts are inside backup and recovery. The backup and recovery procedure expressly addresses AI in its Backup scope and its AI and data recovery requirements (its requirements 1 and 6); use those requirements for the exact scope. The executive consequence is that backup inventories and recovery design cannot omit applicable AI dependencies.
• Plans are tested, and AI has a named test type. The continuity and disaster recovery standard requires testing on a defined cadence (its section 2.7), and the continuity and recovery testing procedure defines an AI resilience test as a named test type; use that row for its validation contents. The resilience framework names AI and data resilience among its core components and, among its recommended metrics, a fallback-or-disablement coverage metric for AI systems (its metrics).
• AI failure has a defined response path. The AI incident response plan defines the AI incident classes, which include model degradation and supplier model incidents, the containment actions available (including disabling a specific capability or suspending a model version), and a staged recovery. Its severity structure and escalation bodies are defined in the plan itself; this brief routes to them. The cross-domain coordination procedure defines a hand-off into the AI stream where a security incident implicates an AI system, and a hand-off into the resilience stream from any domain on crisis activation (its hand-off checklists).
• The practices across four instruments are contributions to managing supplier dependence. The AI security and risk standard requires external AI services to be assessed against its supplier-and-external-service controls (its section 4.9). The foundation model lifecycle procedure manages provider version changes and escalates an involuntary deprecation as supplier and concentration risk, to the escalation body it names (its Step 6). The concentration risk register tracks single-provider reliance for AI features as a concentration finding with defined treatment options (its service-class dimension). The cloud exit and data portability standard sets contract provisions that every new cloud and SaaS contract must carry before signature, scopes a further exit-assistance provision to the higher service tiers it names, and requires a documented exit plan for cloud services hosting assets in those tiers (its sections 4 and 5).
• The governing body's instrument is defined. The board oversight guide establishes that the governing body sets appetite and policy direction while management operates within it (its section 4), provides the question set for structured interrogation (its section 5), and defines the regular reporting the governing body should receive, including on AI incidents (its section 7).

For the governing body and accountable executive leadership, the corpus position resolves into what to require of management, and one answer pattern to watch for. This reading is composite; see the limitations.

• Require inclusion, not a parallel programme. The corpus treats AI as one more class of critical dependency inside the existing continuity discipline. The question for management is therefore not "do we have an AI continuity plan" but "do our impact analyses, dependency maps, recovery objectives, backups, and tests cover our AI dependencies". Coverage across those artefacts, including the applicable backup scope, is a contribution to the outcome the governing body wants: services that degrade in a controlled way when an AI dependency fails.
• Require the fallback and disablement pair. The corpus repeatedly names two AI-specific capabilities: a fallback process and emergency disablement. Both appear in the policy, the impact analysis procedure, and the testing procedure. A documented, tested fallback is a prevention against an AI outage becoming a business outage; disablement without a fallback is only half the pair.
• Require supplier failure to be planned, not assumed away. Provider outage, provider model retirement, and provider concentration are failure modes the corpus addresses, and the practices below are contributions to managing them: assessment (AI security and risk standard, its section 4.9), lifecycle management (foundation model lifecycle procedure), the concentration risk register, and exit planning (cloud exit standard). "Our provider is resilient" is a weak answer: a supplier attestation is evidence for the supplier's own controls, and it is not a continuity plan for the organization's use of the supplier.
• Some answers are weak answers. "We can turn it off" without a fallback answers half the question. "The plan exists" without a test record answers none of it: a test record is the evidence of whether the plan met its objectives, and the testing procedure defines what that record contains. And a recovery objective's standing as a decision, not merely a number, has a dependency on its review against the impact analysis; the impact analysis procedure requires the recovery objectives to carry an accountable approval at its Step 7.

Each item below is an evidence class the governing body can call for from management, and each is evidence for a named control or outcome. The board oversight guide frames the questioning (its section 5); this list frames what a strong answer contains.

• Impact analysis records for AI-dependent critical services, as evidence that the AI considerations in the business impact analysis procedure were applied and that recovery objectives were approved at its Step 7.
• Dependency-map and recovery-objective register entries for AI-dependent critical services, as evidence for the mapping and objective requirements of the continuity and disaster recovery standard (its sections 2.2 and 2.3); the standard's minimum evidence set (its section 3) names the artefacts.
• AI resilience test results with corrective actions, as evidence for the AI resilience test's outcomes, per the test type and required record in the testing procedure, and the fallback-or-disablement coverage metric in the resilience framework.
• The backup inventory covering applicable AI artefacts, and restoration logs for the restoration activities performed, as evidence for the AI backup scope and recovery requirements in the backup and recovery procedure.
• The adopted AI incident response plan, and completed hand-off checklists where a cross-stream hand-off occurred, as evidence that model degradation and supplier model incidents are covered incident classes with containment and staged recovery paths, per the AI incident response plan, and that the hand-offs the cross-domain coordination procedure defines, into the AI stream from security and into the resilience stream on crisis activation, are in place.
• Supplier assessments for external AI services, as evidence for the supplier controls in the AI security and risk standard (its section 4.9).
• The documented rollback plan and the version-transition records for foundation models, as evidence that provider changes are managed per the foundation model lifecycle procedure (its Step 6 and its rollback-plan requirement).
• Any concentration findings concerning AI model providers, evidence that the concentration assessment was performed, and the exit plans for the cloud services in the tiers the standard names, as evidence that single-provider reliance is assessed and, where a finding exists, carries a treatment status, owner, and plan, per the concentration risk register and the cloud exit and data portability standard.

• This page creates no compliance and imposes no requirement. The linked corpus documents govern; where this page differs from a corpus document, the corpus document prevails.
• This page carries composite claims. The single-programme reading (that the corpus governs AI resilience through the general continuity discipline plus AI-specific controls), the "what to require of management" framing, the reading that the impact analysis is a dependency of the downstream continuity decisions, the weak-answer pattern in that same section, the four-instrument reading that those practices are contributions to managing supplier dependence, and the fallback-and-disablement pairing are synthesized across several corpus sources, and the adopting organization validates that reading against its own structure.
• The corpus documents this page points to carry the specific recovery objective definitions, test cadences, service tiers, severity classes, contract periods, escalation bodies, and approval authorities. This page routes to them and does not reproduce them; every value resolves to the corpus documents, not to this page.
• This page makes no claim about how likely any disruption is, and none of its statements should be read as a probability or a frequency.