FCA, 2025
27%
of incidents reported to the FCA in 2025 came from a third party
Business continuity plan: what it must contain
And where a plan stops being enough.
What a business continuity plan is, the sections every plan needs, the question a regulator or auditor will ask about each one, and a worked example marked up to show where a well-written plan still falls short.
What is a business continuity plan?
A business continuity plan is the document that sets out how an organisation keeps its most important services running, or brings them back, when something disrupts normal operations. It matters because the plan is what a team reaches for at 2am, and what a regulator or auditor reads afterwards to judge whether the response was prepared or improvised. Drova's RunReady module holds continuity plans alongside the services, dependencies and test results they describe, so the plan stays current rather than filed.
A good plan answers four questions before anyone needs it: what matters most, what it depends on, how long it can be down, and who does what when it is. The sections below set out how a plan answers each of those, and the question that will be asked of every section once the plan is in use.
Who is this page for?
If you run a small organisation and need a plan to fill in this week, the free government templates are good and you should use them. The UK Government publishes a business continuity plan template and checklist as a Word document, and the Australian Government's business.gov.au publishes an emergency management plan template with a continuity plan section, also as a Word document. Both cover contacts, critical activities and recovery steps, and both are free.
This page is for the organisations those templates stop short of: lenders, insurers, credit unions, superannuation and pension providers, payment firms, and the operations, risk and resilience teams inside them. For those organisations a plan is still necessary, and a regulator will also ask what sits around it. That second question is where most plans fall short, and it is what the rest of this page is about.
Disruption arrives through the dependency you did not map
FCA, 2025
40%
of cyber incidents reported to the FCA in 2025 involved a third party
NCSC, 2025
204
nationally significant cyber attacks in the year to August 2025, up from 89
Third parties sit behind a growing share of the incidents regulators see, which is why the dependency section of a plan carries more weight than it used to.
Why does a plan on its own fall short?
Because the regulators that supervise financial services stopped asking whether a plan exists and started asking what it protects, how long that can be down, and whether anyone has tested the answer.
In the UK, the FCA's policy statement PS21/3 asks firms to identify their important business services, set an impact tolerance for each, map what those services depend on, test them against severe but plausible scenarios and record the lot in a self-assessment. The rules have been in force since 31 March 2022 and the transitional period ended on 31 March 2025, so this is the standing expectation, not a project with a deadline. In Australia, APRA's prudential standard CPS 230 Operational Risk Management, in force since 1 July 2025, treats the business continuity plan as one of three pillars alongside operational risk management and service provider management, and asks for critical operations, tolerance levels and a testing programme around it. ISO 22301, the international standard for business continuity management, makes the same point in its own way: the plan is one output of a management system, not the system itself.
A plan that was written to be filed answers the first question well. The ten sections below are written to answer all three.
What must a business continuity plan contain?
Ten sections. Each card gives what the section covers, and the question you will be asked about it by an auditor, a regulator or your own board once the plan is in use.
Purpose, scope and objectives
What the plan is for, which parts of the organisation and which services it covers, and what a successful response looks like in measurable terms.
The question: Which of your services does this plan protect, and which does it leave out on purpose?
Governance, roles and authority
Who activates the plan, who leads the response, who can spend money and make decisions, and who stands in when they are unavailable.
The question: If the named lead is the person on the plane, who decides?
Critical services and their dependencies
The services that matter most and everything each one relies on: people, systems, data, premises, suppliers. In regulatory language, important business services or critical operations, and their mapping.
The question: Which third parties sit behind these services, and are they in the plan?
Business impact analysis and recovery objectives
How quickly each service must return and how much data loss is acceptable, usually written as recovery time and recovery point objectives, and the point at which disruption becomes intolerable to customers or the market.
The question: Where did these numbers come from, and when were they last revisited?
Risk scenarios
The disruptions the plan is designed for: supplier failure, cyber attack, loss of premises, loss of key people, data corruption, a payments outage. Written so a team recognises the situation it is in.
The question: Which of these have you tested, and were they severe enough to learn anything?
Response and recovery procedures
The ordered actions for each scenario, from activation through to recovery, with the information and resources each step needs. This is the part a team reads under pressure, so it is written for that moment.
The question: Could someone who did not write this plan run it?
Communications and contact tree
Who is told what, when, and by whom: staff, customers, regulators, suppliers, media. Contact details that are checked rather than assumed, and a notification path that still works when the usual channels are down.
The question: Does your regulator's notification deadline appear in this section?
Third parties and suppliers
The suppliers each critical service depends on, their own continuity arrangements, the contractual commitments you can rely on, and what you do if they fail. Increasingly the heart of the plan rather than an appendix.
The question: If your main service provider went down this afternoon, what does the plan say you do?
Testing and exercising
How the plan is exercised, how often, against which scenarios, and what happened last time. Desk-based walkthroughs, simulations and live tests, each with a record of what broke and what was fixed.
The question: Show us the last test, and what changed because of it.
Maintenance and review
Who owns the plan, how often it is reviewed, what triggers an unscheduled review, and how changes to the business find their way into the document.
The question: What has changed in the business since this version, and is it reflected here?
See the plan next to the services it protects
Drova RunReady
RunReady maps your critical services and their dependencies, runs scenario tests against your tolerances, and keeps the continuity plan beside the evidence it rests on.
A worked example: the plan as written
The plan below is a composite, not a customer. It is the kind of plan we see most often: competent, approved, and written to be filed. The extracts are short, and the gaps are marked in the next section.
Scope. "This plan covers the operations of the lender, with 180 staff across two offices, and applies to all business units."
Critical functions. "Lending origination, member servicing, payments processing, treasury, finance and HR are classified as critical. Each function has a recovery time objective of 48 hours."
Response. "On activation, the crisis management team convenes at the alternate site or by conference call. Function heads invoke their recovery procedures. IT restores systems from backup in priority order."
Suppliers. "Key suppliers are listed in Appendix C. Contracts include business continuity clauses."
Testing. "The plan is reviewed annually by the Risk Committee. A desktop exercise was completed in the last review cycle."
Where this plan falls short of the questions regulators ask
Nothing in the plan above is wrong. Read against PS21/3 or CPS 230, four things are missing.
- Everything is critical, so nothing is. Six functions share one 48-hour recovery objective. A regulator will ask which services cause intolerable harm to customers if they stop, and how long each can be down before that point. Payments and member servicing almost certainly cannot wait 48 hours; HR almost certainly can. The plan does not know the difference, so the response team will not either.
- The dependencies are a list, not a map. Appendix C names suppliers. It does not say which service each one holds up, what happens to that service if the supplier fails, or how the lender would know. Under CPS 230 the material service providers behind critical operations have to be identified, registered and managed; under PS21/3 the mapping is the point. "Contracts include business continuity clauses" is a statement about the contract, not about the service.
- The test did not test anything. One desktop exercise, scenario unstated, result unrecorded. Both regimes expect testing against severe but plausible scenarios, and expect to see what the test found and what changed. A walkthrough that confirms the plan reads well tells you the plan reads well.
- The plan is a document, so it ages. Annual review by committee means the plan describes the business as it was at the last review. A new core banking supplier, a merged function or a changed payment rail reaches the plan up to a year later, if someone remembers. That lag is where plans fail in practice.
None of this makes the plan useless. It makes it a continuity plan, and the questions above are resilience questions. That gap is what the next section is about.
Which regime asks these questions of you?
Two regulators, one set of questions
The FCA's PS21/3 and APRA's CPS 230 use different words for the same expectations. Each page sets out what its regulator asks for in full.
Where a plan stops and resilience begins
A continuity plan asks how you recover after something goes wrong. Operational resilience asks which services must not stop, how long they can be down before the harm is intolerable, what they depend on, and whether you have proved you can stay inside that limit. The plan is one of the answers. It is not the question.
In practice the move from one to the other is four pieces of work the plan above has not done: choosing the services that matter most and saying so, setting a tolerance for each and testing against it, mapping the dependencies down to the supplier, and keeping all of it current as the business changes. Regulators in the UK and Australia now ask for exactly this. ISO 22301 has asked for most of it for years.
The regimes differ in vocabulary. The FCA's PS21/3 regime talks about important business services and impact tolerances. APRA's CPS 230 talks about critical operations and tolerance levels. If you report to one of them, those pages set out what each expects. If you do not, the questions are still the right ones, and they are the ones your board will ask after the first real disruption.
How RunReady treats a continuity plan
RunReady is the operational resilience module of Drova's RunGood platform. It identifies what is critical to your business, maps where you are exposed and helps you prepare for disruption, from supplier failures to cyber breaches to system outages, aligned to APRA's CPS 230 and the FCA's PS21/3.
- Services and dependencies, mapped. Each critical service is linked to the people, systems and suppliers it relies on, so the dependency section of the plan is a live view rather than an appendix.
- Scenarios, tested against tolerances. Run a severe but plausible scenario against a service and record whether it stayed within tolerance, with the result kept beside the plan.
- Continuity planning and recovery workflows. The plan, its owners and its evidence live in one place, and review and test dates are tracked as tasks rather than remembered.
The plan still gets written. It just stops being the only thing you have.
Business continuity plans, answered
What should a business continuity plan include?
Ten things: purpose and scope; governance, roles and authority; critical services and their dependencies; a business impact analysis with recovery objectives; the risk scenarios it covers; response and recovery procedures; communications and a contact tree; third parties and suppliers; testing and exercising; and maintenance and review. The section above gives the question each one has to answer.
How often should a business continuity plan be tested?
At least once a year, and after any material change to the business, its suppliers or its systems. Regulated firms are held to that as a minimum: PS21/3 expects ongoing scenario testing and an annual review of the self-assessment, and CPS 230 expects a testing programme whose results reach the board. A test that produces no findings is usually a sign the scenario was not severe enough.
What is the difference between a business continuity plan and a disaster recovery plan?
Business continuity covers the services and how they keep running or come back; disaster recovery covers the technology that restores systems and data. A continuity plan usually contains or references the disaster recovery plan. Our business continuity guide covers the wider discipline.
Who owns a business continuity plan?
An executive sponsor is accountable, usually the chief operating officer or chief risk officer. A named owner maintains the document, and each critical service has a function lead who owns its part. Under CPS 230 the board is ultimately accountable for operational risk management, which includes continuity; under PS21/3, senior managers carry that responsibility through the Senior Managers and Certification Regime.
What is a business impact analysis?
The exercise that identifies the services that matter most, what each one depends on, and how quickly it has to recover before the harm becomes intolerable. It produces the recovery objectives and tolerances the rest of the plan uses. ISO 22301 treats it as the step that comes before planning, not part of it.
Is a business continuity plan a legal requirement?
It depends on who regulates you. APRA-regulated entities must maintain a credible business continuity plan under CPS 230. Firms in scope of the FCA's PS21/3 must be able to stay within their impact tolerances, which in practice requires one. Outside regulated sectors there is usually no statutory requirement, though contracts, insurers and ISO 22301 certification often expect a plan.
Do small organisations need a business continuity plan?
Yes, and a short one is better than none. The free templates from the UK Government and the Australian Government are the right starting point: contacts, critical activities, recovery steps, and a date to review it.
RunReady keeps critical services, dependencies, tests and the continuity plan in one place.
Keep the plan alive, not filed
Operational resilience hub
Explore related topics
Business continuity guide
What business continuity is and how the discipline works.
FCA operational resilience
What PS21/3 requires of UK firms.
APRA CPS 230
What CPS 230 requires of Australian entities.
Impact tolerance
Set the limit a service must not cross.
Scenario testing
Exercise the plan to find the gaps.
Important business services
Decide which services the plan protects first.
