Most Statements of Work for business continuity exercises look fine on paper, but they don’t really tell you what’s going to happen or what you’ll get at the end.
You’ll see phrases like “scenario-based tabletop exercise” or “facilitated workshop”, but very little about how the exercise actually works, what is being tested, or how it leads to anything changing afterwards.
That’s usually why exercises feel useful on the day, but don’t move the organisation on.
If you want a business continuity plan scope of work that actually does its job, you need to approach it differently from the start.
Start by being clear on the type of exercise you’re buying
One of the biggest problems with continuity exercising SOWs is that they assume all exercises are trying to achieve the same thing.
They’re not.
In practice, the objective varies quite a lot depending on where the organisation is and what it actually needs.
-
Sometimes the focus is building confidence with a senior team who haven’t been through a crisis before.
-
Sometimes it’s validating whether the BCP actually works in practice.
-
Sometimes it’s about testing how departments recover when systems aren’t available.
-
Sometimes it’s about decision-making, escalation, or coordination under pressure.
Those are completely different exercises, even if they all get labelled as “tabletop”.
And that’s where a lot of SOWs go wrong. They describe the format, but not the intent. So you end up with something generic that doesn’t quite hit the mark.
A better way to write it is to force a simple question upfront:
What are we actually trying to learn from this?
Because once that’s clear, everything else follows. The scope, the structure, the level of pressure, even the reporting all change depending on the answer.
Define scope properly and don’t let it drift
Once the objective is clear, you need to draw clean boundaries around the exercise.
Without that, things tend to drift. You start off testing one thing and end up with a bit of everything.
A good SOW should be explicit about:
-
Who is involved, and at what level
-
What layer you are focusing on (incident, crisis, continuity)
-
What is deliberately out of scope
That last point matters more than people think. If you don’t say what you’re not testing, expectations creep in and the exercise loses focus.
A crisis leadership exercise, for example, is very different from a departmental recovery walkthrough. Mixing the two usually means you don’t do either properly.
Focus on outcomes, not activity
There’s a tendency to fill SOWs with lists of meetings, workshops and sessions, but that’s not what people are buying. What matters is what they get out of it.
So instead of describing activity, build the SOW around outcomes.
-
Before the exercise, that means clear objectives, a realistic scenario, and people understanding their role.
-
During the exercise, it means structured decision-making under pressure, not just open discussion.
-
Afterwards, it should result in something usable. A short report, a clear set of priorities, and updates to the parts of the plan that didn’t hold up.
The underlying point is simple. You’re not testing whether a plan exists. You’re testing whether people can actually use it.
Describe how the exercise actually runs
“Scenario-based exercise” is one of those phrases that sounds right but doesn’t really mean anything.
If you want the SOW to be useful, you need to describe what will actually happen when people sit down (or log on).
That might include how information is introduced gradually, how decisions are expected to be made, and how escalation is handled. It should also be clear that participants are working with incomplete information, because that’s what real incidents look like.
It also helps to reflect the way incidents actually unfold. They don’t happen in a single, neat conversation. They develop over time, often in stages, with new information changing the direction.
If the SOW reflects that, the exercise will feel far more realistic and will test the right things. This is where the difference usually shows between a generic workshop and a properly designed simulation.
Use scenario walkthroughs to force the issue
One of the simplest ways to improve an exercise is to move beyond general discussion and build in proper walkthroughs.
When people have to use the plan in real time, things become much clearer.
If you want a more structured way of doing this, a proper scenario walkthrough is often the quickest way to see whether a plan actually works in practice, rather than just sounding right on paper.
They either find what they need and follow it, or they don’t. Ownership becomes obvious, gaps show up quickly, and assumptions get challenged properly.
Without that, it’s very easy to have a conversation that sounds sensible but doesn’t really test anything.
This is where most organisations realise that what looks complete on paper isn’t always usable in practice.
Build in pressure and imperfection
If an exercise runs too smoothly, it’s usually not testing the right things.
Real incidents aren’t tidy. Information is incomplete, decisions clash, and time is always shorter than you expect.
You see the same behaviours in completely different settings. Give a group of people a time-limited, high-pressure problem and they will jump in quickly, sometimes miss key information, duplicate effort and focus on the wrong things.
That’s exactly what happens in a crisis. There’s a good way to visualise this using an escape-room type scenario, where the same behaviours show up very quickly once time pressure is introduced.
A good SOW doesn’t try to eliminate that. It allows for it, so those behaviours can be seen and improved.
Treat virtual exercises as their own thing
A lot of exercising now happens over Teams, and it behaves differently from being in a room together.
It’s harder to manage energy and engagement, easier for people to step back from the discussion, and more difficult to read what’s going on across the group.
If the SOW treats it as just a remote version of the same thing, it won’t land properly.
Instead, it needs to account for it. Breaking the exercise into phases, giving people specific roles and tasks, and introducing time pressure all help keep things moving and focused.
Virtual exercises can work well, but they need to be designed that way. If you’re running exercises remotely, there are a few practical things that make a big difference to engagement and realism, particularly around structure, pacing and use of Teams.
Keep reporting grounded in what actually happened
The real value of an exercise comes afterwards, and this is another area where SOWs tend to be vague.
Reporting shouldn’t just describe the session. It should capture how people behaved.
That includes how decisions were made, whether escalation happened at the right time, how the plan was used, and where people hesitated or improvised.
From that, you should get a short list of practical improvements. Not everything that could be better, just the things that actually matter.
If the output isn’t something that can be picked up and acted on quickly, it won’t get used.
Be clear about what happens next
A surprising number of SOWs stop at “we’ll provide recommendations”.
That’s rarely enough.
If you want the exercise to lead to improvement, you need to define what happens afterwards. That might include updating plans, clarifying roles, running follow-on sessions or building a wider exercise programme.
Resilience comes from repeating the cycle, not from a single event.
A quick sense check
Before you finalise a statement of work for business continuity planning, take a step back and sanity check it.
-
Does it explain what’s actually being tested?
-
Can you picture how the exercise will run?
-
Is it clear what you’ll get at the end?
-
Does it feel like it will put people under pressure, or just start a conversation?
If any of those aren’t clear, it probably needs tightening.
Final thought
A good SOW shouldn’t feel like a brochure. It should feel like a plan for something real.
Because when an incident happens, there isn’t time to interpret documents or work out what was meant. People fall back on behaviour, instinct and whatever feels most obvious in the moment.
The whole point of exercising is to shape that behaviour in advance.
If your SOW reflects that, the exercise usually delivers what it’s supposed to.
If you’re looking at running an exercise and want something that actually tests how your team responds, not just ticks a box, it’s worth thinking about how the simulation is designed as much as what scenario you choose. You can see how we approach that here.