What Is a Strategy for Business Continuity Planning?

A strategy for business continuity planning is the high-level decision about how your organisation will keep its critical activities running, and get them back, when something disrupts them. It sets your priorities, your recovery targets, the resources you commit and the people who decide. The plan, with its checklists and contact lists, comes afterwards and puts the strategy into action.

The distinction matters because many UK businesses write a plan without ever choosing a strategy. The result is a long document that nobody can use when systems are encrypted, a supplier fails, or a site is closed. This article explains why the strategy matters, how to build it, which recovery options to choose from, how communication and governance work in a crisis, and how to test the whole thing.

We write from the cyber security side. TrustedIA helps small and medium-sized businesses and larger organisations prepare for, respond to, and recover from incidents, so many examples focus on cyber events. The method works equally for fire, flood, supplier failure or the loss of key staff.

Why a business continuity strategy matters

A business continuity strategy matters because it moves the hardest decisions to a calm day. Which services come back first, how much data you can afford to lose and who may spend money are questions to settle before an incident. Without that groundwork, a continuity plan becomes an argument at the moment you can least afford it.

What a strategy gives you that a plan does not

A plan tells people what to do. A strategy decides what the organisation is trying to achieve and how it will get there. In practice, a sound strategy fixes five things:

• Scope: which parts of the organisation are covered, including sites, subsidiaries and critical suppliers.
• Priorities: the order in which activities are restored.
• Recovery targets: the downtime and data loss you will tolerate for each activity.
• Resources: the budget, people, locations and technology committed to meeting those targets.
• Ownership: who decides, who acts and who deputises.

Writing these down forces disagreements into the open. Finance may expect payroll back in a day while IT has budgeted for a week. It is far cheaper to discover that in a workshop than halfway through an outage.

How strategy, plan and disaster recovery fit together

People often use the three terms as if they meant the same thing. They do not, and mixing up continuity and disaster recovery planning leaves gaps. The strategy sets direction, the plan sets out actions, and disaster recovery covers the technology.

Term	Question it answers	Typical owner
Continuity strategy	What are we protecting, and what recovery outcomes do we commit to?	Board or executive sponsor
Business continuity plan	Who does what, and in which order, when disruption hits?	Continuity lead with department heads
Disaster recovery plan	How do we restore systems and data?	IT team or managed service provider

Many organisations have a disaster recovery plan and believe it covers them. Restoring a server doesn’t help if the finance team cannot approve payments, or if nobody knows who can speak to customers. Disaster recovery is one chapter, and the strategy decides how the whole book fits together.

The cost of improvising

Disruption costs add up in ways that are easy to underestimate. You lose sales while systems are down, pay staff who cannot work, may breach customer contracts, and spend senior time firefighting rather than on the business. Cyber insurers and larger customers also ask more questions about continuity than they once did, so a clear strategy can support renewals and tenders as well as recovery.

Improvised responses also tend to fail in predictable ways. The plan sits on an encrypted file share. The only person who knows the supplier’s emergency number is on holiday. Two managers give customers conflicting messages. A written strategy removes most of these failures before they happen.

A plan written in the middle of an incident is not a plan, it is a guess.

How to build a strategy for business continuity planning

Build the strategy in a fixed order: analyse impact, assess risk, set recovery targets, then choose how to meet them. The order matters because each step feeds the next. Skipping straight to solutions is the most common mistake, and it leads to spending money to protect systems nobody depends on.

Step 1: Run a business impact analysis

A business impact analysis (BIA) lists your activities and measures what happens when each one stops. Interview each department head using the same questions, so the answers can be compared:

• What does this activity produce, and for whom?
• What is the financial, legal, safety or reputational impact after one hour, one day and one week?
• Which systems, people, suppliers and premises does it depend on?
• Is there a manual workaround, and how long can people sustain it?

Record the answers in one table so the priorities become visible. The rows below are examples only, and your own figures will differ.

Activity	Impact after one day	Longest tolerable outage	Key dependencies
Order processing	Missed deliveries, customer complaints	1 working day	ERP system, warehouse scanners, courier link
Payroll	Low, then rising sharply near pay date	3 working days	HR system, bank portal
Marketing website	Minor	5 working days	Hosting provider, content system

Step 2: assess the risks to those activities

Once you know what matters, ask what could take away each dependency. Group threats by their effect, not their cause. Loss of premises, loss of IT, loss of people and loss of a supplier cover almost everything. Ransomware, a power failure and a faulty update all produce the same result for the business: IT is unavailable.

Planning around effects keeps the strategy short and stops it going out of date every time a new threat appears. Score each effect for likelihood and impact on a simple scale of one to five, then look hard for single points of failure. Typical examples are one administrator who holds all the passwords, one internet line, one backup location or one supplier with no alternative.

Step 3: set recovery targets

Three measures give you the vocabulary for defining RTO and RPO targets. The recovery time objective (RTO) is how long an activity can be down before you must have it back. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose. The maximum tolerable period of disruption is the ceiling beyond which the organisation suffers unacceptable harm, and every RTO should sit comfortably inside it.

Grouping activities into tiers keeps the discussion manageable. These figures are illustrative starting points.

Tier	Example activities	Example RTO	Example RPO
1 Critical	Online payments, customer-facing platform	Under 4 hours	Minutes
2 Important	Order fulfilment, finance approvals	1 working day	Up to 4 hours
3 Supporting	HR administration, internal reporting	3 working days	1 working day
4 Deferrable	Archive access, marketing website	1 to 2 weeks	1 working day or more

Your own targets must come from your BIA, not from this table. Tighter targets cost more, so senior management should sign them off with the cost in mind.

Every recovery target is a price tag, so set it from the impact, not from what sounds safe.

Recovery strategies and procedures that work under pressure

Once targets are set, choose for each activity the cheapest recovery option that reliably meets its RTO and RPO. Then write procedures short enough to follow when people are stressed and tired. This is where business continuity planning becomes something your team can actually execute.

Matching recovery options to your targets

Each option below trades cost against speed. Most organisations combine several, because paying for instant failover on a tier 3 system wastes budget.

Option	How it works	Suits	Main trade-off
Manual workaround	Paper forms, spreadsheets, phone-based processes	Tier 3 and 4, short outages	Slow, error-prone, hard to scale
Remote working	Staff work from home on secured devices	Loss of premises	Needs tested remote access and enough devices
Backup and restore	Rebuild systems and restore data from offline or immutable copies	Most tier 2 and 3 systems	Recovery time depends on data volume and rebuild speed
Replication and failover	A second environment kept in sync and switched on	Tier 1 systems	Highest cost and complexity
Alternative site or supplier	Second premises, spare capacity, pre-agreed substitute	Loss of premises or supplier	Contracts must exist before the event

Test the match honestly. If a system has a four-hour RTO but restoring it from backup takes two days, you have a gap, not a strategy.

Writing procedures people will use

Keep procedures to one page per scenario, triggered by effect, for example “loss of core IT systems” or “premises unavailable”. Long manuals go unread in a crisis. The template below can be copied into a document for each scenario.

Scenario: 
Owner and deputy: 
Activation trigger: 
First 60 minutes: 
Activities affected and their RTOs: 
Workarounds in use: 
Recovery steps, in order: 
Who must be told, and when: 
Decisions needed from the crisis team: 
Evidence to keep (logs, times, costs): 

The last line is easy to forget and valuable later. Insurers, auditors and regulators will all want a timeline of what happened and what it cost, and it is much easier to record as you go than to reconstruct afterwards.

Why cyber incidents need their own recovery thinking

In a cyber incident, you cannot trust your own systems. Restoring straight from backup into the same environment can hand the attacker their access back. Your procedure should say: isolate affected systems, preserve evidence, rebuild from clean images, reset credentials, and only then restore data from a point before the compromise.

Backups need the same scrutiny. Follow the 3-2-1 rule: three copies of your data, on two types of storage, with one held offsite. Keep at least one copy offline or immutable so that an attacker with administrator rights cannot delete it. Then restore from it on a schedule, because a backup you have never restored is an assumption. Finally, decide in advance who you will call for incident response and what your insurer’s helpline requires, so nobody is searching for numbers on the day.

Test the restore, not the backup job: only a restore proves you can recover.

Communication and governance during a disruption

Name a small crisis team with clear decision rights, and give it pre-agreed ways to reach staff, customers, regulators and insurers. A technical recovery can succeed while the response fails, simply because nobody could authorise spend or tell customers what was happening. Good business continuity planning treats both as part of the strategy.

Governance: who decides

Define crisis team roles and responsibilities, not just names, and appoint a deputy for each. A workable crisis team for most small and medium-sized organisations has five roles:

• Crisis lead: owns the response and makes the final call.
• Recovery lead: directs technical and operational restoration.
• Communications lead: controls all messages going out.
• Legal and compliance lead: advises on notification duties and contracts.
• Log keeper: records decisions, times and costs as they happen.

Write down which decisions the team may take without further approval. Examples include taking systems offline, appointing external responders, spending above normal limits, notifying a regulator and responding to any ransom demand, which should involve legal advice and your insurer. Senior management should approve the strategy and review it at least once a year, because accountability for resilience sits with them, not with IT.

Communication: who hears what, and when

Different audiences need different information, delivered through channels that still work. Draft holding statements for your likely scenarios in advance, so the communications lead edits rather than writes from scratch.

Audience	What they need	Channel	Owner
Staff	What has happened and what to do now	Out-of-band messaging group or text message	Crisis lead
Customers	Impact, expected timescale, workaround	Website status notice, email, account managers	Communications lead
Regulators	Required formal notification	Official reporting route	Legal and compliance lead
Insurer	Notification as the policy requires	Broker or claims helpline	Crisis lead

Some data breach notification duties run on a clock. If a personal data breach is likely to put individuals at risk, UK GDPR requires you to tell the ICO within 72 hours of becoming aware of it. Firms regulated by the FCA or operating essential services may have further duties. Many cyber policies also require prompt notice and the use of approved responders, so read your wording now, not during the incident.

Keep the plan reachable

A continuity plan stored only on the systems that have failed is useless. Keep an offline copy with each crisis team member, print the contact list, and agree on a fallback channel that doesn’t rely on your normal email or phone system. Then check that people can actually open and use it. This small step catches more problems than most organisations expect.

If your plan lives only on the systems it is meant to recover, you do not have a plan.

How to test, review and maintain the strategy

Test at least once a year and after every significant change, because an untested strategy is only a set of assumptions. Testing is also the cheapest way to find the gaps in your strategy for business continuity planning before a real disruption does.

Exercises, from light to realistic

Start small and build up. Each type of exercise reveals different weaknesses.

Exercise	What it involves	Effort	What it reveals
Desktop walkthrough	Plan owners read through the plan together	About an hour	Outdated contacts, missing steps
Tabletop scenario	A facilitator introduces events and the crisis team discusses its decisions	Half a day	Gaps in decisions and communication
Technical recovery test	Restore a system and its data from backup into an isolated environment, and time it	Several days	Whether your RTO and RPO are realistic
Live simulation	Staff operate on alternative arrangements or respond to a simulated attack	Weeks of preparation	Operational readiness under strain

Begin with a tabletop exercise for the crisis team, including senior leaders. A good scenario is ransomware discovered on a Friday evening, because it tests decisions, communication, and weekend cover all at once.

Measuring and reviewing

After each exercise, record the actual recovery times against your targets, list what failed, and give each action an owner and a date. Without owners and dates, findings fade into a report nobody reads. Beyond the annual review, update the strategy when any of these happen:

• You adopt a new system, supplier or cloud service.
• You acquire a business, move premises or open a new site.
• A named role-holder leaves or changes job.
• You suffer a major incident or a near miss.
• Regulation or customer requirements change.

Standards and guidance worth aligning with

You don’t need certification to run an effective strategy, but recognised standards provide structure. ISO 22301 is the international standard for business continuity management systems. The UK Government publishes a business continuity management toolkit that works well as a plain-language starting point. If you hold or are pursuing ISO 27001, the 2022 edition of Annex A includes controls on information security during disruption (5.29) and ICT readiness for business continuity (5.30), so continuity work counts towards your certification.

If you are regulated by the FCA or PRA, the operational resilience rules ask you to identify important business services and set impact tolerances. Those map closely onto the impact analysis and recovery targets described above, so one piece of work can serve both purposes.

Alignment with a standard is not the goal, but it gives customers, insurers and auditors something they recognise.

Where to start

A business continuity planning strategy comes down to a handful of early decisions: what matters most, how long you can be without it, how you will recover it, who is in charge, and how you will talk to people. Make those decisions in that order, write them down on a few pages, and prove them with an exercise. A short strategy that has been tested beats a thick binder that has not.

If you want help with the cyber side, from backup and recovery design to incident response, you can speak to TrustedIA about business continuity and recovery support.