Business continuity plan template

1. Document control

This plan sets out how Acme keeps its critical services running, or restores them, when something disrupts them. It is the operational companion to the Acme Business Continuity and Disaster Recovery Policy: the policy sets the obligations and who owns them; this plan is what the team uses during a disruption.

Replace every [Fill in] and [set your own] before you adopt the plan, and delete anything that does not match how you actually work.

2. Scope and assumptions

This plan covers the services, data, people and vendors Acme needs to deliver its product to customers and to run the business. It covers disruptions of any cause, including infrastructure outages, security incidents, data loss, vendor failure and loss of key people.

2.1 In scope

• Production systems and data listed in the critical services inventory (section 3).
• The providers listed in the dependency map (section 4).
• The people and roles in section 5, and their backups.
• Out of scope: [Fill in]

2.2 Assumptions

Check each assumption and change it if it is not true for you. A plan built on a false assumption fails when it is needed.

• The team works remotely or can, so loss of an office does not by itself stop operations.
• Infrastructure is defined as code and can be rebuilt in another region or account.
• Backups are held in a separate account or region from the systems they protect.
• At least one person other than the usual owner can follow each recovery procedure.
• An alternative communication channel exists that does not depend on your identity provider or main workspace.
• [Fill in]

3. Critical services inventory

List every service whose loss would stop customers using the product or stop the business operating. The recovery time objective (RTO) is the longest the service can be down; the recovery point objective (RPO) is the most data, measured in time, you can afford to lose. Set your own values with the people who own each service, make sure they match your Business Continuity and Disaster Recovery Policy and what you have promised customers, and only commit to targets your backups and tests show you can meet.

4. Dependency map

Record each outside provider your critical services rely on, how you reach them in an outage, and what you would do without them. Review this map when you add or change a vendor.

4.1 Alternative communication channel

5. Roles and contacts

Name a person and a backup for each role. In a small team one person may hold two roles, but the business continuity lead and the technical recovery lead should be different people when possible.

5.1 Contact list

Keep this list current and reachable when your normal tools are down.

6. Activation

Activating the plan means the business continuity lead takes charge of recovery, the roles in section 5 are filled, and the alternative channel is opened if normal tools are affected. When in doubt, activate: standing the plan down early costs little.

6.1 Activation criteria

• A service in the critical services inventory has been unavailable or badly degraded for [set your own] and the cause is not yet fixed.
• A recovery time objective (RTO) or recovery point objective (RPO) in the inventory is at risk of being missed.
• The primary environment cannot be trusted, for example after ransomware or a suspected compromise of administrator access.
• A provider in the dependency map reports an outage with no estimated recovery time that fits your objectives.
• Key people needed to operate or recover a critical service are unavailable.

6.2 Who can declare

• The business continuity lead (Head of Engineering) or their named backup
• Any member of executive management
• The engineering on-call lead, when the criteria below are met and nobody above can be reached within [Fill in: minutes]

6.3 On activation

1. Record the declaration in the incident record: time, reason, who declared and who leads the recovery.
2. Fill the roles in section 5 and open the alternative channel if needed.
3. Identify the affected services from the inventory and their RTO and RPO.
4. Pick the matching playbook in section 7, or follow the closest one and note the differences.
5. If the cause may be a security incident, start the incident response plan and run both on one timeline.
6. Send the first internal update and decide when to post the first customer update.

7. Scenario playbooks

7.1 Cloud region outage

When: The region or zone hosting a critical service is unavailable or degraded, confirmed on the provider's status page or support case.

1. Confirm the scope with the provider's status page and open a support case; record the case number in the incident record.
2. Decide with the business continuity lead whether to wait or fail over, using the RTO for each affected service in the inventory.
3. If failing over: rebuild or promote infrastructure in the alternative region from infrastructure code, following the recovery procedure listed for each service.
4. Restore or promote data from the most recent replica or backup that meets the RPO, and record the age of the data restored.
5. Update DNS or traffic routing, then verify the service with smoke tests before telling customers it is back.
6. Post customer updates on https://status.acme.example at the cadence the communications lead sets.
7. Plan and schedule the move back to the primary region once it is stable, as a normal change.

Done when: Service running in a healthy region, verified, and customers told.

7.2 Loss of identity provider

When: Staff cannot sign in to the identity provider, or it is suspected to be compromised.

1. Move internal communication to the alternative channel listed in section 4, which must not depend on the identity provider.
2. Use the break-glass accounts for the cloud provider and other critical consoles. Record who used them, when and why.
3. If compromise is suspected, start the incident response plan as well and run both on one timeline.
4. Keep production running; avoid configuration changes that need single sign-on until access is restored.
5. When the provider recovers, rotate break-glass credentials that were used and review sign-in logs for the outage window.

Done when: Normal sign-in restored, break-glass credentials rotated, access logs reviewed.

7.3 Data corruption or ransomware: restore from backups

When: Production data is corrupted, deleted or encrypted, by an error, a faulty release or an attacker.

1. Stop the damage: pause the jobs, deployments or access that are changing data. For ransomware or suspected attack, start the incident response plan and preserve evidence before rebuilding.
2. Identify the last known-good point in time and check it against the RPO in the inventory.
3. Restore from backups into an isolated environment first, using backups held in a separate account or region where you have them.
4. Verify integrity: record counts, checksums or application checks agreed for this service, and a sample review by the service owner.
5. Rebuild compromised systems from infrastructure code rather than cleaning them in place, then switch traffic to the restored data.
6. Record the data loss window (time between the restore point and the incident) and tell affected customers through the communications lead.
7. Log the restore in the restore test log in section 9, including the time it took.

Done when: Verified data back in production, data loss window recorded, root cause being fixed.

7.4 Loss of a key person

When: Someone whose knowledge or access is needed to operate or recover a critical service is unexpectedly unavailable.

1. Name the backup for each role the person held, using the roles table and the contact list.
2. Use documented runbooks and shared, access-controlled credentials, not personal accounts or notes.
3. If access is held only by that person, use the documented admin recovery process for each system and record it.
4. Afterwards, add the missing runbooks and grant access to a second trained person so no critical service depends on one individual.

Done when: Every role the person held is covered and the single-person gap has a corrective action.

7.5 Critical vendor failure

When: A vendor in the dependency map is down for longer than you can tolerate, stops trading, or ends the service.

1. Confirm the outage with the vendor's status page or support, and record what they say about expected recovery.
2. Check the vendor's contract for its availability commitments, support contacts and termination or data export terms.
3. Decide whether to wait, use the documented fallback, or switch to the alternative listed in the dependency map.
4. Export or retrieve the data you hold with the vendor while you still can.
5. Tell customers if the outage affects Acme's service, and record the decision and timeline in the incident record.
6. Afterwards, review whether the vendor's risk rating and the fallback in the dependency map need to change.

Done when: Service restored or replaced, data retrieved where needed, vendor risk reviewed.

8. Communication templates

Only the people your policy names may approve messages to customers, partners or the press.

Before sending: check your customer contracts and service level agreements for availability commitments, notification duties, recipients and timing, and check whether the disruption also triggers duties under your incident response process. These vary by contract and by the data involved. This template is not legal advice; involve legal counsel where a notice may be required.

8.1 Internal update

Send in the alternative channel or your normal channel at the cadence the business continuity lead sets.

• Disruption: [short title], declared [YYYY-MM-DD HH:MM UTC]
• Status: [Assessing / Recovering / Verifying / Resolved]
• Services affected: [from the inventory]
• Customer impact: [what customers can and cannot do]
• What we are doing: [playbook in use and current step]
• Expected recovery: [estimate, or "not yet known"]
• What staff should do: [e.g. hold deployments, use the alternative channel]
• Next update: [time]

8.2 Customer status update

Post on https://status.acme.example, or the channel your contracts name. A starting draft only: keep it factual and do not speculate about causes.

• Title: [Service] [degraded performance / unavailable]
• Update: We are investigating an issue affecting [service or feature]. Customers may [describe what they will see]. Our team is working to restore service.
• Follow-up update: We have identified the cause and are [restoring service / failing over / restoring data]. [What customers can do in the meantime, or "no action is needed".]
• Resolved: Service was restored at [HH:MM UTC]. [Whether any data or activity in a stated window was affected.] We will [share a summary / contact affected customers directly].
• Next update by: [time]

9. Restore test log

Record every restore, whether it is a planned test or a real recovery. This log is how you show the recovery objectives in section 3 are achievable rather than assumed.

10. Annual test and exercise checklist

Complete this checklist at least once a year and whenever the architecture, team or critical vendors change significantly. Keep the records with your audit evidence.

• [ ] Confirm the critical services inventory, owners, RTOs and RPOs are current and approved.
• [ ] Restore at least one critical service from backups into an isolated environment and record the time taken and the age of the restored data.
• [ ] Rebuild a critical environment from infrastructure code, or confirm it still builds, in an alternative region or account.
• [ ] Run a tabletop exercise with the business continuity lead, technical recovery lead, communications lead and executive management, using one of the playbooks in section 7.
• [ ] Check that the alternative communication channel works and that every person on the contact list can be reached through it.
• [ ] Test the break-glass accounts: they work, they are stored securely and their use is logged.
• [ ] Review each provider in the dependency map: support contacts, contract terms and fallback.
• [ ] Draft the internal update and customer status update from section 8 as if the scenario were real.
• [ ] Record attendees, scenario, results against the objectives, gaps found and corrective actions with owners and due dates.
• [ ] Update this plan, the inventory and the runbooks with what you learned, and file the record with your audit evidence.

11. Review and approval

Review this plan at least annually, after every activation and test, and after any significant change to the architecture, team or critical vendors. Each review is approved and recorded below.