Most SA organisations have a ransomware recovery plan. Very few have actually run it under pressure, timed it against current infrastructure, and documented what broke. South Africa remains among the most targeted countries for ransomware on the continent, and when recovery stalls, the costs compound rapidly. A plan that has never been tested under realistic conditions is not a recovery plan. It is a document.
Here are five validation tests your business needs to run before the next attack.
Standard backup verification usually means restoring a file or server in a quiet window, with full team attention, on pre-selected data. Real recovery doesn't work that way. The test your organisation needs restores from your most recent clean backup within a defined time constraint, while other team members simultaneously manage the incident response scenario.
Measure time to first successful restore, integrity via hash verification (not just file presence), and whether backup system credentials are accessible outside the systems that would be encrypted. A common gap that surfaces in this test: backup credentials stored in Active Directory, which ransomware typically encrypts first. Discovering that mid-incident is categorically different from discovering it in a drill.
Your documented recovery time objective was probably established years ago, against a different infrastructure footprint and different data volumes. A proper RTO simulation recovers critical systems against your current environment, under realistic load, during business hours, with the access constraints that would apply in an actual incident.
The metric your board and insurers are asking about is not whether you can recover. It's whether you can recover within the timeframe stated in your business continuity documentation. Where the simulation result diverges from that target, the gap is your real risk exposure. Ongoing vulnerability management reduces the attack surface that slows recovery in the first place.
This test simulates what ransomware does to your highest-value systems: ERP platforms, payment processing infrastructure, financial reporting systems. No actual encryption takes place. The test isolates those systems from the network as if they were encrypted, then maps what the business cannot do.
Measure which transaction processes fail first, whether authorisation systems remain available, and whether manual fallback processes exist and work. Organisations operating under PCI DSS compliance obligations regularly discover during this drill that fallback processes are documented in policy but have never been tested and are, in some cases, no longer viable.
POPIA Section 22 requires notification to the Information Regulator and affected data subjects within a reasonable period after a breach is identified. Meeting that obligation under incident conditions requires the right people to be reachable, escalation paths to be active, and the notification workflow to be executable even when systems are partially down.
Recovery documentation and tested recovery capability are not the same thing. The board needs to know how long it actually takes, what breaks, and what your team does when the plan meets reality.
>
Tim Butler, Chief Operating Officer, Magix
The test verifies who gets notified and in what sequence, how legal and privacy counsel enter the process, and whether incident documentation can be generated without relying on systems that may be unavailable. The term "reasonable period" under POPIA carries regulatory weight, and a communication chain that has never been tested will not hold under actual pressure.
Most recovery plans assume cloud providers, payment processors, and ISPs are fully available during an incident. That assumption needs its own test. Map every critical recovery dependency to the specific third party it relies on, then determine what happens to your recovery timeline if that dependency is unavailable or degraded.
SA organisations face infrastructure constraints that many international recovery frameworks don't account for, including power continuity and connectivity reliability. Confirm SLAs and failover arrangements with direct conversations, not just a contract review. Magix's third-party risk management approach identifies these dependencies before they become recovery liabilities. For context on how third-party exposure has contributed to major SA incidents, the analysis in Africa's growing cybercrime crisis is relevant.
A plan that has never been tested is one you cannot rely on. Running these five validation tests produces the evidence your board, auditors, and insurers need to verify that recovery readiness is substantive, not assumed. If you're unsure where your biggest gaps sit, a structured penetration testing and vulnerability assessment can identify the weaknesses that complicate recovery before an attacker surfaces them for you. Contact Magix to run a recovery readiness assessment against your current environment.
