What we do
We design, implement, and operate the disciplines that keep an organisation’s data and operations available when things go wrong — and the practices that prove they will, before they have to.
Most providers describe this work as “backup.” We do it as four distinct disciplines, because backup is only one of them. Backup, archive, disaster recovery, and business continuity each solve a different problem. Treating them as the same problem is how organisations end up with backups that protect against the wrong failure modes, recovery times that do not match the business need, and audit findings that are hard to defend.
When organisations need this
Most clients come to continuity work for one of a few reasons:
They have looked at their current arrangement honestly — or had someone look at it for them — and concluded they are not confident they could recover. The backup software is running. Whether the data is actually recoverable, in what timeframe, with what integrity, is unclear.
A regulator, insurer, or major client has asked them to demonstrate continuity arrangements with evidence. They need a documented plan, tested recoveries, and reporting that shows the disciplines are operating.
They have lived through an event — a hardware failure, a system corruption, a near-miss with ransomware, a critical staff departure that revealed how much was undocumented. Whatever the event was, it surfaced the question of what would happen if it had been worse.
They are growing into a scale where ad-hoc arrangements no longer hold. The backup that worked when the business was small and the data was simple is straining under the weight of what the business has become.
If your situation does not look like one of these, continuity work may not be the right starting point. Our advisory work (separate practice area) is often a better entry point — we can help you work out what continuity discipline you actually need, before any implementation begins.
How we approach the work
Continuity work runs continuously, but the underlying disciplines are deliberate. The most important discipline is the one most providers skip.
The four practices are different. Backup, disaster recovery, business continuity, and archive solve different problems. Conflating them produces arrangements that protect against the wrong things or recover at the wrong speed.
Backup is the discipline of preserving copies of data so they can be restored if the original is lost or corrupted. The horizon is short — recent copies, frequent intervals, fast access for routine restoration. The goal is to undo small disasters quickly: a deleted file, a corrupted database, a ransomware-encrypted share.
Disaster recovery is the discipline of restoring systems to operation after a major failure — a site loss, a critical infrastructure failure, a successful attack that compromises the environment broadly. The horizon is broader. The goal is to bring the business back up at a defined recovery point and within a defined recovery time, often at a different location, with documented procedures the team can follow under pressure.
Business continuity is the broader discipline of keeping the business operating through disruption. It includes the technology recovery, but it also includes the people, the processes, the alternative arrangements, the communications, and the decision-making. Business continuity is what disaster recovery serves.
Archive is the discipline of preserving data for long-horizon retention — for legal, regulatory, or operational reasons — separately from the active backup. Archive is not the place you go to recover yesterday’s deleted file. It is the place you go to find the contract from seven years ago, the email thread from a closed transaction, the historical record that compliance requires.
The four are designed differently. Backup is high-frequency, short-horizon, fast access. DR is structured around recovery point and recovery time objectives. Business continuity sits above the technology. Archive prioritises immutability and long-term retrievability over speed.
Test the recovery, not just the backup. The most common failure mode in continuity arrangements is not that backups fail — it is that recoveries do. Backups run for years, evidence accumulates, everyone is reassured. Then a real recovery is needed and discoveries get made: the data restores but the application does not start. The application starts but the integration is broken. The integration works but the data is from before the corruption began. We treat recovery testing as a standing discipline, scheduled and documented, with results that count as evidence. A backup that has not been recovery-tested is hopeful storage.
Document the assumptions. Every continuity arrangement is built on assumptions — about recovery point, recovery time, data sensitivity, retention period, restoration sequence, dependency order. We document these explicitly, with the client, before the arrangement goes live. The documentation is what makes the arrangement defensible to an auditor or an insurer, and it is what makes the recovery actually work when it is needed.
Operate inside the security model. Continuity is one of the operational outcomes the Information Security Management practice protects. Backup integrity, immutability, access control, and restoration procedures all sit inside the security framework — not as separate “secure backup” features.
What we cover
We organise continuity work around the four disciplines rather than around backup tooling.
Backup. Routine backup of servers, workloads, virtual environments, file shares, databases, and SaaS data. Local recovery for fast operational restoration. Offsite copies for protection against site-level events. Immutability where the threat model warrants it. We work with the leading backup platforms for on-premises and cloud workloads, and the right platform for a client’s environment is the one we choose with them — not the one we have a margin on.
SaaS and cloud workload backup. Microsoft 365, productivity platforms, and other SaaS applications need their own backup discipline. The provider’s resilience does not protect against accidental deletion, ransomware in shared content, or compliance-driven retention requirements. We operate the backup of these platforms separately from on-premises systems, with the same disciplines applied.
Disaster recovery. Recovery point and recovery time objectives defined with the client and tested against. Documented runbooks for the major failure scenarios. Regular DR exercises — not the box-tick kind, but the kind where the team actually walks through the recovery and discovers what does not work yet. Where appropriate, hot or warm standby arrangements; where appropriate, cold recovery from offsite copies. The right DR shape depends on the business — we help clients decide.
Business continuity. Continuity planning that connects the technology recovery to the business decisions around it — communications, alternative arrangements, key personnel, decision authority during an incident. We do this work alongside the technology recovery rather than as a separate consulting engagement. The plan is not a document that sits on a shelf; it is a working artefact that gets exercised and updated.
Archive. Long-horizon retention for compliance, legal, and operational purposes. Separate from active backup. Designed for immutability, integrity, and retrievability over time horizons measured in years. Where regulatory requirements drive retention (POPIA, FSCA Joint Standards, contractual obligations), we work to those requirements specifically rather than applying a generic policy.
What you get
A continuity arrangement that has been designed, documented, tested, and is being operated. Specifically:
A documented continuity design — what is being protected, against what failure modes, with what recovery objectives, on what schedule, with what dependencies. The design is the foundation; without it, the rest is theatre.
Working backup, DR, business continuity, and archive disciplines, each shaped to the actual need rather than collapsed into a single arrangement.
A schedule of recovery testing with documented results. Real tests — actual restores into actual environments, with actual verification — not “the backup completed without errors” check-boxes.
Documented runbooks for the recovery scenarios the client faces. The kind of runbook a team member can follow under pressure, when the senior people are unreachable and the situation is not the textbook case.
Reporting that means something. Not a monthly green-light dashboard, but a record of what was protected, what was tested, what was learned, and what is changing.
For clients on a managed continuity engagement, this is the ongoing deliverable — month after month, year after year. Continuity is not a project that finishes.
A note on offensive testing
Continuity work occasionally surfaces the question of testing the arrangement against active attack — for example, simulating a ransomware event to see whether the backup discipline holds up. WR360 is a defensive security practice; we do not perform offensive testing or simulated attacks. Where this kind of testing is genuinely needed, we arrange it through trusted independent partners, with the right scope and the right report. The reasoning is on the Monitoring and Response page in full.
Who this is for
Organisations that cannot afford data loss or extended downtime — and have started thinking honestly about what their current arrangement actually protects against. We see this most often in finance, manufacturing, and legal sectors, where data has direct compliance and operational consequence.
It works for organisations that have outgrown an arrangement that worked when the business was smaller. The backup that has been running for years, the DR plan that has not been tested in eighteen months, the archive that lives on a fileshare nobody is sure is being copied — these are the kinds of arrangements continuity work properly addresses.
It works for organisations with regulatory or contractual obligations around data retention, recoverability, or business continuity — where the arrangement has to be defensible, not just functional.
It works less well for organisations that want the cheapest backup product. The work is real, the disciplines take time, and the cost reflects what is being delivered.
It does not work for organisations that want a checkbox without the substance behind it. Continuity arrangements that look fine on paper but have never been tested are common. We will tell you so, and we will not produce the same arrangement for you.
How we work with you
Continuity engagements typically run as ongoing managed-services relationships, structured around an agreed scope, an agreed set of recovery objectives, and a documented testing schedule. The commercial shape varies — see Engagement Models for detail.
A typical pattern is a defined-scope project to design and implement the arrangement (or to remediate an existing arrangement that needs work), followed by an ongoing managed-services relationship to operate it. The implementation is finite. The operation is not.
We work alongside internal teams where they exist. The continuity arrangement is the client’s; we operate it on their behalf, document it for them, test it with them, and leave them better able to defend it.
What it looks like in practice
We apply the same continuity disciplines to ourselves. WR360’s own data — service desk records, documentation system, monitoring data, accounting data, communications history — is backed up, replicated, and recoverable on disciplines we have tested ourselves. We have walked through the recovery exercises we recommend to clients. We do not recommend disciplines we have not lived inside.
This is also what makes our recovery testing argument credible. We have run the tests on our own environment. We have found the things that did not work. We have rebuilt the runbooks based on what was learned. The discipline came from being on the receiving end of it, not from reading about it.
A few honest things to know
Most clients arrive thinking about backup. The reason is often ransomware — it is the threat that has shaped how the market thinks about backup over the last several years, and most prospective clients have at least one ransomware story in mind. We address ransomware directly through the same disciplines that protect against every other failure mode: tested recovery, immutability where warranted, segregation, documented runbooks. But ransomware-as-headline tends to produce arrangements optimised for one threat at the expense of the broader risk picture. The discipline serves the client better than the threat.
Continuity work also reveals things. The first proper continuity engagement often surfaces gaps that previous arrangements left behind — backups that were never tested, archive policies that did not match the regulatory requirement, DR plans that assumed people who have since left. We are clear about this up front: the work involves finding out what is not working before we can make it work properly.
We will sometimes recommend reducing the protection in some areas. Continuity arrangements that protect everything equally are rarely the most defensible — they are usually the most expensive and the least focused. Part of the work is deciding what genuinely needs short recovery time and what does not, what genuinely needs long retention and what does not. The right answer is rarely “everything, equally.”
We do not provide continuity arrangements without the disciplines around them. The technical implementation is achievable in many ways; the disciplines that make it actually protect the business are what we charge for. If you want a backup product without the operating practice around it, we are not the right provider — and that is fine.
What this connects to
Continuity does not stand alone. It is one face of the practice.
The Information Security Management System practice is what continuity arrangements are governed by. Backup integrity, immutability, retention, and recovery procedures all sit inside the security framework.
Advisory and Architecture is where continuity decisions are shaped before they are committed to. Recovery objectives, retention requirements, archive scope — these are advisory questions before they are operational ones.
Technology Operations is where continuity arrangements are operated alongside the rest of the environment. The two are coordinated rather than separated.
Monitoring and Response is what tells continuity whether it is working. Backup failures, replication lag, integrity errors — these are monitoring concerns, surfaced through the same disciplines that surface security and infrastructure events.
Procurement is downstream of continuity decisions. Once the design is settled, procurement is how the backup software, storage, cloud capacity, and supporting arrangements come into the practice.
Want to talk?
The fastest way to start is a conversation. Tell us about the data and operations you are trying to protect, what your current arrangement looks like, and what is making you uncertain about it. We will read it carefully and reply.