Business continuity plan (example and structure)
A business continuity plan (BCP) describes how your organisation keeps running during a serious disruption. Think of a fire, ransomware, data loss or the loss of a key supplier. The plan states who does what, in which order, and with which resources. A good BCP stands apart from certification: you do not need ISO 22301 for one, although that standard does offer a proven structure. The basis of every plan is a business impact analysis (BIA). Practical guidance is in ISO 22313 .
A BCP is not a playbook for every conceivable incident. It focuses on restoring your critical processes, whatever the exact cause of the disruption.
Do you need ISO 22301 for a good BCP?
No. You can write an excellent business continuity plan without ever applying for a certificate. The standard is mainly useful when customers or tenders ask for it, or when you want to show that you take the subject seriously.
The difference is simple to explain:
| Business continuity plan | ISO 22301 | |
|---|---|---|
| What is it? | The plan itself | The standard with requirements for the whole system |
| Mandatory? | Never by law, sometimes by contract | Never mandatory, sometimes by contract |
| Burden of proof | For internal use | Must be demonstrable to an external auditor |
| Scope | One document or a set of plans | Full management system (BCMS) |
Many organisations start with a BCP and only choose certification later. If you want to know whether the standard suits you, read who ISO 22301 is relevant for.
Mandatory components of a business continuity plan
A usable BCP always contains a set of fixed sections. Without these components, the plan stays theoretical. Below you can see what should minimally be included and why.
If you want to work out the plan per system, you will find the IT side in the IT continuity plan. The BCP itself covers the whole organisation.
| Component | What it describes | Why it is needed |
|---|---|---|
| Scope and purpose | Which processes and locations the plan covers | Stops the plan from becoming too broad or too vague |
| Roles and responsibilities | Who forms the crisis team and who decides | There is no time to work this out during a crisis |
| Activation criteria | When the plan comes into effect | Avoids doubt about whether to escalate |
| Recovery priorities | Which process must return first (from the BIA) | Directs people and resources to where they are needed |
| Recovery strategies | How you restore each critical process | Makes the plan workable instead of paper only |
| Communication plan | Who communicates what, internally and externally | Poor communication often makes the damage worse |
| Contact lists | Key people, suppliers, emergency services | Being able to reach people quickly saves valuable time |
Example structure: table of contents for a BCP
This is what a compact business continuity plan could look like. Use this table of contents as a starting point and remove whatever does not fit your organisation.
| Chapter | Content |
|---|---|
| 1. Introduction and scope | Purpose of the plan, what is and is not covered |
| 2. Crisis organisation | Crisis team, roles, mandates, escalation line |
| 3. Activation and alerting | When and how the plan is activated |
| 4. Critical processes | Overview from the BIA with RTO and RPO per process |
| 5. Recovery strategies | Per process: an alternative way of working or location |
| 6. ICT recovery site | Backups, recovery order, recovery environment |
| 7. Communication | Messages, spokesperson, channels |
| 8. Appendices | Contact lists, floor plans, checklists |
The relationship between BCP, BIA and ISO 22301
These three belong together, but they are not the same thing. The business impact analysis provides the input. The business continuity plan is the concrete plan. ISO 22301 is the system that keeps the plan current, tested and improving.
In practice it works like this: the BIA determines which processes are critical and how quickly they must be restored. Those outcomes form chapters 4 and 5 of your plan. ISO 22301 then requires you to test and maintain the plan, so that it does not disappear into a drawer.
How to make a business continuity plan yourself
You do not have to do everything at once. Start small, with your most critical processes, and expand from there. Follow this order.
Step 1: Carry out a BIA
Determine which processes are critical and what their recovery objectives are. Without this basis you set priorities on gut feeling. Use the BIA example as a template.
Step 2: Choose recovery strategies
For each critical process, decide how you keep it running: working from home, a recovery location, a second supplier or a manual way of working.
Step 3: Write the plan
Fill in the example structure above. Keep it short and role-based, so that people can actually use it during a crisis.
Step 4: Test and practise
Run at least one exercise per year, for example a tabletop scenario. An untested plan is an assumption, not a guarantee.
Step 5: Maintain and improve
Update the plan after every exercise, after incidents and after major changes. This is exactly what ISO 22301 safeguards if you later certify.
Common mistakes with a business continuity plan
Writing a plan is the easy part. Keeping it alive is where things often go wrong.
| Mistake | Consequence | Better alternative |
|---|---|---|
| Basing the plan on assumptions | Wrong priorities during a crisis | Always start with a BIA |
| Too long and detailed | Nobody quickly finds the right action | Short, role-based, with checklists |
| Never practising | The plan does not work when needed | Test at least once a year |
| Contact lists going out of date | Key people cannot be reached | Check the lists regularly |