A free, editable business continuity plan — business impact analysis, recovery objectives, continuity procedures, and testing. The structure most assessors and enterprise clients expect to see, not just a description of what one should contain.
This is a generic starting point, not a finished plan. A continuity plan is only useful if it names your actual critical functions, real recovery objectives, and real people — every bracketed section needs filling in from a genuine business impact analysis, not guessed.
A plan that's just a folder of good intentions isn't a plan — when a disruption actually happens, decisions need to be fast and the arrangements need to already exist. At minimum, a usable plan defines: which functions are genuinely critical and why, how quickly each one needs to recover, exactly how that recovery happens, and evidence that it's actually been tested.
The template below covers each of those, in the structure most assessors and Fortify's own Policy Engine use.
Business Continuity Plan — [Company Name]
This plan sets out how [Company Name] will continue to operate — or recover as quickly as possible — during and after a major disruption to our people, premises, systems, or suppliers. It applies to all critical business functions listed in Section 2.
A "disruption" covers any event that stops or seriously impairs normal operations — a cyber incident, loss of a key system or supplier, premises becoming unusable, or the sudden unavailability of key staff.
The following functions have been assessed as critical to the business, with the impact of losing each one for one day and for one week:
[Function name] — Owner: [role]. Impact at 1 day: [describe]. Impact at 1 week: [describe]. Dependencies: [systems, suppliers, people, data].
[Repeat for each critical function — typically 4–8 for a small business. Include functions that generate revenue, that customers directly depend on, and any single point of failure — one system or one person the business can't operate without.]
For each critical function above, the following recovery objectives apply:
[Function name] — Maximum Tolerable Period of Disruption: [e.g. 2 working days]. Recovery Time Objective (RTO): [e.g. 4 hours]. Recovery Point Objective (RPO): [e.g. up to 1 hour of data loss].
[Set these per function, not once for the whole business — a function that could disrupt payroll or safety needs a far tighter objective than one that's merely inconvenient. Note any regulatory or contractual minimums that apply — some sectors and client contracts specify their own.]
For each critical function, or each disruption scenario, the following arrangements apply:
[Scenario, e.g. "Office unavailable"] — Immediate response: [first actions, by whom]. Alternative arrangements: [remote working, alternative premises, backup supplier]. Communication: [who tells whom, internally and externally]. Recovery: [how the function is actually restored, referencing the RTO/RPO above].
[Repeat per scenario. Name real roles, not just "the IT team" — a plan that only exists as good intentions in someone's head isn't a plan when the person who understands it is unreachable.]
This plan is tested at least [annually], with a mix of tabletop discussion exercises for less critical functions and full simulations or technical recovery tests for the highest-priority ones.
Last tested: [date]. Test type: [tabletop / walkthrough / full simulation / technical recovery]. Findings: [what worked, what didn't, what changed as a result]. Next test due: [date].
[A backup job reporting "success" only tells you the copy was made, not that it can be restored — test an actual restore periodically, not just the alert.]
This plan is reviewed at least [annually], after any real disruption or test that surfaces a gap, and whenever the business changes significantly — a new critical system, a new key supplier, a change in headcount, or new premises.
The [Business Continuity Manager / named role] is responsible for coordinating reviews and keeping this plan current. Version: [x]. Last reviewed: [date]. Next review due: [date].
What's the difference between this and a disaster recovery plan?
A disaster recovery plan is specifically about restoring IT systems and data after an outage. A business continuity plan is broader — it covers the whole business: people, premises, suppliers, and processes, of which IT is only one part. Most small businesses need both, and many combine them into one document, which is fine as long as each critical function has real recovery objectives and arrangements written down.
Do we need a business continuity plan for Cyber Essentials Plus or ISO 27001?
CE+ doesn't mandate one for the base certification, but ISO 27001 (Annex A 5.29/5.30) expects documented business continuity arrangements, and cyber insurers and enterprise clients increasingly ask for evidence of one regardless of which certification you hold.
What are RTO, RPO, and MTPD?
Recovery Time Objective (RTO) is how long a function can be down before it becomes seriously damaging. Recovery Point Objective (RPO) is how much data or work you could afford to lose. Maximum Tolerable Period of Disruption (MTPD) is the absolute outer limit before the impact becomes unrecoverable for the business. Set all three per function — a single number for the whole business is rarely honest.
How many critical functions should a small business list?
Typically 4–8. Fewer than that usually means the exercise hasn't looked hard enough at genuine single points of failure; many more and the plan stops being usable in the first hour of a real disruption, when people need a short, clear list — not an exhaustive one.
Fortify's Continuity Builder drafts a tailored first plan from a plain-English description of your business, then the Business Impact Analysis, Recovery Objectives, Plans, and Testing areas let you go deeper than a static document ever could — each one feeding detail straight back into the plan itself.