Minimum version versus actual patch level
Compare the minimum version a policy requires against the actual patch level installed on the device population, not just its build number.
Independent IT security review
A compliant device on paper can still run months behind on patches.
Compliance policy checks a setting. It does not by itself prove a device installed this month’s security updates or that anyone is watching the alerts. This review checks patch cadence and monitoring coverage as their own question.
- Before any access
- Written question and scope
- Agreed evidence method
- No automatic tenant changes
Separate ‘compliant’ from ‘patched.’
A device compliance policy typically checks a minimum operating system version or a boolean update setting. Neither one proves that this month’s specific security updates actually installed.
Update rings and deferral in practice
Check how long deferral and update-ring settings actually delay installation, since a cautious deferral policy can quietly become a permanent gap.
Devices excluded from policy but not from risk
Identify devices that sit outside the compliance policy’s scope entirely-kiosk machines, older hardware, contractor equipment-while still connecting to company resources.
Confirm someone is watching update rollout, not just deploying it.
Windows Update for Business rings, third-party patch tools, and vulnerability data are only useful if a human reviews failures and stalled devices instead of trusting a dashboard nobody opens.
Install-success evidence versus ring assignment
Confirm actual install-success rates are reviewed, not just that devices are assigned to an update ring.
Third-party application patching
Check whether browsers, PDF readers, and common line-of-business applications are patched by the same process as the operating system, or missed entirely.
Failure and stalled-update visibility
Confirm a specific person reviews failed or stalled updates on a cadence, rather than assuming silence means success.
Check whether monitoring coverage matches the device population, not the licence count.
A monitoring or RMM tool licensed for a device count is not the same as a tool actually installed and reporting on every one of those devices-the same gap pattern this site already checks for Defender onboarding.
Agent deployment versus licence count
Compare the number of licensed monitoring agents against devices actually reporting, since the gap tends to grow quietly after onboarding.
Alert routing and ownership
Confirm who actually reviews an alert about a stalled agent or a failed patch job, and how quickly.
Server and non-Windows coverage
Check that servers, macOS devices, and network appliances are not silently missed by a monitoring process built primarily around Windows workstations.
Decide what a coverage gap actually changes.
A finding here can mean a patch-policy fix, a monitoring configuration change, or a decision that a device class needs a different lifecycle plan entirely.
Policy fix versus monitoring fix
Distinguish a change to update rings and deferral settings from a separate fix to agent deployment or alert ownership.
Retire versus remediate
For hardware that cannot take current patches, weigh replacement against continued exception with a documented compensating control.
Recheck cadence tied to release cycles
Set a recheck aligned to vendor patch cycles so coverage is verified on a rhythm that matches how often new updates actually ship.
Next step
Define the review before sharing evidence.
Start with the trigger, decision, and known boundaries. Do not send passwords, recovery codes, or tenant exports.