Patching Cadence and Exceptions: What to Patch When | Operations And Monitoring Field Guide

Your accounting software is on version 12.3.2. The current version is 12.5.1. The update includes security patches, but your IT person says "we can't update because it might break compatibility with our reporting module."

Now you're running known vulnerable software because updating feels risky.

Patching decisions shouldn't be made by gut feeling. They should follow a clear process.

What this solves

Reduces attack surface. Unpatched vulnerabilities are how most ransomware and breaches happen.

Creates predictable maintenance windows. No more "we need to update everything now" scramble.

Manages business risk. Some systems can't update without testing. That's fine — document it and manage the risk.

Supports compliance. Cyber insurance, SOC 2, HIPAA — all require documented patch management.

Recommended patching schedule

Critical and high severity patches (CVSS 7.0+)

Target: Within 5 business days of release.

Scope: Internet-facing systems, servers, anything with sensitive data.

Process: Test if possible, deploy quickly. If testing isn't possible, deploy anyway — the risk of exploitation is higher than the risk of a bad update.

CISA KEV vulnerabilities: These get priority regardless of CVSS score. Treat them as critical.

Medium severity patches (CVSS 4.0-6.9)

Target: Within 30 days of release.

Scope: Workstations, internal systems.

Process: Batch and deploy monthly during maintenance windows.

Low severity patches (CVSS 0.1-3.9)

Target: Within 90 days or next maintenance window.

Process: Include in regular monthly updates.

OS and vendor patches

Operating systems (Windows, Linux): Patch within 30 days for critical, 90 days for others.

Third-party software (Adobe, Java, browsers): Patch within 30 days. Use patch management tools to automate.

Business-critical applications: Test in non-production environment before deploying. Can take 1-4 weeks depending on complexity.

What can go wrong

Never patching. The default for many SMBs. This is the risk that causes most ransomware.

Patching without testing on business-critical systems. Updates break things. Test first.

Patching during business hours. Users get kicked off mid-work. Data can be corrupted.

Patching without rollback plan. What if the update breaks something? You need a way back.

Skipping patches because "it might break something." Unpatched systems get breached. Document the exception and accept the risk formally.

Not tracking exceptions. You made an exception once. Now it's been two years and nobody remembers why that system isn't patched.

What it costs (honest ranges)

Automated patch management tools (Automox, PDQ Deploy): $1-$4 per endpoint per month. Pays for itself in reduced manual work and faster patching.

MSP-managed patching: Usually included in managed services, $500-$2,000/month for small business.

Testing environment: $100-$500/month for a spare VM or cloud instance to test patches before production deployment.

Extended patching exception (compliance or insurance risk): Difficult to quantify, but insurers increasingly deny claims for unpatched systems.

Handling exceptions

Sometimes you can't patch. The vendor doesn't support the current version. A legacy application requires a specific OS version. The business-critical software breaks when updated.

When this happens:

Document the exception. System name, reason, date, risk accepted by.
Implement compensating controls. If you can't patch, isolate that system. Put it behind additional firewall rules. Limit access. Monitor it more closely.
Set a review date. Exceptions shouldn't be permanent. Review every 90 days.
Plan for eventual patching. When does the vendor release a compatible version? When can you migrate? Put it on the calendar.
Accept the risk formally. If the exception is approved, someone senior needs to sign off. Not just the IT person. The business owner.

Vendor questions (copy/paste)

Ask your IT vendor or MSP:

What's our current patch compliance rate?
Do we have automated patch management?
How do we handle exceptions?
What's our patching schedule?
How do we test patches before deployment?

Ask your software vendors:

When are you ending support for version X?
What's your upgrade path from version X to current?
What security patches are in the latest version?

Patching isn't optional. It's the most effective defense against common attacks. The question isn't "should we patch?" It's "how do we patch safely and consistently?" Answer that question, and you're ahead of most SMBs.