Business Continuity & Disaster Recovery Plan

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.

LeakIQ maintains the following targets. These are objectives, measured and reviewed, not contractual guarantees except where set out in the SLA.

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-central-1, Frankfurt), 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.

LeakIQ relies on Neon's automated database backups and point-in-time recovery:

• Automated backups are taken continuously by the managed database platform, enabling point-in-time recovery to any chosen moment within the last 7 days.
• Those are two different windows and both matter: the Recovery Point Objective above is how much recent work could be lost in a failure, at most one hour. The 7 day window is how far back a recovery can reach, which is what applies when a problem is noticed some days after it happened.
• An independent restore test of the production database was carried out on 7 October 2026. A point-in-time copy was recovered to 11:00 UTC that day and verified: 76 of 76 tables present, 466,229 rows, no table holding fewer records than production held at that moment, and the tamper-evident audit hash chain recomputed end to end across 428,872 records in both workspaces, every hash matching and every record following its predecessor. Recovery took approximately two minutes, against the 8 business hour objective in section 3. The verified copy was deleted immediately afterwards, because it is a full unsanitised copy of production.
• What that test does and does not cover, stated plainly: it proves the database can be recovered to a chosen moment and that its contents are intact and internally verifiable. It does not exercise a full application failover, and it recovers within the managed platform rather than rebuilding from a backup file into a fresh project. A single test is also not a programme of periodic restore testing, and we do not claim one.
• All backups are encrypted at rest and are held within the EU.

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.

• This plan is reviewed and updated at least annually, and after any invocation. Next scheduled review: July 2027.
• An independent restore test of the production database was carried out on 7 October 2026, with the measured result recorded in section 4. It is not yet a recurring programme, and this page does not claim periodic restore testing. The next test is due alongside the annual review.
• Recovery objectives are reviewed against actual recovery performance and adjusted where needed.