A business continuity plan (BCP) is the document that sets out how your company keeps delivering its critical products and services when something disrupts it: which processes are recovered first, how quickly, with what resources and who makes the decisions. A plan that works always has the same building blocks: scope and activation criteria, teams and roles, critical processes with their recovery times, strategies and procedures to recover them, communication, and a testing and review schedule.
Further down you will find three examples by type of company and a template outline you can paste into Word and fill in with your own content.
The three numbers the plan rests on
Before you write a single page, the plan needs three values for each critical process. They come from the business impact analysis (BIA), not from the IT manager's gut feeling.
- MTPD (maximum tolerable period of disruption). The point after which the damage becomes unacceptable: lost customers, fines, breached contracts or reputational harm you cannot recover from.
- RTO (recovery time objective). The time within which you commit to having the process running again, even in degraded mode. Always below the MTPD, with a margin for things going wrong.
- RPO (recovery point objective). How much data you can afford to lose, measured in time. An RPO of 15 minutes means that, when you restore, you could be missing at most the last 15 minutes of transactions.
With those three values you can choose a strategy. A four-hour RTO calls for a standby alternate site; a five-day RTO lets you contract the alternative when the incident happens.
Business continuity plan examples by type of company
The three cases are illustrative: we built them to show the reasoning, and they are not real customers or real figures. Timings change with company size, contracts and regulation, so treat them as a way of thinking rather than values to copy.
Financial institution: customer payments and transfers
Scenario. A ransomware attack takes the main data centre offline at 10 a.m. on a business day. The core banking system and the payments platform stop responding.
MTPD of 8 hours. If corporate customers' payroll and supplier payments do not go out that same day, the impact moves from inconvenience to breach: customers who cannot pay their staff, complaints and a difficult conversation with the supervisor. The end of the business day sets the limit.
RTO of 4 hours and RPO close to zero. Four hours leaves room, if the first recovery attempt fails, to still settle before the cut-off. The RPO has to be minimal because losing confirmed transactions means reconciling by hand, with the risk of duplicate payments.
Strategy. An alternate data centre with replication of the transactional database and backups isolated from the network, so the ransomware cannot reach them. While systems are being restored, a manual procedure for high-value payments, with dual signatures and a closed list of authorised transactions. Prepared communications for customers, branches and the supervisor.
Retail or logistics: dispatch from the distribution centre
Scenario. A flood closes the distribution centre that supplies 80 stores for a week. The warehouse management system (WMS) is still running, but the building is not.
MTPD of 72 hours. Assume the stores hold three days of stock for their fastest-moving products. After that come empty shelves, sales lost to competitors and penalties from shopping centres if the store does not open fully stocked.
RTO of 48 hours. The time it takes to get an alternate warehouse running if the agreement is already signed. If you have to look for one during the incident, you will miss the deadline.
Strategy. A framework contract with a third-party logistics provider (3PL) able to receive goods and cross-dock in another city, a list of priority SKUs (you do not need to move the whole catalogue to protect sales) and agreements with the main suppliers to deliver straight to stores during the contingency.
Services or technology company: customer-facing platform
Scenario. The cloud provider suffers a regional outage and the platform the company offers its customers becomes unavailable.
MTPD of 24 hours. Here the contracts set the limit. If the service level agreements promise 99.9% monthly availability, the margin is about 43 minutes a month; beyond that, service credits kick in, and after a day large customers start reconsidering their renewal.
RTO of 4 hours and RPO of 15 minutes. The RTO is set to what the contract allows without a serious penalty, and the RPO to how much customer work it is reasonable to lose.
Strategy. Infrastructure that can be deployed in a second region with replicated backups, a tested failover procedure, a status page and customer notification templates, and remote working for the support team if the office is lost as well.
| Company | Critical process | MTPD | RTO / RPO | Main strategy |
|---|---|---|---|---|
| Financial institution | Payments and transfers | 8 hours | 4 h / near zero | Alternate site with replication and isolated backups |
| Retail or logistics | Dispatch to stores | 72 hours | 48 h / minimal (the WMS is still running) | Logistics provider under a pre-agreed contract |
| Services or technology | Customer-facing platform | 24 hours | 4 h / 15 min | Second region and tested failover |
Notice that none of these strategies is improvised on the day of the incident. In all three cases, what makes it possible to meet the RTO is something that was contracted, configured or rehearsed beforehand.
Business continuity plan structure you can copy
This is the outline we would use for the business continuity plan of a medium-sized or large company. If you move it into Word, keep each section heading and replace the descriptions with your own content.
- Document control. Version, date, plan owner, who approved it and the date of the next review.
- Purpose and scope. Which sites, processes, products and services it covers, and what is explicitly excluded.
- Activation criteria. Which events trigger the plan, who can activate it and how the decision is made to move from incident to contingency.
- Organisation and roles. Crisis committee, continuity coordinator, recovery teams by area, deputies for each person and the call tree.
- Critical processes. A prioritised list taken from the BIA, with the MTPD, RTO and RPO for each one and the minimum resources needed to operate: people, systems, facilities, suppliers and information.
- Scenarios covered. Loss of premises, systems, staff or a critical supplier. A few scenarios by type of loss work better than a long list of disasters.
- Recovery strategies. For each process and scenario, the chosen alternative: alternate site, remote working, substitute supplier, manual procedure.
- Recovery procedures. Step-by-step action cards for each team, with an owner, estimated time and a "done" criterion. This is the part people read during the crisis, so it has to fit in a few pages.
- Communication. Prepared messages and channels for employees, customers, suppliers, authorities and the media, and who speaks on behalf of the company.
- Return to normal. How to move from contingency mode back to normal operations without losing data or duplicating transactions.
- Testing and maintenance. Exercise schedule, results of the last test, outstanding improvement actions and review triggers (a change of supplier, system or site).
- Appendices. Contact directory, inventory of critical resources, contracts with alternate suppliers and activation logs.
Business continuity plan, continuity of operations plan, DRP and crisis plan
The four terms get mixed up in policies, tender documents and audits. Each one answers a different question, and they work best as connected pieces rather than one document that tries to do everything.
| Plan | Question it answers | Scope | Who leads it |
|---|---|---|---|
| Business continuity plan (BCP) | How do we keep delivering what is critical? | The whole organisation: processes, people, sites, suppliers and technology | Continuity or risk, with senior management |
| Continuity of operations plan | How does this area or process keep running? | A process, a plant or an operational area | The person responsible for that operation |
| Disaster recovery plan (DRP) | How do we recover systems and data? | Infrastructure and applications | IT |
| Crisis management plan | Who decides and what do we communicate? | Decision-making, communication and reputation | Crisis committee or senior management |
"Continuity of operations plan" is the term that varies most from one company to another. Some use it as a synonym for BCP; others, especially in manufacturing and logistics, use it for the plant-level or process-level plans that sit under the main plan. What matters is that your policy says what it means in your organisation. The DRP is one of the BCP's strategies: without it there is no technology recovery, but a perfect DRP does nothing for a flooded distribution centre or a site with no staff.
What ISO 22301 requires and where the BIA fits
ISO 22301:2019, Security and resilience. Business continuity management systems. Requirements, is the certifiable international standard for business continuity management systems. ISO published it in October 2019 and in February 2024 added an amendment (ISO 22301:2019/Amd 1:2024) that requires organisations to determine whether climate change is a relevant issue in their context. ISO is already working on a new edition, at committee draft stage (ISO/CD 22301), so it is worth watching for its publication.
The standard does not provide a plan template. It requires a system: the BIA and risk assessment (clause 8.2), the strategies that come out of them and business continuity plans (clause 8.4.4) that are tested and reviewed. That is why a plan written without a BIA will not pass a certification audit, however well the document is drafted. If you want the detail of the standard, we explain it in what ISO 22301 is and what it is for, and the step from risk to BIA is covered in the webinar on risk assessment and BIA.
If you work at a financial institution in Colombia, Mexico or elsewhere in the region, your supervisor also has its own continuity requirements. We go through them in the article on security and continuity regulation in the Latin American financial sector.
Where continuity plans fail
In our experience, plans tend to fail because of what they take for granted rather than what they say. These are the points we would check first in any plan:
- RTOs with no BIA behind them. "Four hours for everything" sounds good, but if nobody asked the business when the damage starts, the plan protects what IT knows about and leaves out processes that have no system of their own.
- Suppliers left out of the plan. The plan assumes the cloud, the carrier or the outsourced call centre will still be there. If a critical process depends on a third party, its failure has to be a scenario, and its contract has to allow for what the plan needs.
- Outdated contacts and deputies. The call tree is the first thing used and the first thing to go out of date. A plan with half the phone numbers wrong delays activation from minute one.
- Documents that are too long. Nobody reads a two-hundred-page plan during a crisis. The one- or two-page action cards for each team are what actually gets used; the rest is context for the auditor.
- Tests that do not test anything. A tabletop exercise once a year is better than nothing, but it does not prove the alternate site will start up. We would alternate tabletop exercises with real technical tests of the most critical process.
Where we would start
If you are starting from scratch, we would run the BIA for five to ten processes before writing anything, with the owner of each one in the room. Then the strategies for those processes, and only then the document, using the outline above. Extending the scope once the first plan has been tested costs far less than fixing a plan nobody has ever rehearsed.
In the GlobalSuite® Business Continuity module, the BIA is run through questionnaires sent to each process owner, which consolidate automatically and give you the RTO and RPO for each process, and plans are built by scenario with their critical resources and the date of their last review. Tests are scheduled and stored with their results and evidence, which is exactly what the auditor asks for. If you would like to see it with your own processes, request a demo.
Official sources: iso.org pages for ISO 22301:2019, its amendment ISO 22301:2019/Amd 1:2024 and the ISO/CD 22301 draft. The examples in this article are illustrative and do not correspond to any customer. Content reviewed in October 2026.
