Ask most business owners “Do you have a Business Continuity Plan?” and the answer is usually yes. Ask when it was last tested, and the room goes quiet.

That gap, between having a plan and knowing it works, is where most businesses actually get caught out. Not because they didn’t plan for a cyber attack, a fire, a flood, or a major outage, but because the plan was written once, filed away, and never put under any real pressure.

Two Different Questions

It’s worth separating these, because they get treated as one and they’re not:

• Business Continuity Planning (BCP) — how does the business keep operating during and after a disruption? Where do people work if the office is unusable? How do you communicate with staff, customers, and suppliers? Who’s authorised to make decisions if key people are unreachable?
• Disaster Recovery Planning (DRP) — how do your systems and data come back online? Which servers, applications, and data need to be restored first, in what order, and how long will that actually take?

A fire that closes your building is a BCP problem as much as a DR one. A ransomware attack is a DR problem that quickly becomes a BCP one, once staff can’t invoice, take orders, or answer the phone. Good incident response readiness treats both together.

The Question That Actually Matters: When Was It Last Tested?

A plan that exists only on paper is a hypothesis, not a capability. The only way to know whether you’ll actually recover in the timeframe you’re expecting is to test it, AND to test it regularly, not once at the start of a contract and never again.

This is also where most gaps get found: a backup that’s been running “successfully” for months but has never been restored, a contact list with three people who’ve left the company, a recovery step that assumes access to a system that itself went down in the incident.

How Blueloop Helps

We work with clients on both sides of this:

Planning and gap identification. We review what’s already in place, or help build it from scratch … AND pressure-test it against realistic scenarios (cyber attack, fire, extended outage, loss of key premises). The goal is to surface the gaps before an actual incident does: missing dependencies, unrealistic assumptions, single points of failure, and recovery steps that look fine on paper but don’t hold up in practice.

Disaster recovery testing. We carry out backup recovery testing with clients once or twice a year (this can sometimes be specified by your insurance company), actually restoring data and systems rather than just confirming a backup job completed. That distinction matters — a backup that “ran successfully” tells you very little about whether it can be restored quickly, completely, and in the right order when it counts.

RTO and RPO that are actually achievable. Recovery Time Objective (how quickly you need to be back up) and Recovery Point Objective (how much data loss is tolerable) are targets the customer sets — you know your business and what “acceptable downtime” looks like better than anyone. Our role is to work through those targets with you and agree, honestly, whether the infrastructure and processes in place can actually hit them. A plan built around an RTO nobody can deliver isn’t a safety net. It is a false sense of security.

When It’s Real: Blackmore’s Fire

Blackmore Limited is one of the UK’s leading green printers, based in Shaftesbury, serving everything from large corporates and charities to small local businesses. Founded in 1900, the company is heavily reliant on IT for design, production, and day-to-day operations — and has been a Blueloop client since 2017.

In April 2021, 37 firefighters tackled one of the largest local fires of that year at Blackmore’s print works, with flames coming through the roof and vents. The fire itself was extinguished quickly, but not before it caused extensive smoke damage near the affected printing press and to Blackmore’s IT equipment. The systems the business depends on for design, production, and day-to-day operations.

This is exactly the scenario incident response readiness exists for: no warning, no convenient timing, and a business that still needs to operate.

Blueloop had already put off-site backups in place, replicating Blackmore’s email, files, and data from the print works to our data centre, with the recovery process documented, validated, and regularly tested. Because that groundwork existed before the fire, we were able to restore full access to Blackmore’s business systems within 24 hours — and Blackmore were back in production, printing 40,000 copies of the Blackmore Vale, the same week. Blueloop also hosted Blackmore’s systems and data while the fire investigation ran and the insurance provision for replacement equipment was agreed.

None of that was possible because of luck. It was possible because the DR plan had been tested and trusted before it was ever needed for real.

You can read the full story here: Blackmore Disaster Recovery Case Study.

Where to Start

If you are not sure how your organisation would answer the questions at the top of this article, whether you have a current BCP/DRP, when it was last reviewed, and when it was last genuinely tested — that uncertainty is itself the answer. It means IT IS time for a review.

Get in touch with Blueloop to talk through your current incident response readiness.