Mailbuttons runs critical email infrastructure for its customers, so we plan deliberately for disruption and data loss. This policy sets out our recovery objectives, backup regime and disaster recovery approach.

# Purpose and scope

This policy defines how Code Cutter Limited (trading as Mailbuttons) maintains service continuity and recovers from disruptive incidents affecting production systems and data. It covers our Stalwart email cluster, PostgreSQL database, RustFS object storage, application services and supporting infrastructure. It aligns with ISO/IEC 27001:2022 Annex A controls 5.29 and 5.30 (information security during disruption and ICT readiness for continuity), 8.13 (information backup) and 8.14 (redundancy of processing facilities).

# Policy

Recovery objectives. We set the following targets, sized realistically for a small, founder-led SaaS:

• Recovery Point Objective (RPO): ≤ 24 hours. Daily backups mean that, in a worst case, we may lose up to one day of data.
• Recovery Time Objective (RTO): hours to one business day for full service restoration, depending on scenario severity.

These are objectives, not guarantees, and are reviewed as the platform grows.

Backup regime. We take daily logical dumps of PostgreSQL and retain them for 30 days. Backups are replicated off-site to Backblaze (EU region, Amsterdam) and are encrypted client-side with a key we control before leaving our infrastructure, so the storage provider never holds plaintext. We verify that backup jobs complete and alert on failure.

Master key criticality. A critical master key, the LLM key encryption key, protects stored customer secrets. If this key is lost, those secrets become unrecoverable even with database backups. The key is therefore backed up securely off-box, separately from the data it protects, and its safe custody is treated as essential to disaster recovery. Confirming the key backup is part of every restore test.

Filesystem-level disaster recovery. Our VPS hosting provider, Fasthosts, does not offer provider-level server snapshots. Our disaster recovery is therefore a deliberate, filesystem-level rebuild: we provision a fresh host, install and configure services from our documented build, and restore data from the off-site backups. We do not rely on any snapshot-and-roll-back capability.

Restore testing. We periodically perform end-to-end restore tests — at least quarterly — restoring backups to a clean environment, confirming data integrity, and exercising the master-key restore step. A backup is only considered valid once a restore from it has succeeded.

Recovery scenarios. We plan for:

• Host loss — rebuild on a new Fasthosts host from documented configuration and restore data.
• Data corruption — restore the most recent clean backup within the 30-day window.
• Supplier outage — degrade gracefully, communicate with customers, and resume when the supplier recovers; for backup storage, retain the ability to restore from local copies.
• Region or provider issue — rebuild in an alternative location using off-site backups held with an independent provider.

Customer communication during a major outage. During a significant outage, the ISMS Owner provides timely status updates through our published channels, with a plain account of impact, expected recovery and any data implications. We confirm resolution and, where warranted, publish a follow-up on the Trust Center, coordinated with the Incident Response Policy.

# Responsibilities

The ISMS Owner is accountable for continuity and recovery planning, ensures backups run and are tested, safeguards the master key, leads recovery during a disaster, and owns customer communications. Suppliers are relied upon for the resilience of the services they provide, as recorded in the Supplier Security Policy.

# Review

This policy is reviewed at least annually and after any material change, and is approved by the ISMS Owner.

Related: Incident Response Policy, Supplier Security Policy, Physical and Environmental Security Policy