Business Continuity Plan

1. Purpose and Scope

This Business Continuity Plan (BCP) sets out how MissionOpsAI Ltd (company registration number 14437210) will maintain or rapidly restore critical business functions in the event of a disruption. It covers the Company's core activities: operation and development of the Foundry sovereign AI orchestration platform, delivery of professional services to clients, and maintenance of client-facing production systems.

The Company operates a distributed, infrastructure-as-code model with no single physical premises dependency. This architecture provides inherent resilience against many common disruption scenarios. This plan addresses the residual risks that require specific continuity arrangements.

2. Critical Business Functions

The following functions are identified as critical, requiring prioritised recovery:

3. Infrastructure Architecture and Resilience

The Company's production infrastructure is distributed across five nodes hosted with Hetzner (European data centres) and a dedicated inference provider:

Node 1 (Primary Production — Helsinki). Hosts the Foundry platform core, client-facing capabilities including cmd.missionopsai.com, foundry.missionopsai.com, canvas.missionopsai.com, and the primary Gitea code repository at git.missionopsai.com. Caddy reverse proxy. SystemD service management. This is the primary production environment.

Node 2 (Showroom — secondary). Hosts demonstration and showcase capabilities including drone-demo.missionopsai.com. Traefik reverse proxy with Docker Compose. Available as a partial fallback for non-critical client-facing functions where Node 1 is unavailable.

Node 3 (NIGHTINGALE — NHS platform). Dedicated node for the NIGHTINGALE NHS sovereign AI platform. Isolated from other Foundry infrastructure. Subject to NHS-specific recovery requirements.

Node 5 (Inference). Dedicated Ollama inference node. Hosts local language models for bulk and routine tasks. If unavailable, model routing falls back to cloud API providers (Anthropic, OpenAI, Mistral) with cost implications.

Code Repository. All production code is version-controlled in Gitea at git.missionopsai.com. The repository is the authoritative source of truth for all platform code. Regular off-site backups are maintained.

Database. PostgreSQL on Node 1 with regular automated backups. Backup retention and restoration procedures are tested quarterly.

4. Threat Scenarios and Response

4.1 Node 1 Infrastructure Failure

Trigger. Node 1 becomes unavailable due to hardware failure, data centre incident, or network disruption.

Immediate response.

1. Confirm outage scope via Hetzner status page and direct SSH attempts.
2. Notify affected clients within 2 hours of confirmed outage.
3. Assess whether Node 2 can serve any critical client-facing functions on an interim basis.
4. Engage Hetzner support for hardware recovery or initiate new node provisioning.
5. Restore from latest database backup and git repository to new or recovered node.
6. Validate all services against checklist before redirecting DNS.

Recovery. Target RTO 4 hours for critical services. Full restoration within 24 hours.

4.2 Key Person Unavailability

Trigger. The CEO (sole director and primary technical lead) becomes unavailable for an extended period due to illness, accident, or other cause.

Immediate response.

1. All system credentials, infrastructure access details, and client contact information are documented in a secure password manager accessible to the designated emergency contact.
2. The designated emergency contact (identified separately and updated annually) has sufficient access and briefing to maintain critical services and communicate with clients during a short-term absence.
3. For extended unavailability (over 7 days), the Company will engage a trusted technical contractor to maintain critical systems while business continuity arrangements are reviewed.

Mitigation. The Company maintains up-to-date runbooks for all critical operational procedures. These are stored in the Gitea repository and reviewed quarterly.

4.3 Cyber Security Incident

Trigger. Unauthorised access, ransomware, data breach, or other cyber security incident affecting Company systems.

Immediate response.

1. Isolate affected systems immediately to prevent lateral movement.
2. Preserve evidence — do not wipe affected systems before forensic capture.
3. Notify the CEO and engage the incident response process under the Company's Security Policy.
4. Where personal data is involved, assess notification obligations under UK GDPR Article 33 (72-hour notification window to ICO where applicable).
5. Notify affected clients as soon as the scope of impact is understood.
6. Restore from clean backups after incident is contained and root cause identified.

Cyber insurance. The Company holds Cyber Essentials certification and is entitled to cyber liability insurance arranged through IASME, providing up to £25,000 of cover including 24/7 incident response support.

4.4 Loss of Key Supplier

Trigger. A critical supplier (Hetzner, Anthropic API, Stalwart email, Brevo relay) becomes unavailable or terminates service.

Response. The Company maintains documented contingency arrangements for each critical supplier dependency, including alternative providers and migration procedures. Model routing can be adjusted to alternative providers via configuration change. Infrastructure can be migrated to alternative European hosting providers. These contingency arrangements are reviewed annually.

4.5 Loss of Premises

Trigger. The registered office or any working location becomes inaccessible.

Response. The Company operates a remote-first model. No critical function depends on access to a single physical location. All personnel are equipped to work fully remotely. This scenario has minimal operational impact.

5. Communication

In the event of a significant disruption, the CEO (or designated emergency contact in the CEO's absence) is responsible for:

• Notifying affected clients within the timeframes specified in their service agreements
• Maintaining a log of the incident, actions taken, and communications sent
• Providing regular updates to clients until services are fully restored
• Conducting a post-incident review and updating this plan accordingly

6. Testing and Review

This plan will be reviewed annually and tested at least once per year through a desktop exercise that walks through the response to a simulated incident. Any gaps or weaknesses identified will be addressed before the next review cycle.

The plan will also be reviewed and updated following:

• Any significant change to infrastructure architecture
• Any actual incident where the plan was invoked
• Any change in key personnel or emergency contact arrangements

7. Responsibilities

The CEO holds overall accountability for business continuity planning and incident response. All employees and contractors are responsible for familiarising themselves with the aspects of this plan relevant to their role and for cooperating with any invocation of the plan.

This plan has been approved by the Board of Directors of MissionOpsAI Ltd.