Skip to content
Review your business continuity and disaster recovery plans
Data Management Business Practices

Business Continuity & IT Disaster Recovery for Australian SMEs

Dale Jenkins
Dale Jenkins

Let’s be honest: “we’ll deal with it when it happens” is not a plan.


If the last few years have taught us anything, it’s that outages rarely happen at a convenient time. Floods, bushfires, fibre cuts, ransomware, and plain old human error have all taken businesses offline at one point or another, with some being down for days.

And when systems go down, the consequences show up quickly. Revenue stops. Clients get frustrated. Compliance risks creep in. In sectors like healthcare, aged care and professional services , it can go well beyond inconvenience.

Despite that, many businesses still treat disaster recovery as something too hard or too expensive to do properly. They picture duplicate data centres, complex infrastructure, and six-figure projects.

While that used to be the case, it's not anymore. In reality, cloud platforms, modern networks and managed services now make resilient designs achievable for most Australian SMEs, provided you approach them deliberately.

Business Continuity and IT Disaster Recovery - Two Sides of the Same Problem

A practical starting point is to reframe “disaster recovery” as “how we keep operating when something important breaks”. That includes both IT-specific incidents (such as ransomware or server failure) and broader disruptions like storms, building damage or a prolonged NBN outage.

A lot of confusion comes from treating these as separate ideas when they're tightly connected.

  • Business Continuity (BC): How your business keeps operating. It focuses on processes and people.
  • Disaster Recovery (DR): How your systems and data are restored.

A simpler way to think about it is this: what happens when something important breaks, and how do we keep going?

That “something” might be a server failure, a cyber incident, or even a prolonged NBN outage. If you only plan for the technical recovery and ignore how the business operates in the meantime, you’re leaving a big gap.

 


Start with Impact - Not Technology

Before jumping into tools or platforms, the most useful thing you can do is get clear on what actually matters (either to you, or more importantly, to your key stakeholders).

Ask yourself:

  • If email, key line-of-business apps or core file storage were unavailable for a day, what would that mean for clients, residents or patients?
  • How long could we operate on manual workarounds?
  • Which sites are mission-critical, and which could slow down without serious harm?

These questions may feel uncomfortable, but they force you to prioritise and that's where good planning starts.

It's also where concepts like RTO and RPO become practical.

  • RTO (Recovery Time Objective): How long you can tolerate being down for.
  • RPO (Recovery Point Objective): How much data you can afford to lose.

An example of this: a clinical or client-facing system would generally need to be back within an hour or two with minimal data loss - while an internal reporting tool might comfortably sit offline until the next day.

Not every system needs the same level of protection, and trying to treat them all as equally critical is a recipe for over-spend and under-delivery.

Once you have clarity on impact and priorities, you can begin to map existing controls such as backups, cloud hosting, redundant internet links, and managed support, against what you actually need. The gaps that remain become the backbone of your business continuity and IT disaster recovery roadmap.


Design for Recovery, Not Just Uptime

Once priorities are clear, the focus shifts to designing an IT estate that can actually recover in practice and under pressure at any time including 2am on a Sunday. This is where many environments look fine on paper but fall apart under pressure.

Start with a simple question: if this system failed right now, how would we bring it back?

For most SMEs, the answer involves a mix of cloud, backups, and network design working together. Cloud platforms like Azure and AWS have made resilient infrastructure far more accessible than it was a decade ago. Instead of relying on a single on-premise server, critical workloads can run on highly available platforms with built-in redundancy and replication.

Don't get me wrong, backups are still essential, but they need to be done properly. A single backup sitting on a device in the server room won’t help much in a real incident.

  1. Start with a clear picture of your critical workloads.

  2. List the applications and services your staff absolutely need to keep operating: practice management or clinical systems, file shares or document management, email and collaboration (usually Microsoft 365), core line-of-business databases, and key network services like DNS.

  3. For each, capture where it runs today (on-prem server, Azure, AWS, SaaS), who supports it, and how staff access it from head office, branches and home. Then, define sensible RTOs and RPOs.

A solid baseline is the 3-2-1 approach. This means you should have:

  • 3 copies of your data, on
  • 2 different media types, with
  • 1 stored offsite and 1 as an isolated copy

The isolation piece is crucial! Without it, ransomware can take out both your production systems and your backups in one hit. For Microsoft 365, that means adding dedicated backup for Exchange, SharePoint, OneDrive and Teams. For on-site workloads, it often means a mix of local backup for fast restores and cloud replicas for true disaster scenarios.

Networks and connectivity round out the picture. Design your WAN and internet access so staff can reach critical cloud services even if a single office goes offline. That might involve SD-WAN with automatic failover between NBN and 4G, or pre-planned procedures to shift key staff to remote work during a site outage. Microsolve’s secure connectivity and multi-site network designs are built with this in mind: predictable, monitored paths to cloud and data centres so failover isn’t a scramble.

Finally, don’t forget the human side of recovery. Document who is responsible for invoking failover, who talks to staff and customers, and how you’ll manage priorities when every department wants to be restored first. Clear ownership and communication plans are as important as replication and backups when the pressure is on.

 


Connectivity Matters More than Most People Think

Even with well-designed systems and backups, your ability to operate still depends on how people connect to them.

If a single internet link or office outage can stop the entire business, that’s not bad luck. It’s a design limitation. At a minimum, most SMEs should be thinking about:

  • Redundant internet (e.g. NBN with 4G/5G failover)
  • Secure remote access so staff can work from anywhere
  • The ability to keep operating if a physical site is unavailable

Done well, this means an office going offline becomes a mere inconvenience and not a business-wide outage.


Governance, Testing and Continuous Improvement for DR and Continuity

Even the most elegant DR architecture is only as good as your ability to operate it on a bad day. Governance, testing and continuous improvement turn a pile of documents into something you can trust when systems are down and staff are stressed. You can have solid infrastructure and still struggle if no one knows what to do when something goes wrong. 

Start by making someone clearly accountable. In many SMEs, that will be an operations lead or practice manager, supported by a partner like Microsolve in a vCIO capacity. Their role is not to run backups or rebuild servers personally, but to own the business continuity plan, keep it current, and ensure it is actually tested.

Testing doesn’t have to mean shutting everything off in the middle of a workday. Begin with lightweight tabletop exercises once or twice a year. Pick a realistic scenario such as a ransomware attack, a regional power outage, or a failed internet link to a key site and walk through your plan with representatives from operations, finance, IT and, where relevant, clinical leadership.

Ask practical questions:

  • Who declares an IT disaster and triggers the plan?
  • How quickly can we confirm what’s affected?
  • Which systems and sites do we bring back first, and in what order?
  • How do we fall back to manual processes if recovery takes longer than expected?
  • Where are contact lists for key vendors, and who has authority to approve emergency changes or spend?

Then layer in technical tests. Quarterly or biannual restore drills of actually recovering a server, a database or a Microsoft 365 mailbox from backup, give you confidence that your tools work and your RPOs are real, not just aspirations. Simulate the loss of a site by failing over one non-critical workload to your DR environment and checking access from a branch office or home. Governance ties everything together over time.

It's imperative to review business continuity and DR as a standing item in management meetings at least annually: revisit RTOs and RPOs, update for new systems or sites, and capture lessons from incidents and near misses. Align this with your broader cyber and IT roadmap so improvements to networks, cloud platforms and managed support directly strengthen resilience instead of happening in silos.

For SMEs that don’t have the internal bandwidth to design and run this cycle alone, partnering with a provider that combines managed support, cloud expertise and continuity planning (like Microsolve!) is often the simplest path. Your team stays focused on clients, residents and patients, while the mechanics of backups, failover, documentation and testing happen quietly in the background.

The Bottom Line

You don’t need an enterprise budget or a perfectly engineered environment to improve resilience.

What you do need is a clear understanding of what matters, a design that supports recovery, and a plan that’s been tested before you actually need it.

Because when something goes wrong and trust me, at some point it will, you won’t be starting from scratch. You’ll be relying on the decisions you’ve already made.

Share this post