
Part of the Education Series by Advisory
Unpatched devices are one of the most predictable, and preventable, sources of security incidents in any organization. Security research consistently shows that the majority of successful breaches exploit vulnerabilities for which a patch already existed at the time of the attack. The fix was available. It just wasn’t deployed.
Yet for most IT teams, patch management remains one of the messiest, most inconsistent parts of the job. Patches get pushed manually, tested insufficiently, and deployed inconsistently. Some devices stay current. Others run OS versions two major releases behind. And nobody has a clear, real-time view of where things stand.
This guide will walk you through how to design a patch management and device compliance strategy that actually holds, across macOS, Windows, and mixed environments, so you can stop reacting to vulnerabilities and start getting ahead of them.
Why Patch Management Fails in Most Organizations
Before getting into what good looks like, let’s diagnose why the current state is usually broken.
Patches are treated as one-time events, not a continuous process. IT teams push updates when something breaks or when an auditor asks. There’s no defined cadence, no ownership, and no enforcement. Devices gradually drift out of compliance with no one noticing until it matters.
There’s no visibility into the true state of the fleet. Without proper tooling, you’re guessing. You might run a monthly report on OS versions, but you have no real-time view of which devices are missing critical patches or which users have been dismissing the “Update Available” prompt for three months.
Patching breaks things—and nobody wants to own that risk. This is the honest truth. A bad patch can break a critical application or cause instability. Most IT teams have war stories. So patches sit in queue, “pending testing,” indefinitely. The risk of inaction feels abstract. The risk of action feels immediate.
Application patching is treated as optional. Most teams focus on OS updates and ignore application vulnerabilities. But browsers, PDF readers, and video conferencing tools all have exploitable vulnerabilities. OS-only patching leaves a massive attack surface unaddressed.
Step 1: Define What “Compliant” Means
Before you can enforce compliance, you have to define it. Most organizations skip this step and go straight to tooling—which is why their tooling never quite does what they want.
Compliance policy should answer these questions in writing: What is the maximum acceptable OS version lag? How quickly must critical patches be deployed? Which applications are in scope? What happens to a non-compliant device?
For most organizations, a reasonable baseline looks like this:
| Policy | Threshold |
| OS version currency | Current release or N-1 (one major version behind) |
| Critical/security patches | Deployed within 14 days of release |
| Standard patches | Deployed within 30 days of release |
| Application patching | Reviewed and deployed monthly |
Adjust these thresholds based on your risk tolerance and compliance requirements. What matters is that you write them down, get leadership sign-off, and build your tooling to enforce and report against them. If you’re working toward SOC 2, HIPAA, or ISO 27001, this documentation isn’t optional—auditors want to see written policy and evidence it’s being enforced.
Step 2: Platform-Specific OS Patch Management
The right approach differs significantly between macOS and Windows, which is why mixed-environment organizations often struggle.
Patching macOS with Jamf
Jamf is the right tool for macOS patch management. It gives you the control and visibility you can’t get from generic MDM tools.
For OS updates, Jamf lets you deploy macOS updates to specific device groups with configurable deferral windows—users can postpone for up to X days before the update becomes mandatory. For application patching, Jamf patch management policies can automatically deploy new versions when they’re released and surface a real-time dashboard showing which devices are running outdated software.
The most powerful—and most underused—feature is staged rollouts via smart groups. Deploy first to a 5-10 device pilot group (typically IT staff), then expand department by department, then enforce organization-wide with a deadline. If the pilot surfaces issues with a specific update, you have time to investigate before it affects everyone. This solves the “patches break things” problem without leaving devices unpatched indefinitely.
Patching Windows with Microsoft Intune
For Windows devices, Intune and Windows Update for Business is the native, cost-effective choice—especially for organizations already on Microsoft 365.
The core concept is update rings: staged deployment groups that mirror the Jamf approach. A standard structure is a Pilot ring (IT staff, updates immediately), an Early Adopters ring (7-day delay), a Standard ring covering most users (14-21 day delay), and a Deferred ring for devices running business-critical applications (30+ days).
Treat Quality Updates (monthly security patches) and Feature Updates (major Windows versions) differently. Quality Updates should deploy quickly—a 14-day maximum window is reasonable. Feature Updates warrant more thorough testing, with a 90-day deferral for most users.
Intune’s compliance policies let you define what a compliant Windows device looks like—minimum OS version, BitLocker enabled, Defender active, no pending critical updates older than X days—and take automated action when devices fall out of compliance. When integrated with Azure AD Conditional Access, a non-compliant device can be blocked from accessing corporate resources until remediated. That turns compliance policy from aspirational documentation into enforced reality.
Step 3: Don’t Skip Application Patching
OS patching gets most of the attention, but application vulnerabilities drive a significant share of real-world attacks. Your application patching strategy needs a software inventory (you need to know what’s installed before you can manage updates), a defined owner for each application category, and a deployment mechanism.
For applications deployed through your MDM, you own the updates—automate them. For applications outside the native MDM catalog, third-party patching tools like Patch My PC or Automox can extend coverage. Monthly is a reasonable cadence for most applications. Emergency security patches (like critical browser updates) should deploy within 72 hours.
Step 4: Monitor Continuously and Remediate Actively
Patching is only as good as your visibility into what’s actually happening. Build dashboards and alerts around these key metrics: OS compliance rate (target 95%+), patch deployment rate within your policy window, application version compliance, and failed patch installations.
A compliance report that sits in a folder is theater. For each category of non-compliance, define a playbook. OS version lag: send automated notification with a deadline; escalate to manager if unresolved. Failed patch installation: create a helpdesk ticket automatically and track to closure. Device not seen in 30+ days: flag immediately—a device that hasn’t checked in with your MDM is a security risk.
Step 5: Handle the Human Side
The technical infrastructure is only part of the equation. Users turn off laptops at the end of the day, ignore update prompts, and travel constantly.
Communicate proactively before deployments. Design deferral windows that balance flexibility and security—a 72-hour window with a mandatory deadline is a reasonable middle ground. Make the update experience seamless (bad experiences create resistance). And for users who repeatedly exhaust their deferrals, escalate through the manager relationship rather than leaving IT as the sole enforcer.
What Compliance Frameworks Actually Require
If you’re pursuing SOC 2, HIPAA, or ISO 27001, patch management is specifically required—not implied. Auditors want your written policy, evidence that patches are deployed in accordance with it, and compliance reports showing your fleet meets the standard. CIS Benchmarks are a useful reference for platform-specific patch cadence and configuration hardening regardless of your specific framework.
The common thread: you need written policy, tooling that enforces it, and evidence you can produce on demand. “We patch things when we remember to” is not a compliance posture.
The Bottom Line
Patch management is one of the least glamorous parts of IT operations—and one of the most consequential. The organizations that get breached via unpatched vulnerabilities aren’t negligent. They’re running on informal processes, without visibility into what’s out of date and without tooling to enforce compliance at scale.
You don’t need a perfect program overnight. You need a written policy, proper MDM enrollment across your fleet, staged rollout automation, and a weekly compliance review. Start there and build from it.
Advisory manages patch management and device compliance as a core component of our fully managed IT service. We deploy and maintain Jamf and Microsoft Intune patch policies, provide real-time compliance dashboards, handle remediation proactively, and produce the documentation your auditors need. If your patch program is held together with manual processes and good intentions, let’s talk.
Visit www.advisorymsp.com to schedule a consultation.
Advisory is an Apple Premium Technical Partner, Jamf Elite Partner, Microsoft Partner, and Google Partner. We provide fully managed IT services for companies with 50-500 employees across AdTech, SaaS, E-commerce, Creative Agencies, and Professional Services.