How to create a business continuity plan? A business continuity plan starts with the business service, not the IT system: first establish which services are critical to the organisation and how long they can be unavailable, and only then map them to the technical components that support them. The reverse order – starting from servers – produces a plan that protects technology but not the business.
Canonical definition: A business continuity plan (BCP) is a documented set of procedures that enables an organisation to continue or recover critical business services after a disruption, based on a business impact analysis (BIA) and recovery objectives (RTO, RPO), in line with the ISO 22301 business continuity management system.
This article walks through the five steps of building a business continuity plan – from defining critical services to the 4 Ps model (people, process, partners, technology) – and flags the typical mistakes made at the start.
Business continuity plan in 5 steps – in brief:
- The starting point is the business service, not the IT system – first establish what is critical to the organisation, then map it to technology.
- The business impact analysis (BIA) sets priorities and recovery objectives: RTO (recovery time) and RPO (tolerable data loss).
- The recovery strategy and plan must cover four areas: people, process, partners and technology (product) – the 4 Ps model.
- An untested plan is an assumption, not a capability – exercises verify whether the stated RTO and RPO are actually achievable.
- The most common mistake is starting from IT and limiting the plan to system recovery, omitting people, process and partners.
- Patronusec helps you build a simple, effective business continuity plan matched to your requirements and budget, without needless bureaucracy.
Table of Contents
Why does the plan start with the business service, not the IT system?
A business continuity plan starts with the business service because it is the service – not the system – that has value to the organisation and its customers, and technology is only the means of delivering it. Starting from IT inverts that logic and produces a plan that recovers servers without knowing what for.
A business service is a specific value the organisation delivers – processing payments, fulfilling orders, providing benefits, running sales. Disrupting a business service has measurable consequences: lost revenue, unhappy customers, regulatory exposure. IT systems matter, but solely because they support services – that is a dependency, not an end in itself.
The correct order is therefore this: first establish which services are critical and how long they can be unavailable before the effects become unacceptable. Only with that knowledge do you map the service to its supporting components – systems, data, people, suppliers. A plan built from the service down protects what has value; a plan built from IT up protects technology, often overlooking that a service also depends on people and partners, not only on servers.
A continuity plan built from the servers upward recovers technology and asks afterwards who it served; a plan built from the service downward knows from the outset what has value – and it is that order that decides whether the plan is useful.
Steps 1 and 2: business impact analysis and recovery objectives
The first two steps are defining critical services and running a business impact analysis (BIA), from which recovery objectives are derived. The BIA is the foundation of the whole plan – without it, recovery objectives are guesswork and recovery priorities are accidents.
Step 1: define critical services. Establish which business services are critical to the organisation, its customers and its obligations (including regulatory ones). Not everything is critical – the key is prioritisation, so that in a crisis you focus resources where the effects of disruption are most serious.
Step 2: run a business impact analysis (BIA). The BIA assesses how disrupting each service affects the organisation over time, and derives recovery objectives from that:
- RTO (Recovery Time Objective) – the time within which a service must be recovered before the effects become unacceptable.
- RPO (Recovery Point Objective) – the maximum tolerable data loss, expressed as the point in time to which data must be recovered.
- MTPD (Maximum Tolerable Period of Disruption) – the outer limit beyond which the organisation’s very ability to function is at risk; the RTO is set inside this limit with a margin.
The key principle: recovery objectives must follow from the BIA, not be numbers chosen because they “sound safe”. An auditor – and the reality of an incident – checks whether the RTO and RPO are anchored in impact-analysis data, not whether they look reassuring on paper.
Steps 3, 4 and 5: strategy, the 4 Ps model and testing
The next three steps translate recovery objectives into concrete capability: choosing a recovery strategy, covering the four areas (4 Ps) and testing the plan. Without these steps, the BIA remains an analysis rather than a capability.
Step 3: choose a recovery strategy for each critical service. For each service, establish how it will be recovered within its RTO and RPO – from technical solutions (backups, redundancy, alternative sites) to the manual workarounds users will apply during the disruption.
Step 4: cover the four areas – the 4 Ps model. An effective continuity plan must span four dimensions, not just technology:
- People – who performs the critical activities, who deputises for them, and how to ensure availability and succession of skills in a crisis.
- Process – how the critical activities run and which manual workarounds allow them to continue when systems are unavailable.
- Partners – which suppliers and partners the service depends on, how to secure continuity on their side, and what to do when they fail.
- Product / Technology – which systems, data and infrastructure support the service and how they will be recovered within the required time.
The 4 Ps model guards against the most common trap: reducing the plan to IT. A service can depend on a single person, a single supplier or a single process as critically as it depends on a server – and a plan that omits those dimensions fails exactly where the technology works but a person, a process or a partner is missing.
Step 5: test the plan. A plan that has never been exercised is an assumption, not a capability. Exercises verify whether the stated RTO and RPO are realistically achievable, and reveal gaps – between the document and reality – before a real incident does. Test results, including the gaps found, feed back into the plan as corrections.
Patronusec Insight: Our project experience shows that the most common weakness in continuity plans is not the absence of technology but an excessive focus on it. Organisations invest in backups and redundancy, and then a disruption halts the service because the only person who knows the process is unavailable, a key supplier has its own outage, or no manual workaround exists for the recovery window. We recommend building the plan around the service and working consistently through the four Ps – people, process, partners, technology – for each critical service. That is the model that turns a plan from an “IT recovery plan” into a genuine business continuity plan.
How do the five steps combine into a working plan?
The five steps combine into a working continuity plan by running them in dependency order: from critical services, through the BIA and recovery objectives, to strategy, the 4 Ps model and testing, and then into a maintenance cycle. Each step builds on the previous one – which is why the order matters.
The recommended sequence:
- Critical services. Prioritisation: what is critical to the organisation, its customers and its obligations.
- BIA and objectives. Business impact analysis, and from it the RTO, RPO and MTPD for each service.
- Strategy. How each service is recovered within its objectives, manual workarounds included.
- The 4 Ps model. Covering people, process, partners and technology for each critical service.
- Testing and maintenance. Exercises verifying the achievability of RTO and RPO, results feeding back into the plan, a review cycle.
The key principle binding it all together: a continuity plan is a process, not a document. Services, dependencies, people and suppliers change over time – a plan that was written once and is neither tested nor updated drifts away from reality. A mature plan is alive: it is exercised, and the results of those exercises improve it.
Patronusec helps you build such a plan as part of our business continuity management (BCM) service – simply and effectively, matched to your organisation’s requirements and budget, without needless bureaucracy.
FAQ – How to create a business continuity plan
Where do you start a business continuity plan?
Start with the business service, not the IT system. First establish which services are critical to the organisation and how long they can be unavailable before the effects become unacceptable. Only then map the service to its supporting components – systems, data, people and suppliers. The service-down order determines whether the plan protects what has value.
What is a business impact analysis (BIA)?
A business impact analysis (BIA) assesses how disrupting each critical service affects the organisation over time, and derives recovery objectives from that: RTO, RPO and MTPD. The BIA is the foundation of the continuity plan – without it, recovery objectives are guesswork and recovery priorities are accidents. Objectives must follow from the BIA, not be numbers that “sound safe”.
What do RTO and RPO mean?
RTO (Recovery Time Objective) is the time within which a service must be recovered before the effects of disruption become unacceptable. RPO (Recovery Point Objective) is the maximum tolerable data loss – the point in time to which data must be recovered. Both are derived from the business impact analysis and verified by testing, not declared up front.
What is the 4 Ps model in a business continuity plan?
The 4 Ps model is the four areas an effective continuity plan must cover: people, process, partners and product (technology). It guards against the most common trap – reducing the plan to IT. A service can depend on a single person, supplier or process as critically as it depends on a server, so the plan must span all four dimensions.
Why do you have to test a business continuity plan?
Because a plan that has never been exercised is an assumption, not a capability. Testing verifies whether the stated RTO and RPO are realistically achievable, and reveals gaps between the document and reality before a real incident does. There is a common gap between an RTO on paper and the real ability to recover – only exercising detects it. Test results feed back into the plan as corrections.
How does Patronusec help build a business continuity plan?
We help you work through the whole sequence: from defining critical services and the business impact analysis, through recovery objectives and strategy, to covering the 4 Ps model and testing. We build a plan that is simple and effective, matched to your organisation’s requirements and budget, without needless bureaucracy – so that it is a real capability, not a document on a shelf.
Recommended reading
A reading path for the business continuity topic:
- What a business continuity (BCM) test report should contain – how to document and use the results of exercises.
- Incident Response, Disaster Recovery, Business Continuity and IT Continuity – how they differ – how a continuity plan relates to IT recovery and incident response.
- DORA for beginners – what it changes, who it applies to and how to start – a regime that requires documented recovery capability.
Business continuity plan – free consultation
Patronusec helps you build a simple, effective business continuity plan (BCM) matched to your organisation’s requirements and budget – from critical services and the business impact analysis, through the 4 Ps model, to testing. Book a free consultation.
