Business Continuity & Disaster Recovery (BC/DR) Policy

Reviewed: 29 January 2026


At a glance

  • We plan for disruption to continue critical services, protect people and meet legal/contractual obligations.
  • We maintain business continuity plans (BCPs) and IT disaster recovery (DR) runbooks with defined RTOs and RPOs.
  • We use redundant cloud infrastructure, encrypted backups, and alternate operational procedures for mail handling.
  • We test continuity and recovery at least annually, record outcomes and improve.

Purpose

This Policy defines how UK Postbox prepares for, responds to and recovers from disruptive incidents to safeguard people, assets and operations, meet UK GDPR obligations (security of processing, Art. 32), contractual commitments, and good practice (e.g., ISO 22301 principles, NCSC guidance).


Scope

  • Business services: customer onboarding (KYC), digital mailbox intake/open/scan/present, forwarding/shipping, billing/payments, customer support, Trust Centre and status pages.
  • Technology: production applications/APIs, databases, storage/object stores for digital scans, networking, identity/SSO, email and support tools.
  • Operations: mailroom facilities, receipt/chain‑of‑custody, scanning equipment, secure destruction, physical security and logistics.
  • Suppliers: cloud platforms, KYC/biometric providers, payment processors, carriers, support tooling, sub‑processors.

Objectives

  • Protect life and safety first.
  • Maintain or restore critical services within agreed Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
  • Preserve integrity and confidentiality of data during disruption; avoid data loss beyond RPO.
  • Meet regulatory and contractual notification and service obligations.
  • Communicate clearly with customers, staff and partners.

Governance & roles

  • BC/DR Sponsor (Executive): approves strategy, resources and risk appetite.
  • BC Manager (owner): maintains BCPs, coordinates tests and training, oversees business impact analysis (BIA), maintains the BC/DR Register.
  • IT DR Lead: owns DR runbooks, backups, infrastructure resilience and failover.
  • Security Lead & DPO: align BC/DR with Incident Response & Breach Notification Policy and data protection requirements.
  • Mailroom Operations Lead: maintains alternate workflows/sites and supplier liaison for continuity of physical handling.
  • Comms Lead: manages internal/external communications and status page updates.
  • All managers: keep team‑level procedures current and ensure staff are trained.

Business Impact Analysis (BIA)

We maintain a BIA identifying critical processes, dependencies, peak periods and tolerances for downtime and data loss. The BIA sets priority tiers and target recovery metrics.


Critical process tiers & targets (current standards)

Process / system

Tier

Target RTO

Target RPO

Customer login & mailbox view/download 1 4 hours 15 minutes
Mail intake, registration & basic metadata 1 24 hours 2 hour
Scanning/OCR & image delivery 2 24 hours 2 hour
Forwarding/shipping instruction processing 2 24 hours 2 hours
Payments & billing 2 24 hours 24 hours
KYC/Onboarding 3 48 hours 24 hours
Customer support/ticketing 2 24 hours 2 hours
Reporting/analytics 3 72 hours 24 hours

Targets are reviewed at least annually. Contractual SLAs may specify stricter values for enterprise customers. These targets represent standard service levels; during major incidents affecting multiple customers or third-party dependencies, actual recovery times may exceed targets.


Continuity strategies

Technology & cloud

  • Geographic redundancy: services deployed across multiple availability zones within a region; stateless services can scale horizontally. Critical data is replicated to a secondary region for disaster recovery.
  • Data resilience: databases use replication and point‑in‑time recovery; object storage for scans uses provider multi‑AZ durability.
  • Backups: encrypted backups (see §8) retained per the Data Retention & Deletion Policy; restore tests performed periodically.
  • Identity & access: SSO with break‑glass accounts (stored in a secure vault) and documented manual access procedures.
  • Change freeze: during severe incidents we may freeze releases and enable feature flags to reduce risk.

Mailroom & logistics

  • Alternate workflows: if scanning is degraded, we may switch to envelope‑only imaging and queue full‑content scans for later.
  • Secondary site or capacity: arrangements maintained to relocate or extend operations (e.g., contracted overflow provider or mobile scanning capability). Secondary site or overflow arrangements can be activated within 24–48 hours of a primary facility becoming unavailable.
  • Carrier continuity: maintain multiple approved carriers and pre‑agreed account structures for rapid switchover.
  • Chain‑of‑custody: paper logs are available where systems are offline; later entered into the platform.
  • Secure storage & destruction: capacity plans ensure secure retention if forwarding is delayed; destruction follows BS EN 15713.

People & facilities

  • Alternate work locations: remote work capability for non‑mailroom roles and VPN/zero‑trust access.
  • Staffing: cross‑training for key roles; on‑call rosters; temporary labour agency arrangements for surge/absence scenarios.
  • Health & safety: PPE and safe‑working guidance; pandemic playbooks (reduced staffing, distancing, cohorting, mail quarantine if mandated). Pandemic playbooks are reviewed annually and updated based on lessons learned and evolving public health guidance.

Disaster Recovery (DR) runbooks

  • Service‑specific runbooks define failover/restore steps, owners, prerequisites and verification checks.
  • Priority order: identity/SSO → database/platform core → storage/object access → application layer → scanning pipelines → auxiliary services.
  • Data validation: integrity checks (hash/row counts), application smoke tests and mail image sampling before announcing recovery.
  • Rollback: documented criteria for rollback vs. continue; backups/images preserved for forensics. DR runbooks are reviewed quarterly for accuracy and tested at least annually; any changes to systems require corresponding runbook updates within 30 days.

Backups & recovery

  • Scope: databases, object/file stores (scans, KYC artefacts), application configs and infrastructure state.
  • Encryption: backups encrypted in transit and at rest; keys managed via KMS/HSM.
  • Frequency: near real‑time replication/point‑in‑time where supported; otherwise nightly.
  • Storage: separate accounts/regions where appropriate; access is least privilege and audited. Critical backups are stored in immutable storage (write-once, read-many) for a minimum retention period to protect against ransomware and malicious deletion.
  • Testing: quarterly restore tests including at least one full system restore annually (not just representative datasets); lessons captured in the DR log.
  • Backup retention: aligns to the Data Retention & Deletion Policy; purge via rotation; no direct erasure from media—expiry by rotation.

Incident linkage & notifications

  • Security events and personal data breaches are handled under the Incident Response & Breach Notification Policy.
  • Where incidents may affect availability or data integrity (e.g., ransomware), the IRT leads; BC/DR supports failover and recovery. Ransomware scenarios have dedicated playbooks covering isolation, backup integrity verification, and recovery sequencing.
  • Regulatory/customer notifications are coordinated by the DPO/Comms per legal and contractual obligations (e.g., ICO within 72h where required).

Communications

  • Status page: used for public service updates during major incidents.
  • Customer comms: in‑app messages for incident notices, workarounds and recovery confirmation.
  • Internal comms: incident channels and briefings; single source of truth maintained by Comms Lead.
  • Media/press: enquiries handled by authorised spokespersons only.

Supplier continuity

  • Sub‑processors and critical suppliers must maintain appropriate BC/DR capabilities and notify incidents without undue delay per contracts.
  • We maintain a dual‑supplier or fallback approach for key functions where feasible (e.g., carriers, KYC, hosting regions). We monitor supplier concentration risk and avoid single points of failure for critical functions where economically practical.
  • Supplier risk is tracked in the Supplier Register with continuity evidence (e.g., certifications, summaries of test results) reviewed annually.

Testing & exercises

  • Table‑top exercises at least annually, covering cyber, cloud outage, carrier disruption and facility unavailability.
  • Technical failover tests for priority systems (identity, databases, storage, scanning pipeline) at least annually; partial component tests more frequently.
  • Mailroom drills: evacuation, alternate workflow execution, and chain‑of‑custody continuity.
  • Every test has a plan, success criteria, report and action tracker. All exercises conclude with a documented lessons-learned session; action items are tracked to completion within 60 days.

Records & metrics

We maintain a BC/DR Register including plans, runbooks, test schedules, results and action logs. Metrics include: time to invoke, time to failover, time to restore to RTO, RPO attainment, customer communication timeliness (target: initial communication within 30 minutes of major incident declaration; updates at least hourly thereafter), and open actions. Reports go to the Executive Sponsor and Security/DPO quarterly.


Data protection & compliance

  • During continuity operations we maintain confidentiality, integrity and availability controls (e.g., encrypted media, access logging, secure transport).
  • We prefer read‑only access for recovery validation and avoid using production data in non‑production recovery unless protected equivalently.
  • Any data transfers outside normal boundaries during incidents are documented and approved by the DPO/Security and covered by appropriate safeguards (e.g., IDTA/UK Addendum to SCCs) where applicable. UK Postbox maintains cyber insurance covering business interruption, incident response costs, and third-party liabilities; policy limits and coverage are reviewed annually.

Plan maintenance & distribution

  • BCPs and DR runbooks are stored in a version‑controlled repository with offline copies for site leads.
  • Contact lists (on‑call, executives, suppliers) are kept current and tested quarterly.
  • Staff receive role‑specific training and know where to access procedures during an incident.

UK Postbox Limited

13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, Dorset, BH16 6FH, United Kingdom


Support: support@ukpostbox.com

Security: security@ukpostbox.com

Legal notices: legal@ukpostbox.com

Data protection: dpo@ukpostbox.com

Complaints: complaints@ukpostbox.com

Accessibility: accessibility@ukpostbox.com

Website: www.ukpostbox.com


Registered in England and Wales Company Number: 06723381

MLR registration no: XLML00000192390

ICO registration no: ZA038907