Business Continuity and Disaster Recovery Plan

1. Purpose

This plan sets out how CompleteFlow Ltd maintains continuity of its business operations and recovers the CompleteFlow platform in the event of a disruption. It supports the commitments CompleteFlow makes to customers on availability, recovery time, and recovery point.

2. Scope

This plan covers:

• Disruptions affecting CompleteFlow Ltd as an operating business (for example, loss of a key supplier, loss of premises, loss of personnel)
• Disruptions affecting the CompleteFlow platform as deployed in a customer's Azure subscription
• Disruptions affecting CompleteFlow's internal operational systems (source control, identity, monitoring)

It is read with CF-PLAN-001 Incident Response Plan; the two plans may be invoked in parallel.

3. Responsibilities

4. Recovery objectives

4.1 Platform (per customer deployment)

Recovery objectives (RTO, RPO, availability targets) are agreed with each customer in the applicable Service Level Agreement, in light of the customer's availability needs, Azure service capabilities in the deployment region, and any optional resilience features enabled (such as geo-redundant storage, PostgreSQL geo-replication, or cross-region DR).

The underlying architecture supports a range of objectives, drawing on:

• Azure Database for PostgreSQL Flexible Server point-in-time restore (up to 35 days), encrypted at rest using the customer's Azure Key Vault key
• Zone-redundant and (optionally) geo-redundant Blob Storage
• Zone-redundant configurations for supporting services where available in the deployment region
• Infrastructure-as-code re-deployment from source into a paired UK region where cross-region DR is enabled

Stricter targets are available on customer request, with the associated Azure architectural choices and commercial implications documented in the deployment specification and the customer's SLA.

4.2 Support hours

Standard CompleteFlow platform support is provided during UK business hours (09:00–17:30 Monday to Friday, excluding UK public holidays). Out-of-hours incidents are triaged at the start of the next business day, with immediate escalation where there is evidence of an ongoing attack, active data exposure, or sustained platform unavailability. Extended or 24×7 support can be agreed as part of a customer's SLA.

4.3 CompleteFlow business operations

CompleteFlow operates as a distributed team with cloud-based tooling and mobile-capable working. Continuity of customer support, engineering operations (deploy, secret rotation, emergency policy), and finance and commercial operations is maintained through documented runbooks and named deputies (see section 7).

5. Threat scenarios

The plan is designed against the following scenario classes:

• Azure regional outage affecting a customer's deployment region
• Service-level outage of a specific Azure service (for example, PostgreSQL Flexible Server, OpenAI, Key Vault) in a given region
• Data corruption affecting application data in a customer subscription (whether by fault or malicious act)
• Loss of a critical supplier (for example, identity provider, source control, monitoring)
• Loss of premises or local infrastructure: CompleteFlow operates as a distributed team so this is a limited exposure
• Loss of key personnel: single-point-of-knowledge risk
• Security incident with destructive consequences (handled in conjunction with CF-PLAN-001)

6. Platform recovery

6.1 Backups

• Azure Database for PostgreSQL Flexible Server: automated backups with point-in-time restore up to 35 days, encrypted at rest using the customer's Azure Key Vault key
• Azure Blob Storage: soft-delete enabled (default 14 days); optional geo-redundant storage for customers who opt in; immutable policies available where required by customer compliance
• Configuration as code: infrastructure definitions, application authorisation policies, and application configuration are versioned in source control; the customer's deployment is reproducible from source
• Secrets: Azure Key Vault provides soft-delete and purge protection; key material subject to Microsoft's HSM-backed key management
• Logs: retained in Azure Log Analytics per the retention configuration (default 90 days hot, 12 months archive)

6.2 Restore procedures

• Application data: point-in-time restore to a defined timestamp via Azure PostgreSQL Flexible Server restore; restored into a parallel database server for validation before cutover
• Blob data: restore from soft-delete, or failover to the geo-replica where configured
• Application services: re-deploy from source control against the restored data plane
• Identity: Azure Entra ID is a Microsoft-managed service with its own multi-region resilience
• Secrets: restore from Key Vault soft-delete where required; rotate any secret that may have been compromised

6.3 Regional failover

Where a customer has opted for cross-region resilience, the deployment architecture includes:

• Geo-replicated PostgreSQL in a defined secondary UK region (subject to Azure service availability in the secondary region)
• Geo-redundant Blob Storage
• Documented failover runbook with pre-defined DNS and application configuration changes

Failover is an operator-initiated activity to ensure it is not triggered inadvertently. The decision to fail over is taken by the Incident Commander in consultation with the customer.

6.4 Azure OpenAI continuity

Azure OpenAI Service is deployed in the customer's preferred region. Where model availability varies across regions, CompleteFlow documents fallback configurations. Transient Azure OpenAI unavailability is handled in application code through retry-with-backoff; sustained unavailability is treated as a service-level incident and managed under CF-PLAN-001.

7. Business operations continuity

7.1 Distributed operations

CompleteFlow operates as a distributed team with cloud-based tooling (source control, productivity, finance, identity), making it resilient to single-location events. Personnel work from CompleteFlow-managed devices with secure remote connectivity (CF-POL-004).

7.2 Key person risk

• Named deputies for Information Security Officer and Technical Lead roles
• Documented runbooks for time-critical operations (secret rotation, emergency access, customer notification)
• Break-glass accounts for critical cloud services, with access and use procedures under CF-POL-003 section 5.3
• Knowledge transfer expectations as part of role handover

7.3 Supplier continuity

For critical suppliers (sub-processors and material suppliers), the Supplier Management Policy (CF-POL-007) requires an assessment of continuity, and for CompleteFlow to maintain a documented view of alternatives. Alternative arrangements are identified and their viability reviewed annually.

7.4 Finance and commercial

• Cloud-based accounting and invoicing with multi-factor authentication and access controls aligned to CF-POL-003
• Business interruption insurance appropriate to the scale of CompleteFlow's operations
• Cyber-specific insurance where commercially warranted

8. Communications during a disruption

• A dedicated status page is maintained with customer-facing service status
• Direct email notification to nominated customer contacts for any event materially affecting their service
• Cadence of updates is defined at the start of the event and maintained until closure, at a frequency agreed with the customer under the applicable SLA
• On closure, a written summary is issued to affected customers within 5 working days

9. Testing and exercising

DR testing is conducted on a CompleteFlow-owned reference deployment that is provisioned from the same infrastructure-as-code as customer deployments. Exercising on the reference deployment means procedures can be validated without risk to customer data or service availability, while the architectural equivalence ensures findings translate directly to customer environments.

• Annual DR exercise: at least one full-scope DR exercise per year on the reference deployment, including restore of a representative database and validation of application behaviour against the restore. Findings are recorded and tracked to closure.
• Backup validation: periodic verification that backups complete, are retrievable, and are encrypted correctly.
• Tabletop exercise: at least annually, covering scenarios such as regional outage, critical supplier loss, and destructive incident (jointly with CF-PLAN-001).
• Failover test: where cross-region resilience is in scope, the failover procedure is tested annually or on material change, on the reference deployment.
• Customer-specific exercises: where a customer requests a DR test on their own deployment (for example, as part of their own audit), CompleteFlow supports this subject to mutually agreed scope and scheduling.

Exercise outputs are captured: what was tested, what worked, what did not, and what actions are required. Actions are tracked in the risk register (CF-REG-001). Where exercises uncover customer-impacting issues, affected customers are informed.

10. Plan maintenance

• The plan is reviewed at least annually by the Information Security Officer
• It is also reviewed after any significant change in architecture, suppliers, customer commitments, or regulatory context
• Version changes are recorded in the document control table

11. Document control