Docs
How Patch Compliance Is Calculated: Installed, Available, Approved, and Why the Math Moves
Learn how patch compliance is calculated in MSP patching tools, including installed, available, and approved updates and why the denominator changes constantly.
Guide for MSPs and IT admins who need a clear explanation of compliance math
Free Audit
Run The Free Audit
If you need to separate stale scans, reboot debt, failure signals, and real patch risk across endpoints, run the free RMM Patch Health Audit.
Patch compliance is usually calculated as a ratio between the updates a Windows endpoint is expected to have and the updates the tool believes are already installed. That sounds simple, but the math moves because the expected update set changes constantly.
This guide explains the installed, available, and approved model in plain language so your team can stop treating compliance math like proof of patch success.
Use Microsoft's update troubleshooting guidance as the source-of-truth baseline when explaining how approved and applicable update state changes over time. Microsoft Learn: Windows Update issues troubleshooting
What You'll Get
- Understand the installed, available, and approved update model behind compliance scoring
- See why denominator changes make compliance percentages more dynamic than they appear
- Separate compliance math from actual patch success
Simple Explanation First
Direct answer: patch compliance is usually calculated by comparing updates believed to be installed against updates currently considered approved and applicable to the device.
The percentage moves because the numerator and denominator can both change, especially after new releases, policy changes, supersedence, and reboot-completion events.
Patch compliance is usually a ratio, not a yes-or-no state. Most tools compare updates that are installed against updates they currently believe should be installed.
The tricky part is that both the numerator and denominator can change, but the denominator changes more often than most MSPs expect. That is why the math can move even when patching seems steady.
How Compliance Is Calculated
A simple model looks like this: installed approved updates / total approved applicable updates.
In practice, that means three questions matter:
- Installed: which updates does the platform believe are already on the device?
- Available: which updates are currently considered relevant to the device?
- Approved: which of those available updates count toward your policy target?
Change any of those three, and the percentage changes. That is why patch compliance percentage meaning is easy to misunderstand. People assume it only measures what happened in the last patch run. Usually it does not.
| Input | What it changes | Why it moves |
|---|---|---|
| Installed updates | The numerator | Changes after installs, rollback, or incomplete reboot state clears |
| Available updates | The denominator | Changes after Patch Tuesday, supersedence, or new applicability |
| Approved updates | The denominator | Changes when policy scope, classifications, or approvals change |
| Scan freshness | The visible result | Changes when the reporting view is older than the endpoint state |
| If this changes | The percentage usually does this | What it often means |
|---|---|---|
| Installed updates increase | Goes up | The endpoint closed part of the gap against the current baseline. |
| Available or approved updates increase | Goes down | The denominator grew, even if the endpoint did nothing wrong. |
| Scan data is stale | Looks frozen or misleading | The score may be describing an older device state. |
If you want the plain-English version of this topic, use what patch compliance means. If you want the side-by-side distinction between math and workflow state, use patch compliance vs patch status.
Why the Denominator Changes Constantly
New releases: Patch Tuesday adds new security and cumulative updates.
Superseded updates: older updates may stop mattering once a newer update replaces them.
Feature update applicability: a device may suddenly be counted against a feature update it was not eligible for before.
Optional and driver classifications: depending on approval rules, these may enter or leave the counted set.
Policy changes: if approvals or classifications change, the compliance formula changes even if the device did nothing.
This is why compliance math is a model of current state, not a clean historical record of patch success.
Why MSPs Misread the Formula
MSPs often see a score and assume it answers a practical question: "Did patching work?" But the formula is answering a different question: "How completely does this device match the platform's current patch model?"
Those are related, but not identical. One is operational. The other is representational. That difference is behind much of the confusion documented in patch report not accurate and patching working but shows not compliant.
Why Compliance Fluctuates After Patching
An MSP patches on Friday. Over the weekend, installs finish. On Tuesday, compliance falls because new updates are now in scope. The device did not become less patched in a practical sense. The model changed around it.
That is why compliance can drop after patching. It is not necessarily lying, but it is often being read incorrectly.
Why Compliance Is Misleading Without Context
RMMs abstract Windows Update data because raw Windows Update Agent state is messy and hard to operate from. That abstraction is reasonable, but it hides detail. It blurs the difference between install success, current applicability, stale scans, and approval logic.
As a result, compliance is not real-time truth and not a direct proxy for success or failure. It is best treated as a summary layer with known blind spots.
Caution: a changing compliance percentage does not automatically mean devices are getting worse. It may mean the denominator changed, the scan is stale, or reboot-completion state has not caught up yet.
A Real MSP Scenario
You patched a 75-device customer over the weekend. On Monday, 68 devices look compliant. On Tuesday, compliance drops even though no new failures appear.
The likely answer is not that seven devices uninstalled updates. The more likely answer is that new applicable or approved content entered the denominator.
This is a math problem first, not a patching-failure problem first.
What to Look at Instead
Use compliance for context, then validate patch health with:
- recent install success history
- pending reboot state
- endpoint uptime
- repeated install failures
- Windows Update service health
If you need the failure side of this topic, continue to devices with failed updates or report failed patches.
Common Mistakes
- Assuming the compliance percentage only reflects the last patch run.
- Ignoring newly applicable updates that entered scope after Patch Tuesday.
- Treating approval changes like endpoint failure.
- Reading stale scans as current truth.
- Using compliance math to explain root cause instead of using it as a summary model.
When Compliance Is Useful
Compliance is useful for trending, customer-level hygiene reporting, and spotting broad drift over time. It is also useful when approvals and scope are stable enough that the percentage tells a consistent story.
It becomes less useful when you ask it to explain root cause. That is where a truth-layer approach like PatchReporter helps: not by replacing the math, but by making the math easier to interpret against real endpoint evidence.
For the reporting and dashboard layer built on top of this math, continue to patch compliance reporting, patch compliance, or patch dashboard.