Why Patching Should Be a System, Not a Habit

Almost no one argues against patching. Every leader I talk to already knows that unpatched systems are how a large share of preventable incidents begin. Awareness has never been the problem. Consistency is.

Manual patching depends on someone remembering to do it, having the time to do it, and doing it the same way every month. That’s three separate points of failure, and they tend to fail quietly, on the busy weeks, which are exactly the weeks an attacker is counting on.

Control 7.3 closes that gap. It asks you to patch operating systems automatically, on a defined schedule, so the outcome no longer depends on anyone’s memory or spare hour.

What this control actually says (in plain English)

If you are not a technical reader, here’s the translation: the computers and servers your business runs on should update themselves, on a schedule you set, without waiting for a person to kick it off.

Now the official version. Control 7.3 says you should perform automated operating system patch management, applying operating system updates on a monthly or more frequent cadence.

That is not busywork. That is operational maturity.

Why business leaders should care

You already run the important parts of your business this way. You don’t rely on someone remembering to run payroll. You put it on a schedule, you automate it, and you verify it happened. Patching deserves exactly that treatment, because the cost of a missed month is not a late paycheck. It’s the opening an attacker uses to get in.

There’s a second reason this belongs on a leader’s radar rather than buried in IT. Patching only works when it sits on top of the groundwork this series has already covered. You can’t patch what you don’t know you own, which is why we started with Establish and Maintain a Detailed Enterprise Asset Inventory. And automation only helps if you actually know what software is running and that it is still supported, which was the point of the spotlight on Why a Software Inventory Is More Than a Security Requirement. Automated patching isn’t a new discipline dropped on top of your environment. It’s what visibility and a known, supported software estate finally make possible.

The fear worth addressing: “an update once broke something”

The most common objection I hear is fear of breakage. A leader remembers the one update that took down a critical application, and that memory becomes a reason to patch slowly, or not at all.

That fear is understandable, and it’s solvable. Automated patching does not mean reckless patching. Modern tooling rolls updates out in stages, or rings: a small pilot group of machines goes first, and anything disruptive is caught there before it ever reaches the whole company. Reboots get scheduled for off hours instead of the middle of the workday. Done well, automation gives you more control over the process, not less, because the behavior is decided in advance instead of improvised under pressure.

A setting someone turned on once is not a control

When I wrote about host firewalls in Why “Default Closed” Is a Business Advantage, I made a point that applies just as cleanly here: a setting someone enabled once is not a control. A control is something you can define, enforce, verify, and report on.

“Automatic updates are on” is not an answer. It’s an assumption. The questions that actually matter are the operational ones:

• Who owns patch outcomes for the whole fleet?
• What’s our coverage this month, and which machines are behind?
• Which systems are exceptions, and why?
• How would we spot drift before it becomes an incident?

Those aren’t technical questions. They’re operational ones, and they’re the difference between a policy that exists on paper and a practice that protects the business.

What “good” looks like

You don’t need to become a patch-management expert to get this right. You need to treat it like any other operational control: set the standard, automate the enforcement, and verify continuously. Here’s the practical path, by platform.

Windows. Use Windows Update for Business or Windows Autopatch through Intune, or your RMM platform, to enforce updates on a defined schedule. Configure update rings so a pilot group patches first. Set the monthly cadence at the policy level so it is never left to individual users.

macOS. Enroll Macs in Intune or Jamf and enforce operating system update settings from the same console, so your standard stays consistent no matter what hardware your team runs.

Servers. Apply the same discipline with defined maintenance windows and staged rollout, so critical systems are updated predictably rather than whenever someone finds time.

Verify and report. If you can’t confirm the control is in place, you can’t rely on it. Pull a monthly coverage report, track exceptions deliberately, and treat any machine that can’t be patched automatically as a decision to be made, not a gap to be ignored.

The quiet payoff

There’s a benefit here that leaders appreciate once they see it. Automation frees your best people from a repetitive, low-judgment chore and lets them spend their attention on work that genuinely needs a human. A team that isn’t spending the last week of every month chasing update status is a team with room to improve everything else.

And it produces something manual patching almost never does well: evidence. Every automated cycle generates a record of what was updated, when, and on which machines. That record is exactly what an auditor, a cyber-insurance underwriter, or a security-conscious client will ask you to show. When you can demonstrate that your systems are patched on a schedule, that coverage is measured, and that exceptions are tracked and justified, you’re no longer asserting that you take security seriously. You’re proving it.

That’s the whole idea behind this series. Take a task everyone agrees is important, remove the human inconsistency that quietly undermines it, and turn it into a dependable system that strengthens the business every month without drama. That’s operational maturity, and it’s within reach for any organization willing to decide how its environment should behave and then hold it to that standard.