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.

5.1 Critical process tiers & targets (current standards)

We categorise business processes and systems into three recovery tiers based on criticality, customer impact and regulatory obligation. Recovery resources and sequencing are prioritised accordingly.

Detailed recovery time and recovery point objectives for each process are documented in the Business Impact Analysis (BIA), which is maintained internally and reviewed at least annually by the BC/DR Sponsor.

These tier classifications represent internal planning priorities and do not constitute service level commitments unless expressly agreed in writing with a customer. During major incidents involving multiple concurrent failures or third-party dependencies, recovery sequencing may be adjusted at the discretion of the BC Manager and IT DR Lead.

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