Service Continuity and Disaster Recovery Strategy

Summary

Every platform in BeeTcore’s care has a service tier and defined recovery objectives, backed by recovery infrastructure held independently of its hosting. When a disruption threatens those objectives, a defined recovery team restores service to an alternative environment and keeps clients informed until it is resolved. The strategy is aligned to the principles of ISO 27001 and tested at planned intervals.

1. Scope

This strategy covers every client platform BeeTcore hosts, maintains, or supports, across content management platforms and custom applications, as well as BeeTcore’s own operations. The controls for each platform follow its stack and project agreement, as set out in the Development Methodology SOP.

2. Risk assessment and business impact analysis

Risks to service are assessed at onboarding and reviewed regularly. Each assessment identifies potential threats, the platform’s critical dependencies, and the business impact of downtime. The results set the platform’s service tier and recovery objectives.

3. Service tiers and recovery objectives

Each platform is assigned a tier based on its criticality to the client’s operations:

• Tier 1. Critical: revenue-generating or mission-critical platforms, such as commerce, donation, and active learning platforms, and business-critical applications.
• Tier 2. Important: platforms where downtime affects credibility and lead flow, such as corporate and marketing websites.
• Tier 3. Supporting: platforms where downtime is tolerable for longer, such as staging environments, internal tools, and archived sites.

A Recovery Time Objective (RTO) and a Recovery Point Objective (RPO) are established for each platform, according to its tier, and confirmed in its project agreement. The RTO is the target time to restore service. The RPO is the maximum acceptable data loss. Recovery follows tier priority, with Tier 1 platforms restored first.

4. Resilience and redundancy

• Independent backups, held separately from the production host. Frequency, retention, and verification are set out in the Backup and Recovery Standards.
• Multiple hosting providers, so a platform can be restored elsewhere instead of waiting on a failed provider.
• Independent DNS, so traffic can be redirected without the affected provider’s involvement.
• Cloudflare edge protection in front of platforms, absorbing attacks and reducing load on the origin server.
• Data replication between primary and secondary systems for custom applications, where agreed.
• Rebuildable environments for custom applications, with code in version control.

5. Disaster declaration and recovery

An incident, handled under the Incident Management Response Strategy, becomes a declared disaster when recovery in place will not meet the RTO, when a provider failure affects several platforms at once, or when data integrity cannot be confirmed. The Senior Delivery Lead declares it and activates a recovery team: a recovery lead, a technical lead, and the project manager for each affected client.

1. Confirm the scope and cause, and check the provider’s status.
2. Provision an alternative environment.
3. Restore the latest verified backup, Tier 1 first.
4. Verify function, data, integrations, and payments.
5. Redirect DNS, confirm with the client, and monitor.
6. Close the event and complete a written review.

6. Client communication

Clients are notified within the response times set out in the Incident Management Response Strategy. Each update covers what is known, what is being done, and when the next update will come. A written summary follows every declared disaster.

7. BeeTcore’s own continuity

BeeTcore runs on cloud-based tools, with credentials held in an approved team password manager and every engagement documented in its project workspace. Work continues without depending on any single device, location, or team member.

8. Testing, documentation, and review

The recovery plan is tested regularly, at planned intervals, through restores into isolated environments and simulated disaster exercises. Procedures, responsibilities, and contact details are documented and kept current. Findings from tests and real events feed into Continuous Service Improvement. This strategy is reviewed annually and after every declared disaster.

Frequently asked questions