• Applies to environments we host or operate, and the internal systems we use to deliver services.
• Goals: maintain core functions, meet recovery targets, protect data, and communicate clearly.
• Client-owned platforms follow this as a minimum alongside client policies.

Stricter targets can be set in the SoW or SLA for specific clients.

• Platform outage: host or region down, storage failure.
• Data corruption: faulty deploy, bad migration, operator error.
• Security event: compromised key, malicious activity (handled with IR plan).
• Third-party failure: API/rate limits, SaaS outage.
• People outage: illness or loss of access for key staff.
• Office/network loss: ISP failure, local power issue (we work remote-first).

• Documented runbooks for critical workflows and environments.
• Role coverage: at least two engineers can operate each client environment.
• Access: break-glass credentials held in a vault with audit and rotation.
• Dependency mapping: upstream APIs and limits noted in project docs.
• Traffic control: disable or queue non-essential jobs during incidents.
• Comms: client updates via the agreed channel (email/Slack/Ticket).

1. Declare & lead: Incident Manager sets severity and opens the log.
2. Stabilise: pause high-risk workflows; apply temporary blocks; protect evidence.
3. Select point-in-time: choose restore point based on RPO and known-good checksums.
4. Restore to staging: recover DB and files; validate core jobs and webhooks.
5. Promote: switch DNS/endpoint or promote the restored node. Monitor closely.
6. Reconcile: replay or re-queue failed runs if safe; document exceptions.
7. Review: post-incident notes, follow-ups, and client summary.

Detailed steps live in the private runbooks for each environment.

• Key providers are listed at /sub-processors.
• We track provider status pages and advisories.
• If a provider is the root cause, we communicate status and workarounds.

• Backups: restore test twice a year per hosted environment.
• Failover drill: yearly table-top, plus at least one live switch in a low-risk window if supported.
• People: access reviews every 90 days; verify a second engineer can operate the stack.
• Actions from tests are tracked to closure.

• Status updates at start, containment, restore, and closure.
• Channel: email or shared Slack/Teams; subject lines include severity and system.
• Templates from the Incident Response policy are used for client notices.

• Keep incident logs, timelines, and restore outputs for at least 12 months (longer where contract requires).
• Store evidence with restricted access and audit trail.

• Review this plan yearly, after major platform changes, or after P1/P2 incidents.
• Project-specific targets (RTO/RPO) live in the SoW or SLA and are kept in step with this plan.

Questions about continuity or a DR request?

Technophobia Ltd · Company No. 14898332 · VAT GB 495 7043 58
13B Devonshire Road Industrial Estate, Millom, LA18 4JS, United Kingdom
+44 1229 774591 • hello@technophobia.uk