What a BCP is, in plain language
A business continuity plan (BCP) is a document that answers the question “what do we do if a key process stops”: who is responsible for what, in what order they act and how quickly they restore operations. A good BCP is made of short step-by-step scenarios of 2–3 pages each. Nobody reads hundreds of pages in a crisis.
A BCP is part of a wider business continuity management system (BCM). It relies on a business impact analysis (BIA) and follows the logic of the ISO 22301 standard.
What a working BCP consists of
- Critical processes and recovery priorities: what we restore first (from the BIA).
- Targets: RTO (recovery time objective; it is shorter than the maximum tolerable period of disruption, MTPD) and RPO (the acceptable amount of data loss) for each process.
- Scenarios: a separate instruction for each type of disruption (cyberattack, IT failure, loss of the office, loss of a supplier, loss of a key employee).
- Roles and contacts: who makes decisions, whom we notify, phone numbers and backup communication channels.
- Backup resources: alternative sites, suppliers, equipment and data.
- Communication plan: what we tell clients, partners and employees, and how.
How to build a BCP in 7 steps
- Identify critical processes. The ones the business cannot do without for even a day.
- Carry out a BIA. Estimate the cost of downtime for each process and set RTO/RPO.
- Find where risk is concentrated. One server, one supplier, one person, one channel.
- Describe recovery scenarios. Step by step, in plain language, one per threat.
- Assign roles and backups. Who does what, and what replaces a link that has failed.
- Run exercises. Only practice shows that the plan works.
- Maintain the plan. Review it when the company or the market changes.
A BCP for a single IT system: what changes
Sometimes the plan is needed not for the whole company but for one system: accounting, warehouse or an order portal. The logic stays the same and the starting point changes. The question becomes: which processes stop without this system.
- List the processes that run on the system. Each one needs an owner from the business, not just an administrator.
- Take RTO and RPO from the BIA. The strictest process on the system sets the requirement for the system.
- Find the dependencies. Servers, integrations, accounts, the supplier. Any of them can turn out to be a single point of failure.
- Describe the manual mode. What people do while the system is down and how they enter the accumulated data afterwards.
- Separate the documents. Recovering the system itself goes into the disaster recovery plan, and running the business without it goes into the BCP. The boundary is covered in BCP and DRP.
A plan like this is proven by an exercise: the system is switched off in a test and the business runs in manual mode.
Common mistakes
- The plan is written to tick a box and never tested, so it fails in a crisis.
- The document is too long, and nobody opens it.
- There are no owners or contacts, so it is unclear who makes decisions.
- The plan is not updated, although the business and its risks have changed over the year.
Structure of a continuity plan
The list in the section “What a working BCP consists of” describes what the plan must contain in substance. The table below shows how this maps onto the sections of the document.
| Plan section | What it contains | Common mistake |
|---|---|---|
| Critical processes | List of processes without which the business stops (critical process register) | Everything gets included, and the plan becomes bloated |
| Roles and authority | Who declares a crisis, who makes decisions, who talks to clients | Everything depends on one person |
| Disruption scenarios | IT failure, loss of the office, loss of a supplier, staff unavailable | Only fire and flood are covered |
| Recovery plans | Steps, timeframes (RTO) and owners for each scenario | Timeframes are not agreed with the business |
| Contacts and resources | Emergency contacts, backup sites, access rights | The list goes out of date in the first month |
| Testing | Schedule of exercises and the update procedure | The plan is written and never tested |
Continuity plan template: docx
A template for a manufacturing, trading or service company: eight sections, a crisis team with deputies, five scenarios with strategies, procedures for the first 24 hours and a list of appendices.
Download the template. An eight-section plan with tables and sample values. Format: docx, 6 pages.
For credit institutions, use the ONiVD plan template (in Russian) with the mandatory elements of Bank of Russia Regulation No. 850-P. No registration, no forms. If you need to adapt the template to your organisation or to pass an inspection with it, contact us: how we do it and how long it takes.
Frequently asked questions
How is a BCP different from a disaster recovery plan (DRP)?
A BCP covers the whole business (processes, people, suppliers, communications). A DRP covers the recovery of IT systems and data. A DRP is usually part of the BCP, as its IT component. More in the article BCP and DRP: what is the difference.
How many pages should a BCP be?
A working plan consists of short scenarios of 2–3 pages for each threat, plus contacts and priorities. What matters most is that the team can act on it without stopping to think.
Where do you start when writing the plan?
With a business impact analysis (BIA): identify your critical processes and the cost of their downtime. You can start with the free resilience assessment on this site.
Check your recovery numbers
The assessment shows where the recovery times the business needs do not match what the technology can deliver. After that, either your specialist calculates these numbers, or we do.
