Service
Disaster Recovery & Resilience
Build a recovery path that has actually been exercised, with recovery targets you can put in front of an auditor or a client.
Nearly every organisation has a disaster recovery document. Far fewer have a recovery path anyone has run. The gap between the two is only discovered on the worst possible day.
What we look at
- Which services genuinely need what recovery targets — most documents apply one tier to everything, which is both expensive and unhelpful
- Backup coverage and, more importantly, whether restores have been tested
- Dependencies that break a failover: DNS, secrets, third-party services, certificate renewal
- Data replication strategy and the consistency guarantees it actually provides
- Who is authorised to declare an incident and start a failover
What you get
Recovery targets defined per service and measured against a real exercise rather than estimated. Automated failover where it is warranted, and an honest recommendation to stay manual where automation would add more risk than it removes. Runbooks written for someone half-awake. And a documented test result you can hand to an auditor, a client’s security review, or an insurer.
Why this gets deferred
Because nothing breaks while you ignore it. It usually surfaces as a procurement blocker — an enterprise client asks for evidence of tested recovery and there is none. Worth doing before that conversation rather than during it.