For two years, his laptop asked him to install a Windows update.
Every time, he clicked "remind me later." He was busy. The laptop was running fine. He'd deal with it later.
The update patched a known vulnerability in the Windows print spooler — a component that had been publicly documented as exploitable since 2021.
When he was eventually hit, the attack entered through that vulnerability. His cyber insurance carrier opened an investigation. One of their standard questions: can you provide your patch history for the 12 months prior to the incident?
He couldn't produce one.
The claim didn't go well.
What patch management actually is
Patching is the process of applying updates to software — operating systems, applications, firmware — to fix known security vulnerabilities.
When a vulnerability is discovered and publicly disclosed, it creates a window. Attackers know about it. A patch exists. The question is whether it's been applied.
For unmanaged devices — where users control their own updates — that window stays open until the user decides to close it. Sometimes that's a week. Sometimes it's two years.
Managed patch management closes that window on a schedule, across every device in your environment, with documentation of what was patched and when.
Why "Windows Update is turned on" isn't patch management
Windows Update, when left to run on its own schedule, patches the operating system. It does not patch:
- Third-party applications (Adobe, Chrome, Firefox, Zoom, QuickBooks, your industry software)
- Firmware on routers, switches, and firewalls
- Server operating systems (which often require separate patch windows)
- Line-of-business applications with their own update cycles
The majority of successful exploits in 2024 and 2025 used vulnerabilities in third-party software, not the Windows OS itself.
Turning on Windows Update is not a patch management strategy. It's one part of one.
What a managed patch policy looks like
A managed patch environment typically works like this:
- Patch scan: Your IT provider runs a regular scan of all managed devices to identify what's missing
- Patch ring: Critical security patches are tested against a sample environment before full deployment — this catches patches that break line-of-business applications
- Deployment window: Patches deploy on a scheduled window (typically overnight or weekends) to minimize disruption
- Documentation: Every patch deployment is logged — what was applied, to which device, on what date
- Exceptions: Any device that can't receive a patch is documented, and compensating controls are applied
That documentation is what an insurer asks for when a claim is filed.
The insurance connection
Cyber insurers increasingly list patch compliance as a coverage condition. Not a recommendation — a condition.
In practice, this means: if your environment was compromised through a vulnerability that a patch existed for, and you can't demonstrate that patch was applied within a reasonable window, your insurer may reduce or deny the claim.
"Reasonable window" varies by policy and vulnerability severity, but for critical patches, most insurers consider 30 days the outer limit.
What to do if you're behind
If you're not sure where your patch status stands:
- Run a free vulnerability scan — your IT provider should offer this as part of any assessment
- Identify your highest-risk gap — the oldest unpatched, publicly-known vulnerability on an internet-facing system
- Build a remediation plan — start with the highest severity, work down
- Establish a go-forward cadence — most managed IT contracts include monthly patching as a baseline
The goal isn't perfection. It's defensibility — being able to demonstrate that you applied reasonable diligence.