Not just backups — the whole business. This guide covers how to run a real Business Impact Analysis, set recovery objectives that mean something, write continuity procedures people can actually follow, and test them before a real disruption does it for you.
Business continuity planning goes wrong when it starts with a generic checklist rather than your actual business. A Business Impact Analysis identifies the functions the business genuinely can't operate without, and assesses what happens if each one is unavailable for a day, then a week.
Don't start with "which servers do we have" — start with what the business does: taking orders, running payroll, delivering the service customers pay for. Systems support functions; they aren't the functions themselves.
For each function, write down what actually happens at 1 day and at 1 week — lost revenue, a missed contractual deadline, a safety issue, reputational damage. Vague answers like "it would be bad" don't give you anything to plan against.
For each function, what does it actually depend on — a specific system, a specific supplier, specific people, specific data? A single point of failure hiding in one of these is usually the real risk.
Worth knowing
Most small businesses over-invest in protecting the system that's easiest to back up and under-invest in the one that would actually put them out of business. A proper BIA, done honestly, is what fixes that.
Once you know the impact, set three numbers for each critical function: how long it can be down before the impact becomes serious (RTO), how much data or work you could afford to lose (RPO), and the absolute outer limit before it's unrecoverable for the business (MTPD).
A function that touches safety or payroll needs a far tighter objective than one that's merely inconvenient to lose. One number for the whole business is rarely honest.
Some sectors and client contracts specify their own recovery expectations. Most regulations (including DORA and NIS2) require you to define and justify your own objective rather than mandating a single universal number — but the justification itself is often what gets checked.
Worth knowing
RTO, RPO, and MTPD are what turn "we should be able to recover" into an actual, testable plan. Without them, continuity stays a vague intention rather than a number someone can be held to.
This is where most plans are weakest — a list of critical functions and targets, but no real detail on what happens next. For each function or disruption scenario, write down the immediate response, the alternative arrangements, and exactly how recovery happens.
"The IT team will handle it" isn't a procedure. Name who has the authority to declare a disruption, who executes the recovery, and who they report to — and make sure those people know they hold the role.
Remote working, a backup supplier, an alternative premises — whatever the fallback actually is, name it specifically rather than assuming it'll be figured out in the moment.
A continuity plan and an incident response playbook aren't the same thing, but a cyber incident that takes down a critical system sits at the intersection of both — cross-reference rather than duplicate.
An untested continuity plan is a hypothesis. Testing ranges from a low-cost tabletop discussion to a full simulation, and different functions warrant different levels of rigour.
Walk through the plan as a team without touching real systems: "the office is unavailable tomorrow morning — what do we actually do?" This surfaces gaps far more cheaply than a real disruption does.
For the handful of functions where the impact is most severe, an actual restore test or live simulation is worth the cost — a backup reporting "success" only tells you the copy was made, not that it can be restored.
What worked, what didn't, and what changed as a result — this record is exactly what an assessor asks for, not just a note that a test happened.
Worth knowing
ISO 22301, ISO 27001, and Cyber Essentials Plus all expect evidence that continuity arrangements are tested, not just documented — a dated record of your last test, and what you changed afterwards, is the evidence that satisfies that.
A plan written for one system and five staff isn't a plan for the business you are today. Treat it as a living document.
And whenever you adopt a new critical system, change a key supplier, move premises, or grow significantly.
A near miss — even a minor one — is the most valuable input you'll get. Feed what you learned straight back into the plan, not into a separate note that never makes it in.
What's the difference between a business continuity plan 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, processes), of which IT recovery is only one part. Most small businesses eventually need both, and many combine them into one document as long as each critical function still gets real recovery objectives and procedures.
What's a Business Impact Analysis, and do we really need one?
A Business Impact Analysis (BIA) is the exercise of identifying your genuinely critical functions and assessing what happens if each one is unavailable. It's the foundation everything else in a continuity plan builds on — recovery objectives and procedures set without one tend to be guesses rather than justified decisions, which is usually what an assessor or auditor notices first.
How is a Recovery Time Objective actually set?
Not from a template — from the impact assessment in your BIA. Ask what genuinely happens at 1 hour, 4 hours, 24 hours, and a week for that specific function, then set the RTO at the point the impact becomes seriously damaging. The honest answer is often more forgiving than people assume for most functions, and tighter than assumed for the one or two that actually matter most.
Do regulations mandate a specific RTO or RPO?
Usually not a single number. Most frameworks that touch continuity — including DORA and NIS2 — require the organisation to define and justify its own recovery objectives rather than mandating a universal figure. The justification itself, not a specific number, is typically what gets checked.
How often should we test a business continuity plan?
At minimum, annually, with more frequent testing for your highest-priority functions. A full tabletop exercise once a year, with an actual restore or recovery test for critical functions more often, catches most of what actually goes wrong before a real disruption does.
Fortify's free assessment scores your continuity readiness in about 10 minutes. In the portal, the Continuity Builder drafts a tailored first plan from a plain-English description, then Business Impact Analysis, Recovery Objectives, Plans, and Testing areas let you build out every step in this guide — with each one feeding detail straight back into the plan.