Business Continuity Plan Template

What is a Business Continuity Plan?

A business continuity plan says what your organisation must keep running when something stops working, how quickly each thing has to come back, and who does what in the first hours. The value is not the document itself. It is that somebody has already decided the priority order and written down the phone numbers, so a fire, a ransomware attack or a supplier collapse becomes a bad week rather than the end of the business.

Regulators require one in financial services, healthcare and critical infrastructure, insurers ask about it, and it now appears routinely in ordinary supplier due diligence. The person who actually uses it is whoever is awake at three in the morning: an operations lead, an IT manager, or the owner of a small firm. It is triggered by a site becoming unusable, a systems outage or cyber incident, the loss of a key supplier, an extended power or network failure, severe weather, or a large part of the workforce being unavailable at once.

Sector rules set much of the requirement, so identify yours. Operational resilience regimes apply to financial services in the UK and EU, including the digital operational resilience rules for in-scope firms; prudential standards apply in Australia; regulated entities in India follow their regulator's business continuity guidance. Health and safety law adds evacuation duties and data protection law adds breach notification. Notification deadlines after a cyber incident vary sharply by regime and are often counted in hours, so find the reporting clocks that apply to you and write them into the plan.

A continuity plan is not a disaster recovery plan, although it usually contains one. Disaster recovery is the technical restoration of systems and data; continuity is how the organisation keeps serving customers meanwhile, including by hand. It is not a cyber incident response plan either, which carries its own forensic, containment and notification steps. It does not replace insurance. And it does not work untested — a plan nobody has walked through fails on exactly the details that matter under pressure.

What to put in a Business Continuity Plan

These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.

How to write a Business Continuity Plan

1. Identify what must keep running

   List your critical activities from the customer's point of view: taking orders, dispatching goods, paying staff, answering emergency calls, running the production line. For each, set how long it can be down before real harm occurs and how much data loss is tolerable. Be honest about this. If everything is critical within an hour, nothing has been prioritised and the plan will not help anyone.

2. Map each activity to its dependencies

   For every critical activity, write down what it needs: named systems, data, premises, equipment, key people and their deputies, suppliers and utilities. Single points of failure surface here — one person who can authorise payments, one supplier for a component, one site holding the only server. Note each one and decide explicitly whether you will remove it or knowingly accept it.

3. Write the workaround, not just recovery

   For each activity, state how it runs while the normal route is unavailable: paper order forms and a phone number, a second site or home working, a standby supplier already onboarded, a manual payroll run through the bank. Say where the forms and contact lists are held offline. A plan that only describes restoring systems leaves everyone with nothing to do for two days.

4. Set roles, escalation and communication

   Name the incident lead and a deputy, the person who can declare an incident, and who authorises spend during one. Then handle communication explicitly: what customers are told and by whom, what staff are told, who speaks to media or regulators, and where messages go if email and the website are down. Keep a printed contact list with mobile numbers off-site.

5. Test it and record what broke

   Run a tabletop walkthrough at least annually with the people actually named in the plan, and test the parts most likely to be wrong: restoring from backup, reaching the standby supplier, whether the emergency number still connects to a person. Record what failed, fix it, and date the revision. Untested assumptions are where continuity plans fail, every time.

Common mistakes

• Keeping the only copy of the plan and the contact list on the file server that the incident has just taken offline, so nobody can reach the instructions for handling the incident.
• Naming individuals with no deputies, so the plan depends entirely on one person being reachable rather than on holiday, in hospital, or three months gone from the organisation.
• Setting recovery time objectives without asking whether the technical setup can meet them, so the plan promises four hours while the backup restore genuinely takes two days.
• Never testing a restore from backup, when the failure of the backup itself is one of the most common and most expensive discoveries made during a real incident.
• Leaving the plan unchanged through a system migration, an office move or a supplier change, so it describes an organisation that no longer exists in any useful detail.

Frequently asked questions

This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.

Related templates

All templates · Management templates