A single cyber incident, a server room flood, or a key supplier going offline can bring operations to a grinding halt. The difference between a business that recovers quickly and one that doesn’t usually comes down to one thing: whether they planned for it. Knowing how to create a business continuity plan gives you a documented, tested process for keeping your organisation running when things go wrong, and a clear path back to normal when they do.
Yet many businesses either don’t have a plan at all or have one gathering dust in a shared drive somewhere. That’s a problem. Without a structured approach, decisions during a crisis become reactive, costly, and slow. A well-built continuity plan removes the guesswork and puts your people, processes, and recovery priorities in order before disaster strikes.
At TrustedIA, business continuity sits at the core of our managed security services. We help organisations across the UK prepare for disruption, whether that’s through disaster recovery planning, cyber incident response, or aligning with frameworks like ISO 27001. We’ve built this guide from that hands-on experience.
Below, you’ll find a practical, step-by-step walkthrough covering everything from risk assessment to testing and maintenance. Whether you’re starting from scratch or tightening up an existing plan, this guide gives you the structure and clarity to get it done properly.
What a BCP covers and who owns it
A business continuity plan is a structured, documented framework that details how your organisation maintains or restores critical functions during and after a disruption. It is not simply a disaster recovery document, though disaster recovery is one component of it. The BCP covers the broader picture: what actions you take during the incident, who makes the decisions, how you communicate with staff and customers, and how you return to normal operations as efficiently as possible. Think of it as your organisation’s operational playbook for when things go wrong.
What a BCP contains
Most people assume a BCP is just a list of emergency contacts and backup procedures. In reality, it covers significantly more ground. A complete plan documents every critical business function, the resources those functions depend on, and the minimum level of service you need to maintain to keep the business viable during a disruption.
A BCP without a clear recovery time objective (RTO) and recovery point objective (RPO) for each critical function is not a plan. It is a set of good intentions.
Here is what a complete BCP typically includes:
| Component | What it covers |
|---|---|
| Scope and assumptions | Which functions, locations, and systems are covered, and what disruption scenarios the plan addresses |
| Business impact analysis (BIA) | The financial and operational effect of losing each critical function, including RTO and RPO |
| Risk assessment | Identified threats, likelihood, impact ratings, and chosen mitigations |
| Recovery strategies | Specific steps to restore each critical function, including workarounds and fallback options |
| Roles and responsibilities | Who leads recovery, who communicates internally and externally, and who has authority to invoke the plan |
| Communication plan | How you notify staff, customers, suppliers, and regulators during an incident |
| Testing and review schedule | When and how the plan gets tested, and who is responsible for keeping it updated |
Each of these components connects directly to the others. A weak business impact analysis, for example, will undermine the quality of your recovery strategies because you won’t have a clear picture of which functions to prioritise when resources are stretched.
Who owns the plan
Ownership is one of the most important questions to settle before you start building your BCP. A plan without a named owner tends to drift, get updated inconsistently, and fail at the exact moment it is needed most. Clarity on accountability is what separates plans that get used from plans that get forgotten.
In most organisations, overall ownership sits with a senior leader, such as the CEO, COO, or Chief Information Security Officer (CISO). This person is accountable for ensuring the plan exists, gets tested regularly, and stays current as the business changes. However, ownership of individual sections should be distributed across the relevant function leads. Your IT lead owns the technical recovery procedures. Your HR lead owns the staff communication plan. Your operations manager owns the facilities and supply chain elements.
When you know how to create a business continuity plan properly, you treat it as a living, cross-functional document rather than a one-person project. Assign named deputies for each section owner too, so there is always someone with the authority and knowledge to act, even if the primary owner is unavailable when an incident occurs.
Step 1. Set scope, assumptions, and priorities
Before you write a single recovery procedure, you need to define the boundaries of your plan. Skipping this step is one of the most common reasons business continuity plans fail in practice. Without a clear scope, the plan becomes too broad to maintain, too vague to act on, and too slow to execute when a real incident hits. Start here and make every subsequent step easier.
Define what the plan covers
Your scope statement answers three questions: which parts of the business does this plan apply to, which disruption scenarios does it address, and which ones fall outside its coverage. Be deliberate about this. A plan that tries to cover every possible scenario in equal depth ends up covering none of them well.
A simple scope definition might look like this:
This plan covers all UK-based operations, including customer support, IT infrastructure, and finance. It addresses cyber incidents, prolonged power outages, and key staff unavailability. Physical site destruction and supply chain failures are excluded from this version.
Write your scope in plain language. The people invoking this plan during a crisis should not need to interpret it.
Document your planning assumptions
Every plan rests on assumptions, and yours needs to make them explicit. Assumptions are the conditions you expect to hold true when the plan is invoked. For example, you might assume that at least 50% of staff are available, that your cloud backup provider remains operational, or that internet connectivity is partially available.
List your assumptions clearly so that anyone reading the plan understands the conditions it was designed for. If an incident falls outside those assumptions, the plan owner knows to adapt the response rather than follow it blindly.
Set your recovery priorities
Not every business function carries the same weight. When you think about how to create a business continuity plan that actually works, you need to rank your critical functions before you assign resources to them. Use a simple priority tier:
| Priority | Description | Example |
|---|---|---|
| Tier 1 | Cannot stop without immediate business failure | Customer billing, core IT systems |
| Tier 2 | Must restore within 24 to 72 hours | Internal communications, HR systems |
| Tier 3 | Can operate manually for up to one week | Reporting, non-critical admin |
Assign each function a tier with input from its department lead. This decision directly shapes your recovery time objectives in the next step.
Step 2. Run a business impact analysis
A business impact analysis (BIA) is the research phase of your plan. It tells you exactly what it costs your organisation to lose a specific function, for how long you can lose it, and how much data you can afford to lose in the process. Without this information, your recovery priorities from Step 1 are educated guesses. With it, they become defensible decisions backed by real numbers.
Gather data from function owners
Start by interviewing or surveying the lead for each priority function you identified in Step 1. Your goal is to understand what each function depends on and what happens to the business when those dependencies are unavailable. Ask each function owner to answer the following:
- What systems, tools, and third-party services does this function rely on?
- What is the financial impact per hour or per day if this function stops?
- What manual workarounds, if any, exist?
- Which staff members are essential to keep this function running?
- What regulatory or contractual obligations does this function carry?
Collect this data in a shared spreadsheet before you move to calculations. Consistent, structured inputs make the analysis far easier to defend and update when your business changes.
Calculate impact and set RTOs and RPOs
Once you have the raw data, convert it into two figures for each critical function: the recovery time objective (RTO) and the recovery point objective (RPO). The RTO is the maximum time your business can tolerate that function being down. The RPO is the maximum amount of data loss, measured in time, that is acceptable.
If your RTO for customer billing is four hours but your backup runs once every 24 hours, you have a gap that your plan must address before it is tested by a real incident.
Use a table like this to capture your BIA output for each function:
| Function | Tier | Financial impact per day | RTO | RPO | Key dependencies |
|---|---|---|---|---|---|
| Customer billing | 1 | ยฃ8,000 | 4 hours | 1 hour | Payment gateway, CRM |
| IT helpdesk | 2 | ยฃ2,000 | 24 hours | 4 hours | Ticketing system |
| Payroll processing | 2 | ยฃ1,500 | 48 hours | 24 hours | HRMS, bank portal |
This output becomes one of the most critical inputs when you think about how to create a business continuity plan that holds up under real pressure rather than just on paper.
Step 3. Assess risks and choose mitigations
Your BIA tells you what it costs to lose a function. This step tells you what could cause that loss in the first place and how likely it is. A risk assessment turns a vague awareness of threats into a prioritised, actionable list, each item with a clear response attached. This is where your plan starts connecting vulnerabilities to concrete decisions.
Identify and rate your threats
Start by listing the threats most relevant to your organisation. Focus on realistic scenarios rather than every conceivable event. Common categories include cyber incidents (ransomware, phishing, data breaches), physical disruptions (fire, flooding, power failure), people risks (key person unavailability, industrial action), and third-party failures (supplier outages, cloud provider downtime).
Once you have your list, rate each threat using a simple likelihood and impact matrix. Assign each a score from 1 to 3 for likelihood (low, medium, high) and 1 to 3 for impact (low, medium, high), then multiply the scores to get a combined risk rating.
| Threat | Likelihood (1-3) | Impact (1-3) | Risk Rating |
|---|---|---|---|
| Ransomware attack | 3 | 3 | 9 |
| Key staff unavailability | 2 | 3 | 6 |
| Cloud provider outage | 2 | 2 | 4 |
| Office power failure | 1 | 2 | 2 |
Threats with a risk rating of 6 or above deserve a specific mitigation strategy and a named owner. Lower-rated risks can sit on a watch list and be reviewed at each plan update.
Choose mitigations that match the risk
For each high-priority threat, document the specific mitigation you will put in place. A mitigation is not a vague intention such as "improve our backups." It is a concrete, verifiable action with a completion date and a named owner. For example, if ransomware scores 9, your mitigation might read: "Deploy endpoint detection and response (EDR) tooling across all staff devices by [date], owned by [IT lead]."
Thinking about how to create a business continuity plan that holds up under real pressure means closing the gap between knowing your risks and actually reducing them. Record your mitigations in the same table as your risk ratings so the threat and its response are always reviewed together.
Step 4. Define response and recovery procedures
Your risk assessment and BIA have given you the intelligence you need. Now you turn that intelligence into documented, step-by-step procedures that tell your team exactly what to do when a specific disruption hits. This is the operational core of how to create a business continuity plan that works under real pressure. Generic instructions do not hold up in a crisis. Each critical function needs its own procedure, written clearly enough that someone unfamiliar with the role can follow it without needing to make judgement calls on the fly.
Write procedure cards for each critical function
A procedure card is a concise, structured document that covers one critical function and one disruption scenario. Avoid lengthy prose. During an incident, people need to move quickly, and a well-formatted card lets them do that without re-reading paragraphs to find the key actions.
Write each procedure at the level your least experienced team member could follow independently. If it requires interpretation, rewrite it.
Use this template for each critical function:
| Field | Detail |
|---|---|
| Function | Customer billing |
| Disruption scenario | CRM system unavailable |
| RTO | 4 hours |
| RPO | 1 hour |
| Lead owner | Finance Manager |
| Deputy | Senior Finance Analyst |
| Step 1 | Switch to manual invoice log (shared drive: /billing/manual-log.xlsx) |
| Step 2 | Notify affected customers by email within 2 hours using template at /comms/billing-delay-template.docx |
| Step 3 | Contact CRM provider on [support number] and log the ticket reference |
| Step 4 | Restore from backup and reconcile the manual log once the system is live |
Repeat this structure for every Tier 1 and Tier 2 function you identified in Step 1. Tier 3 functions can use a simpler checklist format rather than a full procedure card.
Build your communication plan
Who you notify, when, and through which channel matters just as much as what your technical teams are doing in the background. A delayed or missing communication during an incident damages trust with customers and can trigger regulatory obligations you have not prepared for.
Map out your communication responsibilities in a matrix covering staff, customers, suppliers, and relevant regulators. Assign a named owner to each audience group and specify the method and timing of contact for each scenario in your plan.
Step 5. Test, train, and keep it current
A plan that has never been tested is a plan you cannot trust. Writing the procedures is only half the work. Regular testing and staff training are what convert a document into a capability your team can actually rely on when pressure is real. This is the step many organisations skip, and it is also the step that separates those that recover quickly from those that struggle to function at all.
Run regular tests
Testing does not have to mean a full-scale simulation every quarter. Different test types serve different purposes, and a layered approach across the year keeps your plan sharp without overwhelming your teams. Use the following schedule as a starting point:
| Test type | Frequency | What it checks |
|---|---|---|
| Document review | Every 6 months | Accuracy of contacts, procedures, and system details |
| Tabletop exercise | Annually | Whether your team can talk through a scenario step by step |
| Live failover test | Annually | Whether your technical recovery steps actually work |
After each test, record every gap or unclear instruction and update the relevant procedure cards before the next cycle.
A tabletop exercise that produces no list of updates is not a good sign. It usually means the scenario was not realistic enough.
Train your people
Your procedures are only useful if your named owners and deputies know they exist and understand their responsibilities before an incident happens. Run a short briefing with each function owner every time the plan changes in a meaningful way. New staff who inherit ownership roles need a structured handover, not just a link to a shared drive.
Include a basic awareness session for all staff covering what the plan is, how it gets invoked, and what each person is expected to do in the first 30 minutes of a disruption.
Keep the plan current
Understanding how to create a business continuity plan is only part of the challenge. Keeping it accurate as your organisation evolves is the ongoing commitment. Trigger a mandatory review whenever something significant changes: a new system goes live, a key supplier is replaced, a critical team member leaves, or a real incident occurs.
Set a recurring calendar reminder for a full plan review every 12 months at minimum, with a named reviewer assigned to each section.
Ready to act when disruption hits
Now you have a clear picture of how to create a business continuity plan that your team can actually use. You have defined your scope and priorities, run a business impact analysis, assessed your risks, documented recovery procedures, and built a testing schedule. Each step builds on the last, and together they give your organisation a real capability rather than a file that never gets opened.
The biggest risk at this point is delay. Disruptions do not wait for convenient timing, and the organisations that recover fastest are the ones that finished their plan before they needed it. If any part of this process feels difficult to tackle internally, whether that is identifying your risks, mapping your critical functions, or aligning your plan with ISO 27001, working with an experienced partner makes that process significantly faster and more reliable. Talk to TrustedIA about managed business continuity support and build a plan you can depend on.
