Business Continuity & Disaster Recovery

1. Overview

XBert Pty Ltd maintains a comprehensive Business Continuity Plan (BCP) and Disaster Recovery (DR) strategy to ensure the availability and resilience of our platform. As a SaaS platform hosted entirely on Microsoft Azure Platform-as-a-Service (PaaS), XBert leverages Azure’s built-in high availability, geo-redundancy, and automated recovery capabilities to minimise downtime and data loss.

This document outlines the controls, procedures, and responsibilities that enable XBert to maintain service continuity in the event of disruption, and to recover critical systems within defined timeframes.

2. Objectives

The objectives of XBert’s BCP/DR programme are to:

• Maintain availability of customer-facing services with minimal disruption
• Protect customer financial data against loss or corruption
• Recover critical systems within defined Recovery Time and Recovery Point Objectives
• Provide clear roles, responsibilities, and communication channels during incidents
• Comply with applicable regulatory requirements and industry best practices
• Test and validate recovery procedures on a regular basis

3. Scope

This plan covers all XBert production applications and supporting infrastructure:

Application	Description
Web application & API	Primary customer-facing web application and backend API
Subscription billing service	Subscription, plan management, and billing integration
Data processing layer	Background processing and accounting-data fabric (Azure Function Apps, queue-based processing)
Reporting & analytics	Reporting and analytics service

Supporting infrastructure within scope includes:

• Azure SQL databases
• Azure Blob Storage
• Azure Key Vault
• Azure Service Bus
• Azure Container Apps
• CI/CD pipelines (Azure DevOps)
• Source code repositories (GitHub Enterprise)
• Third-party integrations (Auth0, Chargebee, Stripe)

4. Recovery Objectives

Metric	Target	Description
Recovery Time Objective (RTO)	Less than 24 hours	Maximum acceptable time from disaster declaration to restoration of critical services
Recovery Point Objective (RPO)	Less than 1 hour	Maximum acceptable data loss, measured in time, ensured by continuous database point-in-time recovery

These targets apply to all Tier 1 (critical) applications listed in the scope. Non-critical systems may have extended recovery windows.

5. Recovery Strategies

XBert employs a microservices architecture where each component is independently managed and can be restored individually. Recovery strategies are layered to address different failure scenarios:

• Component failure: Individual services are restarted or redeployed from source control. Azure PaaS automatically handles underlying infrastructure recovery.
• Data corruption: Database point-in-time recovery (PITR) restores data to any point within the retention window, allowing precise recovery to a moment before corruption occurred.
• Regional outage: Geo-replicated databases and geo-redundant storage in a secondary Azure region enable failover to the disaster recovery site.
• Complete redeployment: All application source code is permanently stored in GitHub Enterprise (private repositories), enabling rapid redeployment of the full platform from scratch if required.

6. High Availability & Redundancy

6.1 Azure Platform Resilience

• Primary region: Australia Southeast (Melbourne)
• DR region: Australia East (Sydney)
• All critical services are deployed across multiple Azure Availability Zones within the primary region, protecting against data centre failures
• Azure PaaS services provide built-in load balancing and automatic failover within the region

6.2 Database Redundancy

• Azure SQL databases use geo-replication to Australia East, providing a continuously synchronised read replica
• In the event of a primary region failure, the replica can be promoted to primary with minimal data loss

6.3 Storage Redundancy

• Azure Blob Storage is configured with Geo-Redundant Storage (GRS), replicating data asynchronously to the secondary region
• This ensures file and blob data survives a complete regional outage

6.4 Secrets and Certificates

• Azure Key Vault is configured with geo-redundancy, ensuring secrets, keys, and certificates remain accessible during regional failover

6.5 Third-Party Service Resilience

Third-party services used by XBert (Auth0, Chargebee, Stripe) maintain their own high availability and disaster recovery programmes with published SLAs. XBert monitors these services and maintains contingency procedures for third-party outages.

6.6 Threat Detection

Azure Defender provides continuous threat detection across all production resources, enabling early identification of security events that could impact availability.

7. Data Backup & Restore

Backup Type	Scope	Retention	Method	Recovery Method
Database PITR	All Azure SQL databases	28 days	Automated continuous backups (Azure-managed)	Restore to any point in time within the retention window
Database long-term retention	All Azure SQL databases	12 months	Automated weekly full backups to long-term storage	Restore from long-term backup store
Database geo-replica	All Azure SQL databases	Continuous	Real-time geo-replication to Australia East	Promote replica to primary
Blob Storage	All Azure Blob Storage accounts	Continuous	Geo-Redundant Storage (GRS) with asynchronous replication	Failover to secondary region
Key Vault	Secrets, keys, and certificates	Continuous	Geo-redundant Azure Key Vault	Automatic failover to secondary region
Source code	All application repositories	Permanent	GitHub Enterprise (private repositories)	Clone and redeploy from any commit
CI/CD pipelines	Build and release definitions	28 days	Azure DevOps with point-in-time recovery for pipeline metadata	Restore pipeline configuration from backup

8. Disaster Recovery Plan

8.1 Activation Criteria

The DR plan is activated when any of the following occurs:

• A complete Azure regional outage affecting the primary region (Australia Southeast)
• Prolonged service disruption exceeding one hour with no estimated resolution
• Data corruption affecting production databases that cannot be resolved through standard operational procedures
• A security incident requiring system isolation and rebuilding
• CTO or Development Manager declares a disaster based on impact assessment

8.2 Notification Procedures

Upon activation of the DR plan:

1. Internal notification: CTO and Development Manager are notified immediately via Slack
2. Team mobilisation: Relevant technical staff are assembled via Slack and email
3. Customer communication: Status updates are published via Intercom and email, including estimated recovery timelines
4. Ongoing updates: Regular status updates are provided at minimum 2-hour intervals until resolution

8.3 Recovery Steps

The following sequence is followed to restore services:

1. Assessment: Determine the scope and nature of the disruption, identify affected components
2. Database recovery: Restore Azure SQL databases from geo-replica or PITR backups as appropriate
3. Storage recovery: Initiate failover for Azure Blob Storage if the primary region is unavailable
4. Application redeployment: Redeploy application services from GitHub Enterprise source code via CI/CD pipelines, targeting the DR region if required
5. Configuration restoration: Restore secrets and configuration from geo-redundant Azure Key Vault
6. Integration verification: Validate connectivity to third-party services (Auth0, Chargebee, accounting platform APIs)
7. Data integrity checks: Verify data consistency across restored databases and storage
8. Service validation: Execute smoke tests and health checks to confirm correct operation
9. Traffic cutover: Update DNS and routing to direct users to recovered services
10. Post-recovery monitoring: Intensified monitoring for 48 hours following recovery

9. Testing & Maintenance

9.1 DR Testing

• Annual DR exercises are conducted to validate the effectiveness of recovery procedures
• Test scenarios include database restore from PITR, failover to geo-replica, and full application redeployment
• Test results are documented, and any gaps or failures are addressed with corrective actions

9.2 Plan Maintenance

• The BCP/DR plan is reviewed annually or following any of these triggers:
  • Significant changes to infrastructure or architecture
  • A real disaster or near-miss incident
  • Changes to regulatory or compliance requirements
  • Addition of new critical applications or third-party dependencies
• All changes are version-controlled and communicated to relevant stakeholders

10. Roles & Responsibilities

Role	Responsibility
CTO	Overall ownership of BCP/DR strategy; declares disaster activation; approves recovery decisions; oversees communication to stakeholders
Development Manager	Leads technical execution of recovery procedures; coordinates team response; manages CI/CD redeployment
Database Administrators	Execute database backup and restore operations; validate data integrity post-recovery; manage geo-replication and PITR
Development Team	Assist with application redeployment; execute integration and smoke testing; support recovery validation
All Staff	Follow incident communication procedures; report disruptions promptly

11. Compliance

This business continuity and disaster recovery plan supports compliance with:

• Privacy Act 1988 (Cth) - APP 11 (security of personal information), ensuring availability as a component of information security
• ISO 22301 alignment - Business continuity management systems, providing a structured framework for BCP/DR
• ISO 27001 Annex A.17 - Information security aspects of business continuity management
• Azure compliance certifications (ISO 20000-1:2011, CSA STAR, SOC 2)

12. Change History

Version	Date	Changes
1.0	April 2026	Initial creation