What Happens When Systems Go Down — Our DR and Continuity Plan
Systems fail. Links drop, servers fall over, buildings become inaccessible. The question is never whether it happens, but how long it takes to get back and how much is lost.
This article explains what’s in place, what you’ll actually experience, and what’s expected of you.
Two different things
People use these interchangeably, and they’re not the same.
Business continuity is about keeping the work going during a disruption. Different desks, different site, phones instead of the dialler, manual process instead of the system.
Disaster recovery is the technical half — restoring the systems and data themselves from backups and standby infrastructure.
You’ll mostly experience the first. IT handles the second.
What’s in place
Redundant connectivity. We run a primary link and a secondary path so that losing one provider doesn’t take the floor offline. Frampol Africa manages the primary, TelOne provides the disaster recovery link.
Protected power. UPS on network equipment, servers and workstations, with generator behind it. Covered in more detail in the load shedding article.
Backups. Business systems are backed up on a defined schedule and held off the primary site, so a failure of one doesn’t take the copies with it.
Endpoint protection and monitoring. SentinelOne on workstations, with Black Talon Security providing detection and response — which matters because a ransomware event is a disaster recovery scenario, not just a security one.
Two numbers that govern everything
Every system has a target for these, and they’re what the whole plan is built around.
How much data we can afford to lose. If backups run every four hours and a failure happens at hour three, three hours of work is gone. That’s a deliberate trade-off — more frequent backups cost more.
How long we can afford to be down. How quickly a system must be back before the business impact becomes unacceptable. This differs by system: the dialler matters far more urgently than a reporting tool.
Critical, client-facing systems have tighter targets than internal ones. That’s why some things come back within the hour and others take a day.
What you’ll actually see
A brief wobble. During a failover, connectivity may drop for seconds. Calls in progress may end. Log back in and carry on.
A degraded period. One system unavailable while others work. Your team leader will tell you what to do — often that means switching to a different task rather than stopping.
A stand-down. If the floor genuinely cannot work, management decides that, not IT and not individual agents.
In all three cases the pattern is the same: stay at your desk, wait for the announcement, don’t improvise.
What’s expected of you
Don’t improvise around the outage. This is the big one. Don’t work from a personal device. Don’t photograph screens to “catch up later.” Don’t move customer information into WhatsApp or personal email to keep going. The data protection rules don’t relax during an incident — and outages are exactly when well-intentioned workarounds create breaches.
Don’t log a ticket for the outage itself. IT knows. Duplicate outage tickets bury the ones reporting something genuinely different.
Do report what didn’t come back. Your machine, your login, a system that others can reach but you can’t.
Do tell your team leader what was lost. Roughly how many calls, and when. Campaign reporting needs to reflect what actually happened.
Do keep your contact details current. If we need to tell you not to come in, or to come in early, we need to be able to reach you.
Why we test
Plans that have never been tested tend to fail when they’re needed. Restores get tested to confirm backups actually restore, and failovers get exercised to confirm the secondary path carries real traffic.
You may occasionally see a scheduled test announced in the Announcements category. Those are deliberate, they’re announced in advance, and they’re not an outage.
What this has to do with the law
Zimbabwe’s Cyber and Data Protection Act requires appropriate technical and organisational measures to protect personal data — and availability is part of protection, not separate from it. Losing customer data to a failed backup is a data protection failure, not just an IT one.
Several of our clients also require documented continuity arrangements as a contractual condition. When a client asks how we’d handle a two-day outage, this plan is the answer.
Read next: Working Through Load Shedding, and The Cyber and Data Protection Act in Plain English.
Watch: Business continuity vs disaster recovery — a short clip on the distinction the first section covers.
