Plenty of Birmingham businesses have a continuity plan drafted up, agreed at some point and rarely talked about since. The trouble is a plan only proves itself when something genuinely goes wrong, and by then it’s too late to discover it doesn’t hold up. This piece covers how business continuity plan testing works, the gaps it tends to expose, and what to check first if you’re not sure yours would survive contact with a real incident.
Why Business Continuity Plan Testing Matters More Than the Plan Itself
A written continuity plan is a reasonable start, but a document has never had to perform under pressure. Testing is what separates a real set of instructions from a well-intentioned list of assumptions. An earlier piece looked at why every Birmingham business needs a continuity plan in the first place. This one picks up where that leaves off, once the plan exists, and the harder question is whether it would work.
Government survey data puts the proportion of small businesses with a continuity plan that covers cyber security at 44%, down from 53% the year before. Having a plan is one thing. Knowing it works is another, and the two get treated as the same far more often than they should. A supplier changes, a key staff member moves on, or the software referenced in the plan gets replaced with something newer, and none of it shows up until the plan is needed for real.
The Business Continuity Checklist Gaps We See Most Often
When a continuity plan gets tested properly, the same handful of gaps tend to surface. A useful business continuity checklist should catch all of them before a real incident does.
- Outdated contact details: phone numbers change, people leave, and the emergency contact list rarely gets the same attention as the rest of the plan.
- Backups that have never been restored: NCSC guidance on ransomware recovery is explicit that businesses should regularly test that backups restore as expected, not simply assume they will.
- No clear recovery order: plans often list what needs restoring without saying what comes first, leaving the team to make that call live, under pressure, instead of in advance.
This gap is particularly common among businesses running on Microsoft 365. Microsoft’s own documentation on the shared responsibility model confirms that in a software-as-a-service setup, backing up and recovering data is the customer’s job, not the platform’s. A recycle bin isn’t the same as a tested, restorable Microsoft 365 backup. Backup testing is often the first thing SMEs let slip when nothing has gone wrong recently, which is exactly when it matters most.
Disaster Recovery Testing in Birmingham Without Disrupting the Business
Business continuity plan testing doesn’t have to mean shutting down the office for an afternoon. There are a few ways to check a plan, in order of how much disruption they cause.
The simplest option is a walkthrough. Gather the people named in the plan and talk through what each of them would do, step by step, if a specific system went down. This alone tends to surface the outdated contacts and unclear recovery order covered above, and it costs nothing but an hour of everyone’s time.
A tabletop exercise goes a step further. It works through a realistic scenario, a ransomware attack or a server failure, and tests whether the plan’s decisions hold up when nobody knows the answer in advance. The NCSC’s free Exercise in a Box tool is built specifically for this, and it works just as well for a five-person team as it does for a large enterprise.
The most thorough test is a full simulation. This means failing over to backup systems and confirming the business can operate from them. It’s the one most businesses skip, yet it’s the only test that proves the backup will hold up when it counts.
IT Recovery Time Objective and Recovery Point Objective, Explained Simply
Testing only tells you something useful if you know what you’re testing against, and that’s where recovery time objective and recovery point objective come in. Both sound technical, but they answer two ordinary questions.
Recovery time objective, or RTO, is how long the business can survive without a particular system before the disruption turns serious. The concept sits at the centre of the NCSC’s own Cyber Assessment Framework for critical national infrastructure and applies just as directly to smaller businesses. For some systems the RTO might stretch to a full working day. For others, it can be measured in minutes.
Recovery point objective, or RPO, asks a different question. It comes down to how much data the business can afford to lose between backups. If the last usable backup was taken overnight and a system fails mid-afternoon, the RPO determines whether that means losing a day’s work or almost nothing.
Setting both figures deliberately is what turns a generic plan into one built around how the business operates.
How MTS Technology Audits and Stress-Tests a Continuity Plan
MTS Technology has worked with Birmingham and the wider West Midlands for over 50 years, and reviewing an existing plan is one of the more common starting points, alongside building one from scratch. The audit starts with what’s already in place. That means checking contact details, confirming backup restores, and working through a realistic scenario to see where the plan holds up and where it doesn’t.
The business continuity and disaster recovery services MTS Technology provides are built with this kind of testing in mind. Backups that run as frequently as every five minutes, automated ransomware detection, and built-in screenshot verification of restore points mean a plan can be checked properly without waiting for a real emergency to find out whether it works.
A Plan Is Only as Good as Its Last Test
A continuity plan only proves its value once it’s been through proper business continuity plan testing, not by how thorough it looks sitting in a drawer.
Not sure if your continuity plan would work? Get in touch with our team today for a free continuity plan review.
FAQs
How often should a business test its continuity plan?
Once a year as a minimum, and again whenever something significant changes, such as new software, a change of premises, or key staff leaving.
What’s the least disruptive way to test a continuity plan?
A walkthrough, where the people named in the plan talk through what they would do step by step, costs almost nothing and still catches most of the common gaps.
What is the difference between RTO and RPO?
Recovery time objective is how long a system can be down before it becomes a serious problem. Recovery point objective is how much data the business can afford to lose. They answer different questions, and both matter.
Does Microsoft 365 already back up our data?
Not in the way most businesses assume. Microsoft’s shared responsibility model makes backup and recovery of data the customer’s responsibility in a software-as-a-service setup like Microsoft 365.
What happens if a continuity plan has never been tested?
It might still work, but nobody knows that until an actual incident forces the question, and by then there’s no time left to fix the gaps.
