What does good patch management look like for South African businesses?

Good patch management automatically updates Windows, macOS and Linux plus third-party applications such as browsers, Adobe products and Java, deploys in staged rings, controls reboots around outages, and produces compliance evidence. This matters in South Africa because unpatched software and stolen credentials are leading breach vectors, and the country is Africa's most-targeted for ransomware.

Why is patching a security priority in South Africa?

The threat data is unambiguous.

INTERPOL's African Cyberthreat Assessment Report 2026, released on 3 August 2026, found that South Africa accounted for 92% of all ransomware detections across Africa in 2025, along with 70% of business email compromise detections. Trend Micro data cited in INTERPOL's assessment recorded 17,849 ransomware detections in South Africa in 2024. Whatever the reason — the size of the formal economy, the concentration of financial services, the volume of connected endpoints — South Africa carries a disproportionate share of the continent's ransomware burden.

The financial consequence is well documented. IBM's 2025 Cost of a Data Breach Report, based on research conducted by the Ponemon Institute covering breaches between March 2024 and February 2025, puts the average South African data breach at R44.1 million (approximately US$2.45 million). That is down 17% from R53.1 million the previous year, but it remains a figure that would end most mid-sized businesses. The South African financial sector fared worst at an average of R70.2 million, and detection and escalation was the single largest cost category at R17.5 million.

Patching addresses this directly because exploitation of unpatched software remains one of the most common initial access routes, alongside stolen or compromised credentials. It is also the cheapest control available — it costs configuration time rather than licence fees.

The June 2024 ransomware attack on the National Health Laboratory Service, in which more than a terabyte of data was compromised and diagnostic services were disrupted nationally, is the local case study most people remember. It is a reminder that the consequences are not only financial.

What must a patch tool cover?

All the operating systems you actually run. Windows is a given. Confirm macOS and Linux support explicitly if you have them, and check the depth of that support — some platforms technically "support" macOS while offering far less control than they do for Windows.

Third-party applications. This is where most estates are weakest. Browsers, Adobe Reader and Acrobat, Java, Zoom, 7-Zip, VLC, Notepad++ and dozens of others are frequently exploited and frequently unpatched, because they sit outside Windows Update. Ask how many applications are in the vendor's catalogue and whether the list includes the ones you actually deploy. Patch-focused platforms such as Action1 and ManageEngine Endpoint Central compete specifically on catalogue breadth.

Firmware and drivers, at least for the major hardware vendors, where the platform supports it.

Reporting. A patch tool that patches but cannot prove what it patched leaves you unable to answer an auditor, an insurer or a client.

What is ring-based deployment?

Ring-based (or staged, or phased) deployment means you do not push a patch to every device at once. Instead you define groups and release progressively:

• Ring 0 — pilot. A handful of IT-owned devices. Deploy immediately.
• Ring 1 — early adopters. A representative sample across departments or clients, perhaps 5–10% of the estate. Deploy after 24–48 hours if Ring 0 is clean.
• Ring 2 — broad deployment. The bulk of the estate, after another few days.
• Ring 3 — critical systems. Servers and business-critical machines, deployed last and in a controlled window. The purpose is containment. Patches occasionally break things, and a bad patch that reaches 12 devices is an inconvenience while the same patch reaching 600 is an outage. The trade-off is exposure time, so critical security patches — particularly those addressing actively exploited vulnerabilities — should move through the rings faster or bypass them entirely.

Ask whether the platform supports device groups with independent schedules and approval gates, and whether you can pause or roll back a deployment mid-flight.

How do you patch around load shedding and constrained bandwidth?

This is where South African patch management diverges from the generic advice.

Schedule around known outages. A 700MB download that starts at 02:00 and is interrupted at 02:30 may restart from zero, doubling data consumed and producing a failure alert. Where load reduction or municipal outage schedules apply to a site, set patch windows to avoid them.

Cache patches locally. Thirty devices each downloading the same cumulative update over a capped LTE link is 21GB. With a local distribution point or peer-to-peer distribution, it is closer to 700MB. This is covered in more depth in the post on agent bandwidth, but it belongs in your patch configuration decisions.

Control reboots. Patching often requires a restart. Forced reboots during business hours are how IT departments become unpopular; deferred reboots indefinitely are how patches remain uninstalled. The workable middle is a deferral window with a hard deadline, plus the ability to exclude servers from automatic reboot entirely.

Use resumable downloads and automatic retry. Confirm the platform does both. On unstable connections this is the difference between a patch cycle that completes and one that needs manual attention every month.

What patch evidence do POPIA audits need?

POPIA Section 19 requires a responsible party to secure the integrity and confidentiality of personal information by taking appropriate, reasonable technical and organisational measures. It does not list "install patches" as a specific requirement, but unpatched systems are difficult to defend as an appropriate and reasonable measure — particularly after an incident.

Practically, the patch reporting that helps you demonstrate compliance includes:

• Current compliance percentage by device, group or client.
• Missing critical patches, with age — how long has a known-exploited vulnerability been open on your estate?
• Deployment history — what was installed, when, and on which devices.
• Failure records — which devices failed to patch and why, showing that failures are tracked rather than ignored.
• Exclusions and exceptions, with recorded justification. If you are an MSP, you additionally need this per client, exportable, because your client's Information Officer may need it and because your operator agreement likely obliges you to maintain safeguards. Keep the reports; a report you can generate today but did not generate at the time is much weaker evidence than a dated record.

What should you ask a vendor?

1. Which operating systems, and how complete is macOS and Linux support relative to Windows?
2. How many third-party applications are in your catalogue, and can I request additions?
3. Do you support ring-based deployment with independent group schedules?
4. Can I pause, cancel or roll back a deployment in progress?
5. Can patch windows be set per site, and can they avoid scheduled outages?
6. Do you support local caching or peer-to-peer distribution?
7. Are downloads resumable and do failures retry automatically?
8. What reboot control options exist — deferral windows, hard deadlines, server exclusions?
9. What patch compliance reports can I export, and in what formats?
10. How long is patch history retained?

FAQ

How often should I patch? Monthly is the practical baseline for routine updates, aligned to Microsoft's Patch Tuesday cycle. Critical patches for actively exploited vulnerabilities should be deployed within days, not weeks — move them through your deployment rings faster or bypass the rings.

Does patching cover third-party applications? Only if your tool supports it. Windows Update does not patch Chrome, Adobe Reader or Java. Third-party patching is a distinct capability and catalogue breadth varies widely between platforms, so check it against your actual application list.

Can I schedule patches around outages? Good platforms let you set patch windows per site, which lets you avoid known load-reduction or maintenance windows. Also confirm that interrupted downloads resume rather than restart.

Is patch reporting useful for POPIA? Yes. POPIA Section 19 requires appropriate, reasonable technical measures to secure personal information, and dated patch compliance records are practical evidence that you took them. MSPs should be able to produce these per client.

What about devices that are rarely online? Laptops that connect intermittently are a common gap. Ask how the platform handles devices that miss their window — good tools patch on next check-in rather than skipping the cycle.

Suggested internal links

• Should your RMM include antivirus, EDR and backup?
• What POPIA evidence should your RMM produce?
• How much data does an RMM agent use?

Sources to cite in the published version

• INTERPOL, African Cyberthreat Assessment Report 2026 (released 3 August 2026): South Africa = 92% of Africa's 2025 ransomware detections; 70% of BEC detections
• Trend Micro data via INTERPOL: 17,849 ransomware detections in South Africa, 2024
• IBM / Ponemon Institute, Cost of a Data Breach Report 2025: South Africa average R44.1 million (US$2.45m), down 17% from R53.1m; financial sector R70.2m; detection and escalation R17.5m
• National Health Laboratory Service ransomware incident, June 2024

Methodology caveat: IBM's South African sample is a small portion of roughly 600 organisations surveyed globally. Attribute the figure by source and year rather than presenting it as a national statistic.