Many organisations commission a “business continuity plan refresh” and only realise too late that they have paid for an updated document, not improved readiness. A plan that is hard to use, out of date, or untested will be ignored when pressure hits, and teams will default to experience and improvisation instead.

The problem is rarely effort or intent. It is scope. If the refresh scope of work does not define what will change operationally (runbooks, roles, escalation, dependency‑driven recovery, and exercise evidence), the outcome is almost always box‑ticking.

This article sets out ten deliverables you can copy into a statement of work (SoW) to set clear, incident‑ready expectations and avoid “neat document, same risk” outcomes.

If you are planning the refresh end‑to‑end (not just writing the scope), read our practical walkthrough on how to refresh an existing business continuity plan in 2026.

Who this is for

This list is for continuity and risk leaders who already have a BCP, but need to refresh it because something has changed (business model, suppliers, IT/SaaS, audit pressure, or a real incident), and want proof the plan will work beyond compliance.

1) Practical scope definition tied to recovery reality (not org charts)

If the scope does not define what “acceptable recovery” means, everything downstream becomes subjective.

What you should ask for:

• A written scope that defines in‑scope services/value streams, locations, teams, and third parties that support recovery.
• Clear recovery expectations (the required pace of recovery and what must be prioritised).
• Explicit exclusions (“out of scope”) to prevent drift.

Buyer check:

• If the scope is basically “review and update the plan”, you are buying activity, not outcomes.

2) A BCP gap assessment focused on incident usability (not maturity theatre)

A good gap assessment tells you what will break on day one of disruption, not just how your programme scores.

What you should ask for:

• A structured review of the existing plan that tests usability under pressure (navigation, clarity, decision points, escalation paths).
• A prioritised gap list linked to operational consequences and specific fixes.

Buyer check:

• Ask for a one‑page “what fails first” summary. If you get a long narrative report with no priorities, expect slow progress.

3) Revalidated impact and recovery requirements (a proportionate BIA refresh)

Refreshing plans without revalidating recovery requirements is how outdated assumptions get reprinted.

What you should ask for:

• Revalidation of critical services/activities and recovery time expectations so the refresh reflects the business today.
• Confirmed recovery priorities and timeframes that drive response and IT recovery planning (where relevant).

Buyer check:

• If recovery deadlines are “assumed” or copied from an old BIA, you will struggle to justify strategy and spend when questioned.

4) Updated dependency mapping with practical implications

Dependency lists are not enough. You need to know which dependencies constrain recovery and in what order.

What you should ask for:

• Updated mapping across people, premises, IT/SaaS, data and suppliers for in‑scope services.
• Clear links between dependencies and recovery sequencing (what must be restored first, and why).

Buyer check:

• If dependencies are captured but not used to drive recovery order, they will not help you in an incident.

5) A defined scenario set and updated continuity risk view (aligned to what you will test)

If the refresh does not specify scenarios, you cannot specify runbooks, exercises, or evidence.

What you should ask for:

• A scenario set that reflects plausible disruption types and aligns to your operations and dependencies.
• Updated risk inputs that justify which scenarios get runbooks and what “good” looks like in response.

Buyer check:

• If your supplier cannot tell you what you will exercise and how success will be evidenced, expect box‑tick delivery.

6) Scenario runbooks (so the plan can be used quickly)

Monolithic plans are slow to navigate. Under pressure, they become a hindrance rather than a tool.

What you should ask for:

• A concise runbook per scenario (or per high‑value scenario group), written for incident use.
• Runbooks anchored to recovery deadlines and designed to be adaptable to sub‑worst case.

.Buyer check:

• Ask for sample outputs and expected runbook length/format. If it looks like a resized DR plan, you are not getting runbooks.

7) Role cards aligned to runbooks (who does what, now)

In a disruption, people need fast, role‑specific guidance that matches the scenario being faced.

What you should ask for:

• Role cards for key roles that sit alongside runbooks and task role assignees specifically for the scenario.
• Defined authority, deputies, escalation points and handoffs between incident, crisis and operational teams (where applicable).

Buyer check:

• If roles are only described inside the main plan, people will still be searching during the crisis.

8) Roles and contacts governance (not just a contact list)

Contact details decay quickly. A refresh that does not fix governance will decay again.

What you should ask for:

• A defined approach to maintaining roles and contacts (ownership, update cadence, access method during disruption).
• A practical way to keep the plan “always live” rather than a signed‑off archive document.

Buyer check:

• Ask: “Who owns updates after sign‑off, and how will changes be detected?” If nobody owns it, it will drift.

9) Tabletop exercise(s) that build capability (not presentation-style walkthroughs)

Exercising is where plans become trusted, and where hidden gaps show up.

What you should ask for:

• A tabletop exercise that steps through the planned response to the selected scenarios and tests decisions, information flow and timing.
• A design that keeps engagement and realism high (structured phases, injects, time pressure), especially for virtual sessions.

Buyer check:

• If the proposed exercise is “talk through the plan”, you will get attendance, not assurance.

10) Exercise evidence pack plus improvement backlog (proof beyond box-ticking)

Stakeholders do not trust “exercise completed”. They trust documented learning and improvement.

What you should ask for:

• An evidence pack showing what was tested, what happened, what broke, and what changed as a result.
• A prioritised improvement backlog with owners and due dates (and a method to track closure). 

Buyer check:

• If there is no mechanism for continual improvement, you are buying a moment in time, not readiness.

Copy/paste: BCP refresh scope-of-work deliverables (short form)

Use this wording directly in a brief or SoW.

1. Define refresh scope: in-scope services/value streams, locations, scenarios, dependencies, and explicit exclusions; aligned to required pace of recovery.

2. Conduct a BCP gap assessment focused on incident usability and readiness, with a prioritised remediation plan.

3. Revalidate impact and recovery requirements for in-scope services and confirm recovery sequencing and deadlines.

4. Update dependency mapping across people, premises, IT/SaaS, data and suppliers, showing practical recovery constraints.

5. Confirm scenario set and risk inputs used to design runbooks and exercises.

6. Produce scenario runbooks (concise, incident-use format) anchored to recovery deadlines and adaptable to sub-worst cases.

7. Produce role cards aligned to runbooks, including deputies, escalation and decision authority.

8. Define roles/contacts governance: ownership, update cadence, and access method during disruption.

9. Design and facilitate tabletop exercise(s) for selected scenarios.

10. Produce exercise evidence pack and improvement backlog: objectives, record of decisions/actions, lessons learned, owners and deadlines.

This structure aligns to a practical, scenario-led approach where response guidance is cut-to-the-chase and proven through exercising and continual improvement.

Consultant selection checklist (fast, buyer-ready)

If you are selecting a partner to support the refresh, these questions quickly separate “document update” providers from incident-ready delivery.

Ask:

1. Will you deliver scenario runbooks, or only update the main BCP document?
2. Do you provide role cards aligned to runbooks, or generic role descriptions?
3. How will you confirm the pace of recovery and validate recovery deadlines (rather than assume them)?
4. How will you map dependencies and translate them into recovery sequencing?
5. What does your tabletop exercise look like, and what evidence will it produce?
6. How will you stop the refreshed plan becoming obsolete after sign-off?

If answers are vague, you are likely heading towards a box-tick outcome.

A BCP refresh is worth doing when it improves response clarity, recovery realism, and stakeholder assurance. If you can’t point to runbooks, role clarity, and exercise evidence at the end of the work, you have not really refreshed readiness.

If you want an external view on whether your existing BCP would stand up in a real incident, start with a structured review focused on usability, scenario response and evidence (not just compliance).