Most organisations we speak to already have a business continuity plan.
The hesitation usually comes later. People aren’t convinced their plans are particularly strong, but starting again feels like too much. A full review sounds time-consuming, expensive, and likely to create more work than they can absorb, so the plan just stays as it is.
That’s where the risk tends to sit.
If you’re starting from scratch, a structured checklist helps you cover the basics properly (you can find one here:
https://www.inoni.co.uk/blog/business-continuity-planning-checklist-bcp-set).
But most organisations aren’t at that stage. They already have something — the challenge is knowing whether it holds up in practice.
What’s needed at that point isn’t a full rebuild. It’s a practical way to review what you already have and understand whether it would actually work.
In most cases, the barrier isn’t awareness — it’s scale.
A full BCP refresh involves revisiting impact analysis, engaging multiple teams, rewriting plans, and coordinating input across the business. That quickly turns into a programme rather than a manageable piece of work.
If you’re not set up for that, it’s easy to delay. Plans get left as they are, with the assumption that they’re “probably fine”, even when there’s some doubt.
A lighter, more focused review is often a more realistic starting point.
At this stage, the question is straightforward:
If something went wrong tomorrow, would this plan actually help us respond and recover?
You don’t need a formal audit to answer that. What you need is enough clarity on how the business operates, what it depends on, and how people would respond under pressure.
This doesn’t need to be overly formal, and it doesn’t need to cover everything.
In most cases, you can get a clear view by working through three areas.
Start with a small group of senior stakeholders and sense-check the basics. Which services or products genuinely matter to the organisation, and how long could they be disrupted before it becomes a serious issue?
If the answers vary significantly, that’s already a sign of risk. Most plans refer to “critical activities”, but the assumptions behind those decisions are not always shared or clearly defined. That tends to show up when decisions have to be made quickly.
From there, take a small number of key services and look at them in practical terms. What do they actually rely on to operate — people, systems, sites, suppliers?
You don’t need a detailed model, just enough to see whether anything important is missing or assumed. In most cases, dependencies are only partially understood, or they sit across different teams without a clear overall view.
This is where a lot of the real gaps sit.
This is where plans either hold up or start to fall down.
Take a realistic scenario and talk it through. How would the issue be identified? Who would take control? What would actually happen in the first few hours?
If the answers are clear and consistent, the plan is probably in reasonable shape. If they’re vague, or vary depending on who you ask, that’s usually where attention is needed.
If you want to make this more structured, it can easily be turned into a short gap assessment without becoming a full programme.
In practice, that usually means focusing on a small number of critical services, running one or two short workshops with senior staff and subject matter experts, and reviewing the existing plans, runbooks and role structures alongside those discussions.
The output doesn’t need to be complicated. You’re aiming for:
From there, the focus should be on assigning actions to owners, setting short timeframes (typically weeks rather than months), and improving what already exists rather than rewriting everything.
You rarely end up with a long list of issues.
More often, a few consistent themes come out of the review. Impact is described but not clearly defined, different parts of the business are working to different assumptions, dependencies are only partially understood, and response actions are too high level to follow in a real situation.
None of that means the plan is fundamentally wrong. It usually just hasn’t been worked through in enough detail to be reliable under pressure.
This is where reviews either add value or get ignored.
You don’t need a long report. What you need is a small number of clear actions that can actually be taken forward.
That might include agreeing what “significant impact” means in practice, clarifying ownership and escalation, improving the level of detail for a handful of key services, aligning cyber response with the wider BCP, and testing the plan through a short exercise.
Each action should be owned, time-bound, and linked to a clear outcome. That’s what turns a review into something useful.
At some point, the only reliable way to confirm whether a plan works is to test it.
A short, scenario-based exercise will usually expose more than any document review. It shows whether roles are clear, whether decisions can actually be made, and whether recovery actions are usable in practice.
For most organisations, this is the step that turns a plan from something theoretical into something they can rely on.
This kind of review tends to work well when plans already exist but haven’t been revisited for a while, when confidence in them is unclear, or when a full refresh feels too large to start.
It provides a way to make progress without committing to a major programme straight away, while still improving the areas that matter most.
Most organisations have a plan. But they have something that was written at a point in time and hasn’t been properly tested since.
The risk isn’t always what’s missing. It’s what hasn’t been properly checked.
A short, focused gap assessment is usually enough to see that clearly — and to decide what’s worth doing next.