# Business Continuity & Disaster Recovery Plan

**SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999)**
Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: annually, and after any restore test or major incident

## 1. Purpose and scope

This plan defines how SyncMate continues or restores service after a disruptive event: loss of hosting infrastructure, database corruption or loss, prolonged third-party outage, or unavailability of key personnel. It covers the whole platform — the web application (Cloudflare Workers), the Postgres database and object storage (Supabase on AWS, Asia-Pacific/Sydney), authentication, and the extraction pipeline.

## 2. Recovery objectives

| Metric | Target |
|---|---|
| Recovery Point Objective (RPO) | 24 hours — no more than the last 24 hours of transactions at risk |
| Recovery Time Objective (RTO) — full platform | 1 business day |
| RTO — degraded service (read-only access to existing documents and reports) | 4 business hours |

## 3. Backup arrangements

| Layer | Mechanism | Retention |
|---|---|---|
| Database (Supabase Postgres) | Provider-managed daily physical backups plus continuous write-ahead log (WAL) archiving | 7 days, point-in-time recovery within the window |
| Object storage (uploaded receipts, invoices, statements) | Stored on durable object storage (AWS S3-class, 99.999999999% design durability); files are content-addressed and never overwritten in place | For the life of the customer account |
| Application code | Git repository with the full deployment history; every deploy is reproducible from source | Indefinite |
| Configuration and secrets | Platform-managed environment configuration; secrets are also held in the credential escrow described in section 6 | Indefinite |

Backups are encrypted at rest by the hosting provider. SyncMate does not maintain separate off-platform copies; durability relies on the provider arrangements above, which is why the restore test in section 5 is performed and recorded.

## 4. Failure scenarios and response

| Scenario | Response |
|---|---|
| Application deploy failure / bad release | Roll back to the previous deploy from version control; typical recovery under 15 minutes. Migrations are backward-compatible where possible so rollback does not strand data. |
| Database corruption or operator error | Point-in-time recovery to just before the event using WAL archives, within the 7-day window. |
| Loss of the primary hosting region | Re-deploy the application from source to a healthy region and restore the database from the latest backup snapshot. Target: within RTO of 1 business day. |
| Prolonged third-party outage (Xero, AI extraction provider) | SyncMate queues outbound work and retries; inbound uploads continue to be accepted and are processed when the dependency recovers. Customers are notified per the incident-notification commitments in the SLA (A1). |
| Unavailability of the Founder/Technical Operator | Key-person succession per section 6. |

## 5. Backup verification and restore testing

A documented restore test is performed at least annually, and additionally after any material change to the database layer:

1. Select the most recent automated backup.
2. Restore it into an isolated environment that is separate from production.
3. Verify, and record: the restore completes; table counts match production within the expected delta for the snapshot time; a sample of recently created records (documents, ledger entries, user accounts) is present and readable; a sample uploaded file downloads and opens correctly.
4. Record the date, the operator, the backup used, the checks performed, and the result in the test log. Failures are raised in the Risk Register (A4) and treated under the Vulnerability Management Policy (A6) where applicable.

The restore test log is retained as evidence and is available to customers and auditors on request.

## 6. Key-person succession

SyncMate is currently operated by a single Founder/Technical Operator. To ensure continuity if that person becomes unavailable:

- **Credential escrow.** A sealed, access-controlled escrow holds the credentials and recovery codes needed to administer the hosting, database, domain, DNS, payment and source-control accounts. Access to the escrow is held by a nominated successor under a documented handover procedure.
- **Runbook.** A maintained handover runbook describes the architecture, the deployment process, the routine operational tasks (backups, monitoring, incident response), and the location of all administrative accounts.
- **Data protection.** Customers' financial data is not included in the escrow; the successor gains access only to the administrative systems needed to operate the service, and that access is logged.
- **Review.** The escrow contents and runbook are verified at least annually and updated whenever a material system or account changes.

## 7. Communication during a disaster

- Customers are notified of any P1 incident (including invocation of this plan) within 48 hours, with impact, remediation steps, and recovery progress, per the SLA (A1).
- If the event involves a data breach, the notification and OAIC obligations in the Privacy Policy and the Exit & Data Destruction policy (A10) apply.

## 8. Review and maintenance

This plan is reviewed annually, after any invocation, and after any restore test. Changes are versioned and published in the Policy Library with an effective date.