Patch Management: The Boring Task That Stops Most Breaches

If you could only do one thing to protect a business from a cyber attack, it would not be a fancy firewall or a clever piece of detection software. It would be keeping everything up to date. Patching is the least exciting task in security and the one that prevents the most damage.

The reason is simple. Most attacks do not use some unknown, brilliant new method. They use a hole that was found months ago, that the vendor already fixed, on a system nobody got around to updating. The fix existed. It just was not applied.

Why patching gets neglected

Nobody neglects patching on purpose. It slips because it is endless and invisible. There is no finish line. The moment you update everything, new updates appear. And when it is done well, nothing happens, which makes it very hard to feel good about the time spent.

So it gets deferred. Just this once, during a busy week, the update waits. Then the busy week becomes a busy month. The gap between the fix being available and the fix being applied is exactly the window an attacker needs.

There is also a fear factor. Applying a patch might break something. That fear is legitimate — bad patches happen. But the answer is not to stop patching. The answer is to test before you deploy, which is a process, not a reason to defer indefinitely.

What good patch management looks like

The goal is not to apply every update the instant it appears. That can break things. The goal is a deliberate process, repeated reliably.

Know what you have. You cannot patch a system you have forgotten exists, which is why this connects directly to keeping an accurate asset register. The forgotten server in the corner is the one that gets you. The unpatched device that nobody knows about is the entry point that your security tooling is not watching.

Prioritise by risk. A critical flaw on a system exposed to the internet gets fixed now. A minor issue on an internal machine can wait for the scheduled cycle. Not everything is urgent, but knowing which is which takes judgement. This is where automation helps — it can tell you which systems are behind and by how much, but a human still needs to decide the order.

Test before you deploy widely. Apply important updates to a small group first, confirm nothing broke, then roll out. This is how you avoid the cure being worse than the disease. A good patching process has a test group, a deployment window, and a rollback plan.

Keep a record. Write down what was patched and when. This is what separates a managed process from a hopeful one, and it is the evidence you should expect from any provider. We covered this in what managed IT actually includes — a provider who cannot show you a patching record is not really managing anything.

The compliance angle

For South African businesses there is a second reason to take this seriously. Under POPIA, failing to maintain reasonable security measures is not just risky, it can be a breach of your legal obligations. Patching is about as reasonable and basic as a security measure gets. A regulator asking whether you took reasonable steps to protect personal information is not going to accept “we were too busy to apply updates” as an answer.

The ongoing nature of compliance is the part that catches people out. POPIA is not a certificate you earn once. It is a set of practices you maintain. Our colleagues cover this in POPIA is not a once-off exercise — the same principle applies to patching. It is not a project with a completion date.

Why this matters more than the exciting stuff

Organisations spend significant budget on security tools — firewalls, endpoint detection, SIEM platforms — and then leave known vulnerabilities open for months. That is like fitting a state-of-the-art alarm system and leaving the back door open. The alarm will tell you someone broke in. Patching would have prevented the break-in entirely.

None of this is clever. That is the point. The boring, repeated, well-recorded task is the one that quietly does the most. The organisations that have their patching under control are the ones that sleep at night. The ones that do not are the ones that show up in breach reports.

The bottom line on patching

The organisations that have their patching under control are not the ones with the biggest security budgets. They are the ones with a process — deliberate, repeated, recorded, and reviewed. That process is within reach of any organisation, regardless of size. The tools exist. The knowledge exists. What it takes is the discipline to make it happen consistently and the visibility to know when it has not.

If your organisation does not have that process today, that is not unusual. Most do not. The question is whether you are going to build it before or after something forces you to. The managed IT services conversation and the continuous monitoring conversation both start with knowing what you have and whether it is current. Patching is where that knowledge meets action.