Skip to main content

Backup & Disaster Recovery

Business continuity planning

Business continuity planning: RTO and RPO in plain English, a critical systems inventory, scenarios for ransomware, office loss and outages, and testing.

In short

Business continuity planning answers two questions for every system you rely on: how long could you cope without it (recovery time objective, RTO) and how much data could you afford to lose (recovery point objective, RPO). Dig IT Solutions works through your critical systems, the realistic scenarios, and the technical and people arrangements needed, then tests the plan on a schedule.

When you need this

Signs this is the right conversation

  • If the office burned down tomorrow, I genuinely don't know what we'd do.
  • We have backups but no idea how long a full restore would take.
  • One person knows all our passwords and systems.
  • Our internet goes down and the whole company stops.
  • Our clients and insurer are asking for a continuity plan and we don't have one.

Scope

What we deliver

  • 01

    Critical systems inventory

    Every system, application, data set, connection and supplier listed with its owner, its dependencies and how long the business can run without it.

  • 02

    RTO and RPO agreed per system

    Recovery targets set with management in plain terms, so backup frequency and recovery methods match what the business actually needs.

  • 03

    Scenario planning

    Written responses for ransomware, loss of the office, extended ISP outage, key-person unavailability, cloud service outage and hardware failure.

  • 04

    Technical alignment

    Backups, cloud services, failover connectivity, VoIP call routing and remote working set up so the plan is achievable, not aspirational.

  • 05

    Communications and roles

    Who declares an incident, who calls whom, how staff and customers are informed, and where the plan lives when systems are down.

  • 06

    Testing schedule

    Restore tests, a tabletop walk-through and, where appropriate, a full failover exercise, with results and improvements recorded.

Outcomes

What you get out of it

  • A written plan that people know how to find and use.
  • Recovery times based on tests rather than hope.
  • Insurer, client and audit questions answered with a document.
  • Fewer single points of failure, technical and human.

FAQ

Questions we are asked

Straight answers. If yours is not here, call 020 8482 4020 or 01992 939 365 and ask an engineer.
What is RTO and RPO in plain English?
RTO, recovery time objective, is how quickly you need a system back after it fails: an hour, a day, a week. RPO, recovery point objective, is how much recent data you could afford to lose: if your last backup was last night, your RPO is a day. Together they tell you how often to back up and what kind of recovery arrangements to pay for. Different systems justify different answers.
What should a business continuity plan include?
An inventory of critical systems and suppliers with recovery priorities, agreed RTO and RPO per system, defined roles and contact details, step-by-step responses for the most likely scenarios, where backups and passwords are held and who can access them, how staff and customers will be communicated with, and a testing schedule. It should be short enough to use under pressure and stored somewhere reachable when your systems are down.
How is business continuity different from backup and disaster recovery?
Backup is a copy of your data. Disaster recovery is the technical process of restoring systems from those copies. Business continuity is the wider plan for keeping the business operating: where people work, how customers are contacted, how phones are answered, which supplier to call, and in what order systems come back. DR is one chapter of the continuity plan, not the whole book.
How does VoIP help with business continuity?
A cloud phone system such as 8x8 doesn't depend on your office being available. If the building or the line is out, calls can ring on mobiles, at another site or on laptops at home within minutes, and auto-attendant messages can be changed remotely. That removes one of the most visible failures during an incident: customers ringing an office that doesn't answer. See voip business phone systems service.
How often should we test the plan?
Test a restore of something meaningful at least quarterly, walk through the plan as a tabletop exercise annually, and re-test after any major change such as a migration, a new site or a change of provider. Update contact details every time someone joins or leaves. A plan that hasn't been tested is a set of assumptions, and the first real incident is a bad time to discover which ones were wrong.

Next step

Talk to an engineer, not a sales script

Tell us what is not working, or what you are planning, and we will give you a straight view on what it would take to fix.

WhatsApp us