Plan template · ISO 27001
Business continuity plan template
The playbook your team opens when the office, the systems or a key supplier goes down. A ready-to-edit Word template for ISO 27001 controls A.5.29 and A.5.30, with an impact tolerance section for FCA-regulated firms, written for a UK firm of 25 to 250 people.
Key takeaways
A business continuity plan is the playbook a firm follows to keep critical activities running, or restore them within agreed times, during a disruption. ISO 27001 controls A.5.29 and A.5.30 expect continuity to be planned and tested, and FCA-regulated firms must stay within impact tolerances. This template gives a UK firm of 25 to 250 staff a ready-to-edit Word plan.
- Required by
- ISO 27001:2022 A.5.29 and A.5.30; FCA SYSC 15A for in-scope firms; DORA Article 11 for EU financial entities
- Approved by
- Top management, with a named owner and invoking authority
- Test cycle
- At least annually, and after significant change
- Format
- Word, about 18 pages, with a business impact analysis worksheet
What's in the template
One Word document, about 18 pages, version 1.0. It has four parts:
- The business continuity plan. The playbook itself, laid out in the order you'd use it on a bad day: how and when to invoke it, who does what, your critical activities with their recovery targets, a response strategy for each type of disruption (loss of premises, people, technology, data or a key supplier), keeping information secure during the disruption, ICT recovery, communications, the return to normal, and how the plan is tested and reviewed. An optional section sets out important business services and impact tolerances for FCA-regulated firms.
- A getting-started guide. It shows what to fill in first (the business impact analysis), which section is optional if you're not FCA-regulated, and what to leave alone.
- Next steps. These show where the plan sits alongside your business continuity policy, disaster recovery runbooks and incident response process, and how to plan your first exercise.
- A plan management checklist. It covers approval, distribution, offline copies, exercise dates and review dates: the records an auditor asks to see alongside the plan.
The appendices give you a business impact analysis worksheet, a contact directory, an invocation checklist with a decision log, message templates for staff, clients and suppliers, and an exercise record. Every placeholder is in square brackets, so you replace names, numbers and suppliers rather than writing from a blank page.
What is a business continuity plan?
A business continuity plan is the document your team follows to keep critical activities running, or restore them within agreed times, when something disrupts the business. It names who decides, what gets recovered first and how fast, and how you keep clients and staff informed. It's the playbook. Your business continuity policy states the commitments the plan delivers.
Auditors ask for it because ISO 27001 controls A.5.29 and A.5.30 expect continuity to be planned, implemented and tested. Customers ask for it because their own regulators make them check that you can keep serving them. A due-diligence questionnaire rarely stops at "do you have a BCP?". The next question is "when did you last test it?".
Which standards require one
| Standard | What it asks for |
|---|---|
| ISO 27001:2022, control A.5.29 | Plan how to maintain information security at an appropriate level during disruption. |
| ISO 27001:2022, control A.5.30 | ICT readiness must be planned, implemented, maintained and tested, based on business continuity objectives and ICT continuity requirements. |
| FCA operational resilience (SYSC 15A) | In-scope firms must identify their important business services, set an impact tolerance for each, and be able to remain within it during a severe but plausible disruption. Reviewed after material change, and at least every 12 months. |
| DORA, Article 11 (EU financial entities) | An ICT business continuity policy and ICT response and recovery plans, tested at least yearly and after substantive change to the ICT systems that support critical or important functions. |
| Customer due diligence | Most enterprise and financial-services questionnaires ask for the plan, its last test date and the recovery times it commits to. |
ISO 27001 doesn't name a document called a business continuity plan. But A.5.29 and A.5.30 require planning that an auditor will expect to see written down, approved and tested. For the detail on each control, see the A.5.29 guide and the A.5.30 guide.
Important business services and impact tolerances
The FCA's operational resilience rules apply to banks, building societies, insurers, PRA-designated investment firms, recognised investment exchanges, enhanced scope SM&CR firms, and payment and e-money firms. Since 31 March 2025, those firms must be able to stay within their impact tolerances.
An impact tolerance isn't the same as a recovery time objective. The recovery time objective is your internal target for restoring a system or activity. The impact tolerance is the maximum disruption an important business service can tolerate, measured as a length of time, before further disruption could cause intolerable harm to clients or put the UK financial system or orderly markets at risk. The plan has to show how the first keeps you inside the second.
If you're in scope, the template's optional section records each important business service, its tolerance and the recovery strategy that supports it. If you're not in scope but your clients are, expect them to ask for your recovery times in their outsourcing and supplier reviews. The same section answers them. The PRA has parallel rules for the firms it regulates, with its expectations set out in supervisory statement SS1/21.
How to create your business continuity plan with this template
With a business impact analysis already done, this takes two to three days of work spread over a fortnight, plus one tabletop exercise. Without the analysis, start there: it's where most of the judgement sits.
Before you start
A continuity plan describes how the business recovers, so it depends on knowing what the business runs on. Check you have:
- A list of what you'd recover first. Your critical activities, or your important business services if you're FCA-regulated, and the people, systems, data, premises and suppliers each depends on. No list yet? Your asset inventory is the starting point: see the A.5.9 guide.
- A view of what could disrupt you. Your risk assessment should already name the plausible disruptions: ransomware, a cloud outage, losing the office, losing a key person or supplier. If it doesn't, the clause 6.1 guide covers how.
- A named owner and an invoking authority. The owner keeps the plan current. The person who can invoke it needs the authority to spend money and redirect staff in the middle of a crisis, and needs a deputy. No one named yet? Ask top management to name both before you start, because a plan nobody owns goes stale and one nobody can invoke stalls in a crisis.
- Your incident response process. Most disruptions start as incidents. The plan should pick up where incident response hands over, not duplicate it. The A.5.24 guide covers the incident side. No incident process yet? Write a short one first, or the plan will end up trying to do both jobs.
If none of these exist yet, the job is bigger than one document. That's the point where most firms bring in help.
1. Run the business impact analysis (half a day to a day, with the right people in the room)
- Do this: list your critical activities, then for each ask two questions: how long can it stop before the damage is serious, and how much recent data could you lose? Record a recovery time objective and a recovery point objective, and the dependencies behind each.
- The template: includes a business impact analysis worksheet with the columns already set, and a summary table in the plan that the worksheet feeds.
- Watch for: IT setting the targets alone. Recovery times are business decisions. Put someone from operations and someone who knows the client contracts in the room, and get a director to sign the numbers.
2. Decide who invokes the plan, and when (1 to 2 hours)
Next, write down what counts as a disruption that triggers the plan, who can declare it, and who stands in when they can't. The template gives you invocation criteria, an escalation path and a decision log, so the first hour of a crisis isn't spent working out who's in charge. Name real people and real deputies. A role with no deputy is a single point of failure.
3. Write a response strategy for each type of disruption (about a day)
- Do this: for each type of loss (premises, people, technology, data and key suppliers), write what you'll do in the first hour, the first day and the first week, and how each critical activity carries on while systems are down.
- The template: organises strategies by the impact, not the cause, so one strategy for "loss of technology" covers ransomware, a cloud outage and a failed update. Information security during the disruption has its own section, for A.5.29.
- Watch for: strategies that depend on the thing that's failed. A recovery runbook stored on the encrypted file server can't be read, and a contact list that lives only in the email system that's down can't be used.
4. Plan your communications (2 to 3 hours)
Then decide who tells whom, what, and how, when your usual channels may be down. Staff need to know whether to come in. Clients need an honest update before they hear it elsewhere. If you're regulated, notifying the FCA may be part of the response. The template includes pre-drafted message templates for staff, clients and suppliers, with a who, what, when and how table for each audience. Keep a copy of the contact directory somewhere that doesn't depend on your own systems.
5. Approve, distribute and exercise (one management meeting, then a two-hour tabletop)
- Do this: take the plan to top management for approval, give everyone with a role a copy they can reach offline, then run a tabletop exercise against one realistic scenario within the first few months.
- The template: includes an exercise record and a plan management checklist for approval, distribution and review dates.
- Watch for: a plan approved and filed but never exercised, and actions from the exercise that are never closed. Both are covered in How to use it so it holds up at audit.
Do it yourself, or have us do it with you
| Do it yourself with the template | Do it with GRCMANA | |
|---|---|---|
| What you end up with | An approved business continuity plan, ready for its first exercise | The plan, the business continuity policy, a facilitated business impact analysis, recovery targets checked against your suppliers and backups, and a first exercise run with your team. For regulated firms, important business services and impact tolerances mapped and ready for your self-assessment |
| Your time | Two to three days over a fortnight, if the impact analysis and risk assessment exist. Considerably more if they don't | Less of your own time: we run the workshops and draft the documents, and your team reviews and decides |
| Best if | Someone on your team knows the business end to end and is comfortable making the recovery calls above | Continuity landed on you alongside your day job, a client or regulator is asking for evidence of testing, or you need impact tolerances that will stand up to the FCA |
Prefer the second column? Talk to us about operational resilience.
What good looks like
Most business continuity plans read well. Fewer survive the first exercise. Here is the difference.
Weak and strong, side by side
| Section | Weak | Strong | Why the strong one works |
|---|---|---|---|
| Invocation | "The plan will be invoked in the event of a major incident." | "The [COO], or [Head of Operations] in their absence, invokes this plan when any critical activity in section 4 is unavailable, or is expected to be, for longer than half its recovery time objective." | It names who decides and gives a test anyone can apply at 2am. |
| Recovery targets | "Critical systems will be restored as quickly as possible." | "Client portal: recovery time objective 4 hours, recovery point objective 15 minutes. Set in the business impact analysis of [date], signed by [CEO]." | A number can be tested. "As quickly as possible" can't. |
| Supplier dependency | "We rely on cloud providers with high availability." | "Payments run on [provider]. Its contract commits to [SLA]. If it's down for more than [x hours], we switch to [manual process], owned by [name]." | It shows the recovery time is achievable, not assumed. |
| Contacts | "Contact details are held on the intranet." | "The contact directory in Appendix A is printed and held by each plan role-holder, and a copy sits in [separate cloud account]. Checked quarterly." | It still works when the intranet is the thing that's down. |
| Testing | "The plan will be tested periodically." | "We run a tabletop exercise each [quarter/half-year] and a live restore of [system] each year. Results and actions are recorded in Appendix E." | ISO 27001 A.5.30 expects testing. A schedule and a record can be sampled. |
What an auditor checks in the first five minutes
Before reading the detail, most auditors check that:
- It's current and approved. It has a version, an approval by top management and a review date that hasn't passed.
- The targets have a source. Each recovery time traces back to a business impact analysis, not a guess.
- It's been tested. There's an exercise record from the last twelve months, with actions that were closed.
- The people are real. The named roles and deputies still work at the firm, and their contact details are correct.
- It covers security during the disruption. It says how access control, logging and data protection hold up when you're working around a failure (A.5.29).
- People can reach it. The people who'd use it know where it is, including when your systems are down.
If all six hold, the auditor moves on with confidence. If one fails, they usually look harder at everything else.
What good looks like at 25 staff and at 250
| Feature | Around 25 staff | Around 250 staff |
|---|---|---|
| Length | 8 to 12 pages, one plan for the whole firm | One core plan with team or site annexes and separate disaster recovery runbooks |
| Invoked by | The managing director, with one named deputy | A small crisis team with a rota |
| Business impact analysis | A half-day workshop covering five to ten critical activities | A structured exercise across departments, refreshed each year |
| Recovery strategy for technology | Rely on SaaS resilience, plus your own exports and a tested restore | Documented failover, immutable backups and timed restore tests |
| Exercises | One tabletop a year | Tabletops each quarter or half-year, plus an annual live test |
| Regulated firms | Impact tolerances for two or three important business services | A full mapping, scenario testing and a written self-assessment |
The common mistake at 25 staff is a plan copied from a large company that names a crisis team the firm doesn't have. The common mistake at 250 is the reverse: a plan written when the firm was small that has never caught up with its suppliers, its offices or its clients' expectations.
How to use it so it holds up at audit
The plan is only half the evidence. An auditor, a client or the FCA will test whether it works, and these are the records they usually ask for:
- The approval record: who in top management approved this version, and when.
- The business impact analysis: the signed output behind every recovery time in the plan.
- Exercise and test records: what was tested, when, what happened, and the actions that followed, with their closure status.
- Distribution: who holds a copy, including offline copies, and evidence that role-holders know their part.
- Review history: the last review, what changed, and the next review date. For regulated firms, the link to your operational resilience self-assessment.
The most common reasons a business continuity plan fails audit:
- It has never been tested, or the last test was more than a year ago.
- The recovery times have no business impact analysis behind them, or nobody signed them.
- Named people have left, and their deputies were never appointed.
- Actions from the last exercise or real incident are still open.
- It depends on systems that would be unavailable in the very disruption it's meant to handle.
- It's a generic template with another organisation's departments or suppliers still in it.
Each of these is cheap to prevent and expensive to discover in the middle of an outage.
Business continuity plan questions
How and when the plan is invoked, who does what, your critical activities with their recovery times, a response strategy for each type of disruption, how information stays secure during it, how you communicate, how you return to normal, and how the plan is tested and reviewed.
A business continuity plan keeps the whole business running: people, premises, suppliers, clients and technology. A disaster recovery plan is narrower. It restores IT systems and data, and it usually sits beneath the continuity plan as a set of technical runbooks.
The policy states the commitments: why the firm manages continuity, what's in scope, who's accountable and how often plans are tested. The plan is the playbook that delivers those commitments when something goes wrong. Most firms need both, and auditors read them together.
At least once a year, and after any significant change to the business, its systems or its key suppliers. A tabletop exercise counts as a test. Keep a record of each one, including the actions it produced and when they were closed.
People, premises, processes and providers (your suppliers and partners). They're a useful check that the plan covers more than technology: what happens if key staff are unavailable, the office is inaccessible, a process fails or a supplier goes down.
Get the template
Start from a plan laid out the way you'd use it in a crisis, written for a firm your size, with the regulated-firm sections ready if you need them. Download the Word template, run your business impact analysis, and book your first exercise.
This template is a starting point to adapt to your organisation, not legal or regulatory advice.
