---
title: "Business continuity policy template"
canonical: https://www.grcmana.io/vault/templates/business-continuity-policy
published: 2023-12-15
updated: 2026-10-17
author: "Harry West"
framework: "ISO 27001"
type: "Policy"
---

# Business continuity policy template

## Key takeaways

A business continuity policy is where top management commits the firm to managing continuity: scope, accountability, how recovery objectives are set and how often plans are tested. ISO 27001 controls A.5.29 and A.5.30 expect continuity to be planned and tested against those objectives. This template gives UK firms of 25 to 250 staff a Word starting point.

- **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
- **Review cycle** — At least annually, and after significant change
- **Format** — Word, about 9 pages, with a policy management checklist

## What's in the template

One Word document, about nine pages, version 1.0. It has four parts:

1. **A getting-started guide.** It shows what to fill in first (the roles and the scope), when to drop the optional operational resilience section (if you're not FCA-regulated), and what to leave alone, including the commitments in section 3.
2. **The business continuity policy.** Your commitments, laid out the way an ISO 27001 auditor reads them: purpose and scope, leadership's commitment, how continuity objectives are set, roles and responsibilities, the plans the policy requires, information security during disruption, testing and exercising, training, exceptions, and how the policy is approved, communicated and reviewed. An optional section covers operational resilience for FCA-regulated firms.
3. **Next steps.** These cover writing the business continuity plan to match, running the business impact analysis behind your recovery objectives, booking the first exercise and restore test, and adding continuity to your management review.
4. **A policy management checklist.** It covers approval, communication, the testing calendar and review dates: the records an auditor asks to see alongside the policy.

Every placeholder is in square brackets, so you replace names, services and cadences rather than writing from a blank page.

## What is a business continuity policy?

A business continuity policy is the short document in which leadership states why the firm manages continuity, what it covers, who is accountable, how recovery objectives are set and how often the arrangements are tested. It doesn't say what to do when the office floods. That's the job of the [business continuity plan](https://www.grcmana.io/vault/templates/business-continuity-plan), the playbook that delivers the policy's commitments on the day.

Auditors read the policy first because it tells them what to test. Every commitment in it becomes a question: show me the business impact analysis, show me last year's exercise, show me who approved the recovery times. Clients ask for it in due-diligence questionnaires for the same reason. It tells them whether continuity is owned at the top or left to 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. |
| ISO 27001:2022, control A.5.1 | Topic-specific policies must be defined, approved by management, published, communicated to and acknowledged by relevant staff, and reviewed at planned intervals. A business continuity policy is usually one of them. |
| 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, put into effect through ICT response and recovery plans. |
| ISO 22301 (business continuity management) | A documented business continuity policy, if you certify to ISO 22301 as well. |
| Customer due diligence | Financial-services clients in particular ask for the policy, the date it was approved and the date of the last test. |

ISO 27001 doesn't name a document called a business continuity policy. But A.5.29 and A.5.30 expect continuity to be planned and tested against objectives, and an auditor will look for the place where leadership set those objectives and committed to the testing. For the detail on each control, see the [A.5.29 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-29-information-security-during-disruption) and the [A.5.30 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity).

### Where the policy ends and the plan begins

The policy and the plan answer different questions. Keep each to its own job, and use the same terms, roles and cadences in both.

| Question | The policy says | The plan says |
| --- | --- | --- |
| Why do we manage continuity? | The commitment, signed by top management | Nothing; it assumes the commitment |
| What's covered? | The scope: services, sites and suppliers | The critical activities within that scope, one by one |
| How fast must we recover? | How recovery objectives are set and who approves them | The recovery time and recovery point for each activity |
| Who is accountable? | The owner, the sponsor and who may invoke the plan | Named people, deputies and contact details |
| How often do we test? | The minimum cadence and where results are reported | The exercise schedule, scenarios and records |

Write a recovery time into the policy and you'll be re-approving the policy every time a system changes. Numbers belong in the plan. The policy says how they're set.

### FCA operational resilience: what the policy commits to

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.

For an in-scope firm, the policy is where leadership commits to the cycle the rules describe: identify important business services, set an impact tolerance for each, map the people, processes, technology and suppliers behind them, test against severe but plausible scenarios, and record it all in a self-assessment. It also says who approves that self-assessment: the rules require the governing body to approve and regularly review it (SYSC 15A.7). The plan then shows how each service is kept inside its tolerance.

If you're not in scope but your clients are, the optional section still earns its place. Their outsourcing and supplier reviews will ask how you support their important business services, and the policy is where you show it's owned at the top.

## How to create your business continuity policy with this template

With the groundwork in place, this takes about half a day plus one management meeting. The policy is short. The judgement is in making every commitment one the firm will actually keep.

### Before you start

A continuity policy commits the firm to something, so you need to know what it can deliver. Check you have:

- **An ISMS scope statement.** The policy's scope should sit inside it and use the same words. No scope statement yet? Write that first: see the [clause 4.3 guide](https://www.grcmana.io/vault/iso-27001/clause-4-3-determining-the-scope-of-the-information-security-management-system).
- **A rough list of what matters most.** You don't need a finished business impact analysis, but you need to know which services clients would miss first. The [business continuity plan template](https://www.grcmana.io/vault/templates/business-continuity-plan) includes the worksheet for the full analysis.
- **A sponsor in top management.** Someone who can approve the policy, the recovery objectives and the money behind them. An IT manager can own the work but can't make these commitments. No sponsor yet? Find one before you draft, because a policy nobody senior will sign can't be approved.
- **A view of what could disrupt you.** Your risk assessment should name the plausible disruptions: ransomware, a cloud outage, losing the office, losing a key supplier. If it doesn't, the [clause 6.1 guide](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) covers how.

If none of these exist yet, the job is bigger than one document. That's the point where most firms bring in help.

**1. Name the sponsor, the owner and who may invoke** *(15 minutes)*

- **Do this:** put names against the sponsor (top management), the policy owner, and the role that may invoke the business continuity plan, with a deputy.
- **The template:** has these roles and their responsibilities laid out, with placeholders that match the roles in the business continuity plan template.
- **Watch for:** making continuity an IT responsibility. Technology recovery is one part of it. Premises, people, suppliers and client communications aren't IT's to decide.

**2. Set the scope** *(30 to 60 minutes)*

Next, say which services, sites, teams and suppliers the policy covers, in words that match your ISMS scope statement. The template gives you the structure and a placeholder for the services in scope. Start from the services clients pay for, then follow each one to the suppliers it depends on.

> **Where most firms get stuck:** a scope that stops at the office door. The services clients depend on most often run on a cloud platform, a payments provider or an outsourced IT firm. If those dependencies sit outside the policy, so does most of the real risk, and a client's due-diligence team will notice before the auditor does.

**3. Write the commitments and how objectives are set** *(about an hour)*

- **Do this:** confirm what leadership commits to (keeping critical services running within approved recovery objectives, maintaining information security during disruption, meeting legal, regulatory and contractual requirements, and improving continually), then say how recovery objectives are set and who approves them.
- **The template:** has these commitments written in, with the A.5.29 commitment on security during disruption in its own clause, and an objectives section that points to the business impact analysis rather than repeating its numbers.
- **Watch for:** promises with no mechanism behind them. "We will recover within four hours" is a promise. "Recovery objectives are set through a business impact analysis and approved by the CEO" is a mechanism an auditor can test.

**4. Set the testing and review cadence** *(20 minutes)*

Then decide the minimum: how often each plan is exercised, how often ICT recovery is tested, and where results are reported. The template sets an annual exercise and an annual restore test as defaults, plus a test after significant change, with results reported to the management review. Choose a cadence you'll meet in a bad year, not a good one.

> **Where most firms get stuck:** a testing commitment written to impress. "All plans are tested quarterly" reads well in a client questionnaire. Then the auditor asks for the four exercise records from last year, and there's one. The cadence in the policy is the standard you'll be held to, so set it where you can evidence it.

**5. Approve, communicate and connect it to the plan** *(one management meeting, then 1 to 2 hours)*

- **Do this:** take the policy to top management for approval and set the next review date, no more than a year out. Publish it, ask staff in scope to confirm they've read it, and check that the business continuity plan uses the same roles, scope and cadence.
- **The template:** includes a policy management checklist for the approval, communication, testing calendar and review records.
- **Watch for:** a policy and a plan that disagree. Different owners, a different scope or a different test cadence in each tells an auditor the two were never read together. More in [How to use it so it holds up at audit](#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 policy, ready for your plan to deliver | The policy and the business continuity plan, written together and consistent, with a facilitated business impact analysis behind the recovery objectives. For regulated firms, important business services and impact tolerances set and ready for your self-assessment |
| Your time | Half a day plus a management meeting, if the groundwork is in place. Considerably more if it isn't | Less of your own time: we run the workshops and draft the documents, and your team reviews and decides |
| Best if | Your scope is settled and someone senior is ready to make the commitments above | Continuity landed on you alongside your day job, a client or the FCA is asking for evidence, or the plan doesn't exist yet either |

Prefer the second column? [Talk to us about operational resilience](https://www.grcmana.io/contact).

## What good looks like

Most business continuity policies say the right things. Fewer say things the firm can prove. Here is the difference.

### Weak and strong, side by side

| Clause | Weak | Strong | Why the strong one passes |
| --- | --- | --- | --- |
| Commitment | "The company is committed to business continuity." | "The \[board\] commits to keeping the services in scope running within the recovery objectives it approves, to maintaining information security during disruption, to meeting legal, regulatory and contractual continuity requirements, and to continually improving these arrangements." | It says what is committed and covers security during disruption (A.5.29). |
| Scope | "This policy applies to all business operations." | "This policy covers the services listed in \[the business impact analysis\], including the parts delivered by \[named key suppliers\], at \[locations\], within our ISMS scope." | It can be checked against the ISMS scope, and the supplier dependencies are inside it. |
| Objectives | "We aim to recover from any disruption as quickly as possible." | "Recovery time and recovery point objectives are set through a business impact analysis, approved by the \[CEO\], reviewed each year and recorded in the business continuity plan." | A.5.30 bases ICT readiness on business continuity objectives. This says where they come from. |
| Roles | "IT is responsible for business continuity." | "The \[board\] approves this policy. The \[COO\] owns the continuity programme and may invoke the plan, with the \[Head of Operations\] as deputy. Plan owners keep their sections current." | Continuity is a business responsibility, and named roles can be sampled. |
| Testing cadence | "Plans will be tested regularly." | "Each plan is exercised at least once a year and after significant change. ICT recovery is tested by a restore at least \[annually\]. Results and actions are reported to the management review." | A cadence and a reporting line can be tested. "Regularly" can't. |

### What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

1. **It's current and approved.** It has a version, an approval by top management and a review date that hasn't passed.
2. **The scope matches.** It sits inside the ISMS scope and covers the services clients depend on, suppliers included.
3. **The commitments include security.** It commits to maintaining information security during disruption, not only to getting systems back.
4. **The objectives have a source.** It says how recovery objectives are set, and the business continuity plan carries them.
5. **The cadence has been met.** The exercise and test records match what the policy promises.
6. **The policy and the plan agree.** Same owner, same scope, same roles, same test cadence.

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 | Two to three pages | Three to five pages, with the detail in plans and annexes |
| Approver | The managing director | The board or executive committee |
| Owner | A director who holds it alongside their main role | A named resilience, risk or operations lead |
| Plans it governs | One business continuity plan for the whole firm | A core plan, team or site annexes and ICT recovery runbooks |
| Testing cadence | One tabletop and one restore test a year | Exercises each quarter or half-year, plus annual live tests |
| Regulated firms | Impact tolerances for two or three important business services | A full operational resilience framework, scenario testing and a written self-assessment |

The common mistake at 25 staff is a policy that promises a programme the firm can't run: a crisis team, quarterly exercises, a continuity manager who doesn't exist. The common mistake at 250 is a policy that never grew up with the firm, still silent on the suppliers and services that now carry most of the risk.

## How to use it so it holds up at audit

The policy is the promise. The records are the proof, and these are the ones an auditor, a client or the FCA usually asks for:

- **The approval record:** who in top management approved this version, and when.
- **Acknowledgement:** evidence that staff in scope have read it, and that people with a role know what it is.
- **Evidence the cadence was met:** exercise and restore-test records that match what the policy promises, with actions tracked to closure.
- **Management review minutes:** continuity results reported to top management, as the policy says they will be. The [clause 9.3 guide](https://www.grcmana.io/vault/iso-27001/clause-9-3-management-review) covers the review itself.
- **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 policy fails audit:**

- It promises a test cadence the firm hasn't met.
- It and the business continuity plan disagree on owners, scope or cadence.
- It was approved by IT, not top management, or never formally approved.
- Its scope leaves out the suppliers the critical services run on.
- It covers getting systems back but says nothing about security during the disruption.
- It's more than a year old, and nothing shows it was reviewed.

Each of these is cheap to fix at the desk and expensive to explain in the audit room.

## Business continuity policy questions

### What should a business continuity policy include?

Its purpose and scope, leadership's commitment, how recovery objectives are set and approved, who is responsible and who may invoke the plan, the plans it requires, how information security is maintained during disruption, the minimum testing cadence, and how the policy is approved, communicated and reviewed.

### Who should approve a business continuity policy?

Top management, such as the CEO, managing director or board. The policy commits the firm to recovery objectives and the spending behind them, so the approver needs that authority. An IT or operations lead can own and maintain it.

### How often should a business continuity policy be reviewed?

At least once a year, and after any significant change to the business, its services, its key suppliers or its risks. A real disruption or an exercise that exposes a gap should also trigger a review. Keep a record of each review, even when nothing changes.

### How long should a business continuity policy be?

Short. Two to five pages is typical for a firm of 25 to 250 people. The policy sets commitments and responsibilities; the procedures, contacts and recovery times belong in the business continuity plan.

### Does a small firm need a separate business continuity policy?

It needs the commitments written down and approved somewhere. Some small firms put them in a short section of the business continuity plan. A separate policy makes them easier to approve, review and show to clients on their own, which is why most firms keep one.

## Get the template

Start from a policy that already says what an auditor and a regulated client expect, written for a firm your size and built to match the business continuity plan. Download the Word template, put your names and services in, and take it to your next management meeting.

*This template is a starting point to adapt to your organisation, not legal or regulatory advice.*