BCR · Business Continuity Management and Operational Resilience

BCR-09Cloud & AI Related

Disaster Response Plan

Specification

Establish, document, approve, communicate, apply, evaluate and maintain a disaster response plan to recover from natural and man-made disasters. Update the plan at least annually or upon significant changes.

Threat coverage

Model manipulation

Data poisoning

Sensitive data disclosure

Model theft

Model/Service Failure

Insecure supply chain

Insecure apps/plugins

Denial of Service

Loss of governance

Architectural relevance

Physical infrastructure

Network

Compute

Storage

Application

Data

Lifecycle

Preparation

Data storage, Resource provisioning, Team and expertise

Development

Not applicable

Evaluation

Not applicable

Deployment

AI applications, Orchestration

Delivery

Operations, Maintenance, Continuous monitoring

Retirement

Archiving, Data deletion, Model disposal

Ownership / SSRM

Owned by the Cloud Service Provider (CSP)

The Cloud Service Provider (CSP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with cloud computing (processing, storage, and networking) technologies in the context of the services or products they develop and offer. The CSP is responsible and accountable for implementing the control within its own infrastructure/environment. The CSP is responsible for enabling the customer and/or upstream partner to implement/configure the control within their risk management approach. The CSP is accountable for ensuring that its providers upstream implement the control related to the service/product developed and offered by the CSP.

Model

Owned by the Model Provider (MP)

The model provider (MP) designs, develops, and implements the control as part of their services or products to mitigate security, privacy, or compliance risks associated with the Large Language Model (LLM). Model Providers are entities that develop, train, and distribute foundational and fine-tuned AI models for various applications. They create the underlying AI capabilities that other actors build upon. Model Providers are responsible for model architecture, training methodologies, performance characteristics, and documentation of capabilities and limitations. They operate at the foundation layer of the AI stack and may provide direct API access to their models. Examples: OpenAI (GPT, DALL-E, Whisper), Anthropic(Claude), Google(Gemini), Meta(Llama), as well as any customized model.

Orchestrated

Shared Model Provider-Orchestrated Service Provider (Shared MP-OSP)

The MP and OSP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.

Application

Owned by the Application Provider (AP)

The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.

Implementation guidelines

[All Actors]
1. Building Response Foundation:
a. Establish cross-functional teams with clearly defined roles and responsibilities.
b. Designate specific decision authorities empowered to act during time-sensitive situations.
c. Create explicit escalation pathways with activation criteria for different scenario types.
d. Develop detailed responsibility assignments covering all recovery functions.

2. During Incidents:
a. Deploy rapid diagnostic procedures identifying affected components and dependencies.
b. Conduct immediate impact assessment determining operational consequences.
c. Activate containment measures preventing problem escalation.
d. Execute stability verification before initiating recovery procedures.

3. During Recovery Operations Phase:
a. Implement pre-planned alternatives for critical functions.
b. Deploy progressive restoration based on established priorities.
c. Activate reconciliation procedures ensuring data and state consistency.
d. Execute verification protocols confirming successful function restoration.

4. Post Incident Response (PIR) and Activities:
a. Conduct comprehensive analysis of response effectiveness includes scheduling of PIR meetings.
b. Implement identified resilience improvements while memories remain fresh.
c. Update response procedures based on practical experience.
d. Document lessons learned for organizational knowledge preservation.

5. Cross-Entity Coordination:
a. Establish clear communication channels spanning organizational boundaries.
b. Create shared terminology ensuring consistent understanding during joint responses.
c. Develop notification procedures alerting dependent entities about potential impacts.
d. Implement synchronized status reporting during complex incidents.

Auditing guidelines

1. Examine the policy and procedures for adequacy, approval, communication, and effectiveness as applicable to a disaster response plan.

2. Examine the policy and procedures for evidence of review, upon significant changes, or at least annually.

3. Examine the documented disaster response plan specific to AI processing infrastructure, verifying it addresses recovery of physical facilities, network systems, compute resources,
and storage systems supporting AI workloads.

4. Verify that the plan has received formal approval from senior management responsible for infrastructure operations, with evidence of review and sign-off.

5. Assess the defined recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical infrastructure components, confirming they align with service level commitments to
dependent AI services.

6. Review documentation of geographic redundancy and failover mechanisms for infrastructure components, confirming implementation of technical controls that support rapid recovery.

7. Verify that critical infrastructure components' off-site backup and recovery capabilities are established and regularly tested.

8. Examine evidence that the disaster response plan has been communicated to all relevant personnel, including training records and awareness programs.

9. Review records of disaster recovery tests or exercises conducted within the past 12 months, confirming they included realistic scenarios relevant to AI infrastructure.

10. Verify that the plan is reviewed and updated at least annually and after significant infrastructure changes, with documented change history and revision approval.

Standards mappings

ISO 42001No Gap

ISO 42001: A.4.2 (Resource documentation)
ISO 42001: A.4.3 (Data resources)
ISO 42001: A.4.4 (Tooling resources)
ISO 27001 A.5.30 (ICT readiness for business continuity)

Addendum

N/A

EU AI ActPartial Gap

Article 15 (4) (accuracy, robustness, and cybersecurity)

Addendum

Establish, document, approve, communicate, apply, evaluate, and maintain a disaster response plan to recover from natural and man-made disasters. Update the plan at least annually or upon significant changes.

NIST AI 600-1Partial Gap

GV-1.5-002
MG-2.3-001

Addendum

Expand MG-2.3-001 or add an additional action that specifically requires disaster response planning that includes natural and other man-made disasters in incident response and recovery plans. This action should explicitly require a periodic review and update cycle to account for changes in risk exposure and ensure readiness for diverse disaster scenarios.

BSI AIC4No Gap

BCM-03

Addendum

N/A

AI-CAIQ questions (2)

BCR-09.1

Is a disaster response plan to recover from natural and man-made disasters established, documented, approved, communicated, applied, evaluated, and maintained?

BCR-09.2

Is the Disaster Response Plan updated at least annually or upon significant changes?