Your backups probably exist. The uncomfortable question is whether they'd get the business working again by Monday morning.
That's where most small firms in Essex and London get caught out. They've got Microsoft 365, a NAS in the comms cupboard, maybe a cloud backup service, and a rough idea of who to call if the server dies. What they don't have is a proper IT DR plan that tells them what gets restored first, how long they can realistically operate without it, and what happens if the problem isn't just hardware but ransomware, a broadband outage, a failed switch, or a dead VoIP platform.
For a small business, disaster recovery doesn't need to look like an enterprise programme with binders, committees, and expensive standby infrastructure. It does need to be clear, tested, and matched to how the company operates. A ten-person office, a warehouse with scanners, and a professional services firm running entirely in the cloud all need different answers.
Table of Contents
- Laying the Foundation with a Business Impact Analysis
- Defining Your Recovery Goals RTO and RPO
- Choosing Your Recovery Strategies and Infrastructure
- Creating Actionable Runbooks and Communication Plans
- Testing and Maintaining Your IT DR Plan
- Making It Happen with Expert Support
Laying the Foundation with a Business Impact Analysis
A good IT DR plan starts with one discipline that sounds more corporate than it is. Business impact analysis, or BIA, means working out what the business must keep doing, what breaks when it can't, and what those activities depend on.
That matters because small businesses often protect technology in the wrong order. They'll spend time discussing a server warranty while ignoring the fact that most of the day-to-day operation now relies on Microsoft 365, broadband, Wi-Fi, shared files, cloud line-of-business apps, and the phone system.
The reason this deserves attention is straightforward. The UK Government's 2025 Cyber Security Breaches Survey summary cited here reported that 43% of UK businesses experienced a cyber breach or attack in the previous 12 months, rising to 67% for medium businesses. Resilience isn't theoretical when that many firms are dealing with real disruption.
Start with business functions, not devices
If you begin with a list of hardware, you'll miss the core priorities. Start with activities the business gets paid for.
A typical small company might list things like taking customer calls, sending quotes, processing orders, accessing job sheets, taking card payments, dispatching engineers, or raising invoices. Those are business functions. The systems behind them come second.
Practical rule: If the owner asks, “What stops us trading today?” the answers belong at the top of the BIA.
A short workshop is usually enough. Get the owner or operations lead, whoever looks after finance, and the person with day-to-day responsibility for IT. Then build a simple table.
| Business function | What happens if it stops | Main systems involved | Who owns it |
|---|---|---|---|
| Taking customer enquiries | Missed revenue and poor service | VoIP, mobiles, internet, CRM | Sales or office manager |
| Sending and receiving email | Delays, missed approvals, customer confusion | Microsoft 365, identity, internet | Admin or ops |
| Processing orders | Work backs up quickly | ERP or job system, file access, printers | Operations |
| Billing customers | Cash flow impact | Accounts package, file store, email | Finance |
Ask three plain-English questions
The BIA becomes manageable when you reduce it to three questions.
What's critical?
Not useful. Critical. If it's down, can staff still work, serve customers, or get paid?What's the impact if it fails?
Think in operational terms first. Phones unanswered. Jobs not scheduled. Staff idle. Customers chasing updates. Then add legal, contractual, or reputational impact where relevant.What does it depend on?
Many plans falter on this point. Email may depend on internet access, identity services, MFA, laptops, and mobile connectivity. Your VoIP platform may depend on broadband, power, switch ports, handsets, and the supplier's call routing.
A dependency list for a small firm often includes:
- Internet connectivity: Primary broadband, backup connectivity, Wi-Fi, firewall.
- Identity and access: Microsoft 365 sign-in, MFA methods, password manager access.
- Communications: VoIP platform, auto-attendant, call forwarding, mobiles.
- Core data: File shares, SharePoint, OneDrive, finance data, customer records.
- Site services: Power, comms cabinet, switch stack, printers for dispatch or warehouse labels.
A server can be healthy while the business is still effectively down because users can't authenticate, make calls, or reach cloud systems.
Done properly, the BIA stops you wasting money. You might discover the old on-prem file server is less important than broadband resilience and rapid access to Microsoft 365 accounts. Or that your biggest exposure isn't storage failure at all, but the fact nobody knows how to reroute inbound calls if the office loses connectivity.
Defining Your Recovery Goals RTO and RPO
Once the priorities are clear, the next job is setting recovery targets the business can understand and fund.
Two terms matter here. Recovery Time Objective (RTO) is how long you can tolerate a service being unavailable. Recovery Point Objective (RPO) is how much data loss you can tolerate. If you remember just one thing, think of RTO as a stopwatch and RPO as the amount of work you'd have to re-enter.
RTO and RPO without the jargon
RTO answers, “How long can we be down before it becomes unacceptable?”
RPO answers, “If we restore from backup or recover after corruption, how much recent work can we afford to lose?”
A practical example helps. If your accounts package has an RTO of a few hours, that means the business expects it back the same day. If its RPO is very tight, you'll need backup and replication arrangements that protect recent transactions. If your archived marketing files can wait until tomorrow, both targets can be looser and cheaper to deliver.
Specific planning is vital. Independent guidance summarised in this right-sized disaster recovery planning research notes that 17% of infrastructure failures and 13% of application failures took more than 24 hours to recover. If you haven't set realistic RTOs, you won't know whether your current setup is acceptable until you're already in trouble.
A brief explainer is useful if your team needs a visual reference.
Set tiers instead of one target for everything
Small businesses often make one of two mistakes. They either declare everything critical, which becomes unaffordable, or they avoid setting targets at all, which leaves IT guessing.
A tiered model works better.
| Tier | Typical systems | Recovery expectation |
|---|---|---|
| Tier 1 | Email, identity, internet access, core line-of-business system, telephony | Fastest recovery and closest monitoring |
| Tier 2 | Shared files, print services, internal collaboration tools | Important, but can follow after core trading systems |
| Tier 3 | Historical archives, old project folders, non-urgent internal apps | Restore later if needed |
That structure keeps budget aligned with risk. If the business says phones and customer email must return first, spend money there. Don't burn it on fast recovery for systems nobody needs in the first few hours.
Good RTO and RPO targets aren't aspirational. They're negotiated between business impact and budget.
For a right-sized IT DR plan, each tier should have an owner, a recovery method, and a fallback. If the main internet circuit fails, can phones divert to mobiles? If users can't reach the office, can they work securely from laptops over another connection? If a file share is encrypted, can the team continue from cloud copies while the main restore runs?
Choosing Your Recovery Strategies and Infrastructure
The planning phase becomes one of decisions. The question isn't “What's the best disaster recovery technology?” The question is, “What setup gets this business back inside the agreed targets without creating a support nightmare?”
The trade-off triangle
For most SMBs, recovery choices sit inside a triangle of cost, speed, and complexity. You can improve one easily. Improving all three at once is harder.
A local NAS backup is usually straightforward and gives quick restores for deleted files or a failed PC. It doesn't help much if the site is inaccessible, the NAS is compromised, or ransomware reaches the backup platform.
Cloud backup improves off-site resilience and often simplifies retention. Restores can be slower, and you're dependent on internet access and supplier recovery workflows.
A hybrid design usually lands in the sweet spot for a small business. Keep a fast local recovery option for common issues. Add protected off-site copies for major incidents. That covers accidental deletion, hardware loss, and a bad day at the office.
What usually works for a UK SMB
There isn't one template, but these patterns tend to hold up well:
- Microsoft 365-heavy offices: Protect Exchange Online, OneDrive, SharePoint, and identity access. Make sure staff can sign in from alternative devices and locations.
- Server-based businesses: Use image-based backup or equivalent recovery tooling for the key host or VM workloads, with off-site copies isolated from the main production environment.
- Phone-dependent firms: Build a clear failover route for inbound calls. If the hosted VoIP service or office connectivity fails, calls should divert to mobiles or another answer point.
- Operational sites: If printing labels, job sheets, or delivery paperwork is essential, include printers and print paths in the plan. They're often ignored until dispatch stops.
A lot of firms also need to think about physical dependencies, not just data. If the firewall dies, your cloud apps may as well be down. If the PoE switch fails, the handsets and wireless access points may disappear with it. If the comms cabinet loses power, your internet backup may not stay up either.
Common gaps that break recovery
In practice, these are the weak spots that cause trouble:
- Single inventory missing or outdated: If nobody has one current list of servers, switches, firewalls, subscriptions, key apps, admin accounts, and support contacts, recovery slows immediately.
- Cloud assumptions: Businesses assume Microsoft 365 means “covered”. It doesn't replace the need for a recovery plan around access, deleted data, misconfiguration, account lockout, or supplier-side outage handling.
- VoIP blind spot: The phone system is treated as a utility until there's an incident. Then nobody knows who can redirect numbers, change call flows, or publish a temporary message.
- No clean admin route: If MFA methods depend on the same devices or phones that are unavailable, recovery can stall before it starts.
- Broadband dependency hidden in plain sight: A cloud-first business with one internet circuit has still got a single point of failure.
A sensible strategy document for an IT DR plan should cover each core service, the recovery method, the fallback option, and any supplier dependency. If your broadband, hosted telephony, DNS, backup portal, and line-of-business application all sit with different providers, write down who they are and what they're responsible for. During an outage, nobody wants to discover the critical logins are in an inbox they can't access.
Creating Actionable Runbooks and Communication Plans
A recovery plan becomes useful when it turns into runbooks. That means step-by-step instructions that someone can follow under pressure, not broad statements like “restore the server” or “contact the provider”.
What a useful runbook actually contains
The best runbooks are short, specific, and scenario-based. One for server failure. One for ransomware suspicion. One for broadband outage. One for office access loss. One for VoIP failure.
Each runbook should answer five things:
- Trigger point: What tells the team this runbook applies?
- Immediate actions: What must happen in the first few minutes to contain impact?
- Ownership: Who leads, who approves, who contacts suppliers?
- Technical sequence: In what order do systems and dependencies come back?
- Validation: How do you confirm the service is properly working, not just “powered on”?
If a runbook needs a long explanation before anyone can use it, it's too vague.
Store runbooks somewhere staff can reach during an incident. That usually means not only on the office file server. A secure cloud document repository, protected password manager, and printed emergency contact sheet can all have a place here.
A simple scenario with phones down
Take a common example. The office internet circuit is down and the hosted handsets can't register.
A poor runbook says: “Call the telecoms provider and wait for updates.”
A useful runbook says something closer to this:
- Office manager confirms calls are failing on two handsets and one softphone.
- Engineer checks whether the fault is internet-wide or voice-specific.
- If broadband is down, authorised person logs the ISP fault.
- Telecoms contact reroutes the main number group to nominated mobiles.
- Reception message is updated with temporary wording.
- Staff switch outbound urgent calls to mobiles or softphones over alternate connectivity.
- Team validates inbound calls from external numbers and confirms hunt group behaviour.
- Customer-facing staff send a short service notice if response times are affected.
That's a real working document. It has owners, order, and an outcome.
Communication needs its own plan
Technical recovery is only half the job. People need updates they can act on.
For internal updates, decide who messages staff, where they'll receive updates if email is affected, and how often they'll be updated. For customer communication, agree who approves wording and when you'll tell clients there's a problem.
A dedicated Critical alerts platform can be useful if you need a fast way to push urgent notifications by text or voice when normal channels are patchy. That's especially relevant if your primary email or phone platform is part of the incident.
Keep a few templates ready in advance:
- Staff advisory: Short message with status, expected next update, and what staff should do now.
- Customer service notice: Acknowledge disruption, explain the current workaround, avoid technical detail.
- Supplier escalation note: Include account name, affected services, business impact, and callback details.
The tone matters. Calm, factual, and brief nearly always works better than overexplaining. Customers don't need your firewall model and call queue architecture. They need to know whether they can still reach you and what happens next.
Testing and Maintaining Your IT DR Plan
Most disaster recovery documents fail for one simple reason. They were written once, approved once, and never exercised in a way that exposed the gaps.
That's why testing is the part that separates a decent-looking plan from a usable one. In a small business, this doesn't have to mean a full weekend simulation every month. It does mean regular, deliberate checks that prove the plan still matches the environment.
Why written plans fail
Written plans go stale quickly. Staff change. Suppliers change. Microsoft 365 tenant settings change. The backup product gets replaced. The office moves. The broadband line is renewed with a different carrier. None of that automatically updates the DR documentation.
Institutional guidance summarised in this disaster recovery methodology and maintenance guidance gives a sensible cadence for staying current: annual plan maintenance, semi-annual testing for backup media supporting critical processes, and plan revisions within 60 days after a DR test. That's practical because it forces a review cycle and closes the loop after problems are found.
A proper test also checks dependencies outside your own kit. If your plan depends on an ISP, hosted VoIP supplier, cloud backup provider, DNS host, or remote access service, those assumptions need to be exercised too.
An untested IT DR plan is just documentation. Testing is the point where theory meets your actual suppliers, passwords, permissions, hardware, and staff availability.
A practical test schedule
For a typical UK SMB, a balanced schedule looks like this:
- Quarterly tabletop exercise: Talk through one scenario in a meeting. Keep it realistic. “Ransomware on a finance laptop.” “Broadband outage on payroll day.” “Office inaccessible after an electrical issue.”
- Twice-yearly backup recovery checks for critical data: Restore selected items and prove they're usable. Don't stop at “the job completed successfully”.
- Annual full plan review: Recheck systems, owners, contact details, and recovery order.
- Post-change review: If you change your VoIP platform, firewall, server host, Microsoft 365 setup, or office connectivity, update the plan straight away rather than waiting for the annual cycle.
You also need to test both technical recovery and operational workarounds.
| Test type | What it proves | Good SMB example |
|---|---|---|
| Tabletop | People know decisions and sequence | Walk through ransomware response and comms |
| Restore test | Backups actually recover usable data | Recover a finance folder or mailbox item |
| Service failover check | Supplier and routing assumptions work | Divert inbound numbers to mobiles |
| Access test | Staff can work another way | Sign in securely from spare laptop or alternate location |
What to record after every exercise
A one-line note saying “test passed” is nearly useless. Record what scenario was tested, who took part, what worked, what failed, and what changed.
Include practical findings such as:
- Missing credentials: Admin access stored in the wrong place.
- Supplier delay: Wrong support number or unclear escalation path.
- Dependency surprise: A cloud app relied on office internet for SSO routing or device trust.
- Comms issue: Staff didn't know where to look for updates.
- Recovery order mistake: A service was restored before the identity or network component it needed.
Then assign actions with owners and deadlines. If a test exposes that call forwarding can't be changed without a code held by one person on annual leave, that isn't a note for later. It's a fix.
Recovery planning also benefits from a single current inventory of infrastructure, applications, and configurations. Without that, test results don't feed back into anything durable. You end up proving one narrow scenario while the underlying documentation remains unreliable.
Making It Happen with Expert Support
A right-sized IT DR plan isn't about buying every resilience product on the market. It's about joining the pieces properly. Business impact analysis, sensible RTO and RPO targets, a recovery method that fits your budget, clear runbooks, and scheduled testing all need to work together.
For many small businesses, the hard part isn't understanding the idea. It's maintaining the discipline. Someone has to keep the inventory current, check backup outcomes, retest call routing, review Microsoft 365 access paths, and update the plan after infrastructure changes. That work usually gets squeezed out by day-to-day support demands.
That's where expert help earns its keep. An experienced support team can bring structure to the process, challenge unrealistic assumptions, and run the tests most businesses never get round to doing. They can also spot the local, practical risks that generic guides skip, such as single broadband dependency, undocumented VoIP routing, stale supplier contacts, or backup systems that have never been restored under pressure.
If your business would struggle to answer “What fails first, what comes back first, and who does what?”, the plan needs tightening.
If you want help building a practical, tested recovery plan for your business, speak to Networking2000. They support organisations across London and Essex with IT, connectivity, telephony, and security, and can help turn a rough backup setup into an IT DR plan that's realistic, current, and usable when things go wrong.
