Security
Business Continuity & Disaster Recovery Plan
Version 1.0 · Last updated 7 July 2026 · Next review July 2027
This plan describes how LeakIQ Ltd (company number 17311148) maintains availability of the LeakIQ platform and recovers service and data in the event of a disruption. It complements the Incident Response Plan and the Service Level Agreement in the Master Subscription Agreement.
1. Purpose and scope
The purpose of this plan is to ensure LeakIQ can continue to operate, and can restore service and customer data within defined objectives, following an event that disrupts normal operations. It covers the LeakIQ application, its database, and the customer data LeakIQ processes.
LeakIQ is a cloud-native, serverless application with no on-premises infrastructure. This significantly reduces the range of continuity risks: there are no physical offices, servers or data centres owned by LeakIQ that could be lost.
2. Recovery objectives
LeakIQ maintains the following targets. These are objectives, measured and reviewed, not contractual guarantees except where set out in the SLA.
| Objective | Target | How it is met |
|---|---|---|
| Availability | 99.5% monthly (per SLA) | Serverless, auto-scaling compute with a managed, highly-available database |
| Recovery Point Objective (RPO) | ≤ 1 hour | Continuous / point-in-time database backup, at most a small window of recent writes is at risk |
| Recovery Time Objective (RTO) | ≤ 8 business hours (critical restore) | Stateless application redeploys in minutes; database restored from managed backup or point-in-time recovery |
3. Architectural resilience
Continuity is built into the architecture rather than bolted on:
- Stateless compute. The application runs as ephemeral serverless functions on Vercel. There is no persistent server to fail or rebuild, a new deployment can be brought up in minutes, and compute scales automatically with demand.
- Managed, resilient database. Data is held in Neon PostgreSQL (EU, AWS eu-west-1, Ireland), a managed service with built-in redundancy, automated backups and point-in-time recovery.
- No single point of custody for secrets. Connector credentials are encrypted (AES-256-GCM) and the encryption key is held separately from the database, so a database restore does not expose plaintext credentials.
- Tamper-evident state. The append-only, hash-chained audit log provides an authoritative record used to verify data integrity after any restore.
4. Backups and restore testing
LeakIQ relies on Neon's automated database backups and point-in-time recovery, and adds its own assurance layer on top:
- Automated backups are taken continuously by the managed database platform, enabling point-in-time recovery to a chosen moment within the retention window.
- LeakIQ runs backup integrity validation to confirm backups are complete and consistent, and runs periodic restore tests to confirm data can actually be recovered, not just that a backup file exists.
- Backup and restore-test health is monitored and surfaced to workspace administrators in the Command Centre (Backup & Recovery), so a degraded backup state is visible, not silent.
- All backups are encrypted at rest and are held within the EU.
5. Failure scenarios
| Scenario | Response |
|---|---|
| Application / deployment failure | Roll back to the last known-good deployment or redeploy; stateless compute means no data is involved and recovery is typically minutes. |
| Database corruption or accidental data loss | Restore from managed backup or point-in-time recovery to just before the event; verify integrity against the audit log. |
| Cloud region outage | We redeploy the application to a healthy region; database recovery follows the managed provider's regional resilience, with restore into an alternate region if required. |
| Credential compromise | Rotate the affected connector credentials and the encryption secret; invalidate sessions. Handled under the Incident Response Plan. |
| Sub-processor outage (Vercel / Neon / Resend / Stripe) | Monitor the provider's status, follow their recovery, and keep affected customers informed. Email delivery and billing degrade gracefully without affecting stored data. |
6. Invocation and roles
A continuity or disaster event is declared and managed under the same command structure as a security incident (see the Incident Response Plan). The Incident Lead declares the event, coordinates recovery, and owns communication to affected customers. Recovery steps follow the documented operational recovery process; progress and decisions are recorded on the incident timeline.
7. Testing and review
- This plan is reviewed and updated at least annually, and after any invocation. Next scheduled review: July 2027.
- Restore capability is tested periodically via automated restore validation, and continuity is exercised alongside the annual incident-response tabletop.
- Recovery objectives are reviewed against actual recovery performance and adjusted where needed.