Business Continuity

Business Continuity & Disaster Recovery

How we keep delivering, and how hosted services are restored, when things go wrong.

Trust & Compliance Centre · Last reviewed: July 2025

At a glance

Do you have a Business Continuity Plan (BCP) or Disaster Recovery Plan (DRP)? Yes Both are maintained; summary below, full runbooks available under NDA
What is your Recovery Time Objective (RTO) for critical services? 24–48 hours for critical hosted services; tighter targets can be architected and agreed per engagement

Recovery objectives

For critical hosted services our standard Recovery Time Objective (RTO) is 24–48 hours — the time to restore service after a major disruption. The Recovery Point Objective (RPO) — the maximum data loss window — is driven by backup configuration and is agreed per engagement; Azure database services provide automated backups with point-in-time restore as standard.

Where a customer needs tighter objectives (for example, zone-redundant or multi-region deployment with near-zero RTO), these are architected into the solution and the associated targets recorded in the engagement documentation, consistent with our Master Services Agreement.

Disaster recovery for hosted services

Recovery of hosted services is built on Azure platform capabilities:

  • Automated backups — databases and storage use Azure's automated backup services, with geo-redundant storage available so backups survive the loss of a data centre or region.
  • Infrastructure as code and CI/CD — environments are redeployable from version-controlled definitions and pipelines, so infrastructure can be rebuilt in a paired region (UK West for UK South workloads) rather than reconstructed by hand.
  • Source code resilience — all source is held in hosted, replicated version control, independent of the runtime environment.
  • Regional pairing — Azure's UK South / UK West region pair keeps recovery within the UK (see Hosting & Data Residency).

Recovery procedures are documented per solution and validated through the same deployment pipelines used for routine releases — meaning the recovery path is exercised continuously, not just in an annual test.

Business continuity

Beyond hosted infrastructure, our continuity planning covers the ability of the business itself to keep operating:

  • Location independence — we operate as a distributed, remote-capable team; loss of any single office or location does not interrupt delivery.
  • Cloud-based tooling — communication, source control, project management, and delivery tooling are all cloud-hosted with their own provider resilience.
  • Key-person cover — engagement knowledge is captured in documentation, version control history, and runbooks rather than held by a single individual.
  • Supplier failure — dependencies on third-party services are identified per engagement, with substitution or recovery options noted (see Third-Party Supplier Management).

Runbooks available on request

Full BCP/DRP runbooks describe internal infrastructure and recovery steps in detail, so they are shared under NDA rather than published. Request via hello@assemblysoft.com.

Back to the Trust & Compliance Centre

Start a meaningful conversation with us today.

FAQs

Assemblysoft are Your Safe Pair of Hands

Microsoft Azure

Azure

Azure DevOps

Azure DevOps

Blazor

Blazor