# Business Continuity & Disaster Recovery Plan

**Company:** [Company Name]
**Effective date:** [Date]
**Plan owner:** [Owner / Role]

## Purpose & Scope

This plan describes how [Company Name] keeps essential operations running during a disruption and how it recovers systems and data afterward. A disruption could be an outage, a cyber incident, a failed supplier, a natural event, or loss of a facility.

It covers the critical systems, people, and processes the business depends on. It does not try to cover every minor hiccup — it focuses on what would seriously hurt the business if unavailable.

## Key Definitions

- **RTO (Recovery Time Objective):** The target time to get a system or process working again after it goes down. Example: an RTO of 4 hours means we aim to restore it within 4 hours.
- **RPO (Recovery Point Objective):** The most data, measured in time, we can afford to lose. An RPO of 1 hour means backups/replication must be recent enough that we lose at most one hour of data.

Shorter RTO/RPO usually costs more, so set them by how critical each system is.

## Critical Systems & Recovery Objectives

| System / process | RTO | RPO | Owner |
|------------------|-----|-----|-------|
| [e.g., Customer-facing app] | [e.g., 4 hours] | [e.g., 1 hour] | [Owner / Role] |
| [e.g., Email & comms] | [e.g., 8 hours] | [e.g., 4 hours] | [Owner / Role] |
| [e.g., Finance/billing] | [e.g., 1 business day] | [e.g., 24 hours] | [Owner / Role] |
| [e.g., Internal file storage] | [e.g., 1 business day] | [e.g., 24 hours] | [Owner / Role] |

## Backup Approach

- Back up critical data on a schedule that meets each system's RPO.
- Keep at least one copy off-site or in a separate cloud region/account, isolated from production so one failure cannot destroy both.
- Protect backups from tampering and ransomware (for example, restricted access and immutable or versioned storage).
- Test restores regularly — a backup is only proven when you have restored from it.

## Recovery Procedures (High Level)

1. Confirm the disruption and its scope; declare an event if criteria are met (see Activation).
2. Prioritize recovery by RTO, starting with the most critical systems.
3. Restore from clean backups or fail over to standby infrastructure.
4. Verify data integrity and that systems function correctly before returning them to use.
5. Communicate status to staff and customers as appropriate.
6. Move to normal operations once stability is confirmed, then schedule a review.

Keep detailed, system-specific runbooks alongside this plan.

## Roles & Activation

- **Who declares:** The plan owner ([Owner / Role]) or executive sponsor [e.g., CTO/CEO] declares an event and activates this plan.
- **Coordinator:** Runs the recovery, tracks progress against RTO/RPO, and keeps the timeline.
- **System owners:** Execute recovery for their systems per the runbooks.
- **Communications:** Handles internal and customer updates.

Define clear activation criteria, for example: a critical system is down with no quick fix, or an incident threatens data integrity.

## Communications

- Use a pre-agreed channel and an out-of-band backup (in case the usual tools are down).
- Send regular status updates to leadership and staff.
- Decide customer/partner messaging with Communications and the exec sponsor; be honest and avoid speculation.
- Maintain an up-to-date contact list (staff, vendors, hosting, insurer) accessible even if main systems are offline.

## Testing

- Run a tabletop exercise at least [e.g., annually] and after major changes; walk through a realistic scenario with the response team.
- Test actual backup restores for critical systems on a regular cadence.
- For each test, record: the scenario, who took part, what worked, gaps found, measured vs. target RTO/RPO, and dated follow-up actions.

## Version History

| Version | Date | Author | Summary of changes |
|---------|------|--------|--------------------|
| 1.0 | [Date] | [Owner / Role] | Initial version. |
| | | | |

*Template by Cipherwire (cipherwire.biz). An original starting point, not legal advice — adapt it to your environment and have it reviewed before you rely on it.*