CF01-014: AI Business Continuity & Operational Resilience Policy

AI Control Library / CF-01: Lifecycle Governance

Designation: Core | Control types represented: Operational

AI failure can interrupt a business process even when the rest of its infrastructure remains available. Continuity policy must address loss of trustworthy output as well as outright service outage.

Control requirement

Establish an approved policy for maintaining or safely suspending critical AI-supported services during disruption. Define resilience objectives, acceptable degradation, recovery priorities, responsibilities and requirements for plans, testing and supplier dependencies.

Why this matters

The control is effective when its required decisions and safeguards can be demonstrated in the actual workflow. An approved document or completed form alone is insufficient if the described actions are not performed.

How the control types work together

Operational controls provide the policies, decisions and recurring processes described here.

When it applies

Business processes dependent on AI, including hosted services, identity providers, data pipelines and human review capacity.

Tailor depth and review frequency to potential impact, system authority and uncertainty. Document the reason for any exclusion; a supplemental designation does not make an otherwise applicable safeguard optional.

Ownership

The business continuity sponsor is accountable; business and AI system owners establish service priorities with technology and risk teams.

Implementation guidance

  1. Identify critical AI-supported processes and the consequences of unavailability or unreliable output.
  2. Set approved service recovery objectives and minimum operating levels based on business impact, including when safe suspension is required.
  3. Assign continuity planning, exercises, supplier coordination and communication responsibilities; resource viable manual or alternative workflows.
  4. Review policy after significant dependency changes, disruptions and exercises; verify that detailed plans implement the approved priorities.

How to verify it

Use a representative sample of actual records or an authorized controlled exercise. A reviewer with suitable expertise should compare observed practice with the approved scope and acceptance criteria.

Test Expected result
Inspect a critical AI service Its recovery priority, minimum service and accountable owner are explicit.
Compare continuity plans with policy objectives Plans and resources support the stated requirements.
Consider available but unreliable output A defined degradation or suspension decision exists.

Record a finding when a required result is absent, evidence cannot substantiate the claim, or practice differs materially from the approved conditions. An exception may record accepted risk, but does not turn a failed safeguard into an effective one.

Evidence to retain

  • Approved resilience policy
  • Critical-service priorities
  • Recovery objectives and responsibilities
  • Plan and exercise oversight records

Protect evidence according to its sensitivity and approved retention requirements. Retain enough detail to substantiate the assessment without unnecessarily duplicating confidential or personal information.

If the control fails

Escalate unsupported recovery commitments to the continuity sponsor. Restrict dependence on AI where failure would exceed tolerance and no viable fallback or safe suspension is available.

Example in practice

Hypothetical example: A support center defines a reduced manual queue for a model-provider outage. Its policy also activates that queue when answer reliability becomes unacceptable, even if the provider reports normal uptime.

Related controls

Framework mappings

  • CSA AICM (BCR-01)
  • NIST AI RMF (MANAGE 4.1)
  • EU AI Act (Art. 9(2)(e))
  • ISO 42001 (Cl. 8.2)

Review and maintenance

Review at the interval approved by the control owner and after a material change, relevant incident or failed assessment. Reassess the affected scope, update records and verify corrective actions before closing findings.

Back to Lifecycle Governance

Version 1.0

Scroll to Top