The catch-all patch-all policy is probably the culprit here. If there’s a month where there’s not a lot of patches coming out then it wouldn’t be a problem, but if there’s a bunch of out of band patches or third party patches that come out, then that policy is going to drag your numbers down until those patches have gone out on the patch-all policy. Does that fit with the data you are seeing? You can look at individual devices and see in the Associated Policies section of the Device Details page to see which specific policy is not up to date and keeping that machine considered “non compliant”.

Yep, makes sense. So we do two patch windows per month, with a catch-all patch-all to catch anything after that. So once any update is introduced, it nukes our entire org’s compliance percentages lol. Any thoughts on how to maybe architect around that differently?

How about temporarily inactivating the patch all policy, then running your report, and turning it back on? That way while the policy is off it won’t show any pending patches (unless they’re triggered by one of your other patching policies). I just tested that in my console and turning the policy off temporarily does change the compliance percentage.