TL;DR: Patch compliance measures whether your endpoints meet your organization's defined patch policy. A meaningful compliance report should separate compliant, noncompliant, and unknown devices while clearly defining the scope, denominator, and freshness window behind the percentage. Without that context, even a strong-looking compliance rate can hide stale devices, missing data, or unaddressed patching gaps.
Patch compliance measures whether in-scope endpoints and software meet your organization's patching policy at a specific point in time. Effective reporting goes beyond a single percentage by tracking coverage, missing patches, remediation timelines, deployment failures, exceptions, and data freshness, giving you enough detail to identify and fix what's actually broken.
The 2026 Verizon DBIR reports that vulnerability exploitation now accounts for 31% of breaches, surpassing stolen credentials as the leading initial access vector. Knowing patches were deployed isn't enough. You need to know whether the right patches reached the right devices in time.
What is patch compliance?
Patch compliance measures your environment against a defined patch policy, not against some universal standard floating in the ether.
Your policy determines what's in scope, which updates are required, when they're due, what's excluded, and how often status gets evaluated. That makes compliance contextual by definition. An endpoint can be fully current under one organization's policy and two weeks overdue under another's SLA.
You can measure compliance by device, by patch, by software instance, by business unit, or by whatever segmentation makes sense for your environment. NIST defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches. That verification step, confirming the patch actually landed, is where reporting earns its keep.
Before going further, some terms worth keeping straight:
Term | What it means |
|---|---|
Patch compliance | Whether systems meet the defined patch policy |
Patch coverage | Whether in-scope systems are actually managed and evaluated |
Patch deployment success | Whether attempted deployments completed successfully |
Vulnerability remediation | Whether a security weakness was eliminated or mitigated |
These aren't synonyms. Blurring them together is how dashboards lie to you.
How do you calculate patch compliance?
There's no universally correct patch compliance percentage until you define the numerator, denominator, scope, and time window. Reporting is misleading when it presents a percentage without defining those variables. Several common reporting practices can make compliance results look stronger than they are.
Device-level vs. patch-level compliance
Here's why two teams can look at the same environment and report different numbers:
You manage 100 endpoints, each with 10 applicable patches. Ten devices are missing one patch each. By patch instance, you installed 990 of 1,000 applicable patches, so patch-level compliance is 99%. But only 90 of 100 devices have every required patch, making device-level compliance 90%.
Same fleet. Same missing patches. Very different headline number.
The three-state model
Every in-scope endpoint should land in one of three buckets:
Compliant: Current data confirms that the endpoint meets the defined patch policy.
Noncompliant: Current data confirms that the endpoint does not meet the policy. For example, a required patch remains missing after its deadline.
Unknown: There isn't enough current data to determine compliance because the endpoint has exceeded the freshness window, an evaluation failed, or another visibility gap exists.
Unknown differs from compliant. Treating it as compliant is how disappearing laptops magically improve your dashboard.
Useful formulas
No single percentage tells the whole story. Reporting coverage alongside compliance prevents missing or stale devices from silently disappearing from the calculation. These are useful conventions, not universal standards:
Coverage rate: Endpoints evaluated within the freshness window ÷ all in-scope endpoints × 100
Evaluated compliance rate: Compliant endpoints ÷ evaluated endpoints × 100
Demonstrated fleet compliance: Compliant endpoints ÷ all in-scope endpoints × 100
Evaluated compliance describes the devices you have current information about. Demonstrated fleet compliance uses the entire in-scope fleet as its denominator, preventing the reported rate from improving simply because devices go dark.
How CIS Controls measures patching
CIS Controls v8.1 provides one formal assessment model for patch management. For operating systems and applications, the Control 7 assessment specification separately calculates update effectiveness, automation coverage, and what CIS calls “scan compliance,” which measures whether automated patch management software is configured to run every 30 days or less.
Update effectiveness can include both up-to-date installations and outdated installations covered by documented exceptions. CIS’s model isn’t the only valid way to measure patch compliance, but it illustrates why every reported percentage needs a clearly defined scope, status model, and denominator.
What should a patch compliance report include?
A useful patch compliance report shows scope, current status, overdue patches, risk, deployment outcomes, exceptions, and data freshness at the device level, with enough context to identify exactly what needs remediation.
Core fields worth including:
Endpoint name or unique identifier
OS and version
Last check-in timestamp
Last successful patch evaluation
Applicable, installed, and missing patches
Patch severity or risk context
Release date and policy deadline
Days overdue
Deployment status and failure details
Reboot-pending status
Exception status, owner, and expiration date
Business unit, site, or device group
This is about operational visibility rather than audit evidence. If you need the framework-mapping and evidence-chain angle, that's covered in PDQ's guide to vulnerability management for IT audits.
Which patch compliance metrics actually matter?
Not all metrics deserve dashboard real estate. Here's what actually drives action:
Metric | What it answers | Why it matters |
|---|---|---|
Patch compliance rate | How much of the evaluated environment meets policy? | Tracks policy compliance; pair with reporting coverage to identify blind spots |
Endpoint reporting coverage | How much do we have current information on? | Guards against artificially high compliance |
Patch SLA adherence | Are we hitting deadlines by risk class? | Shows whether patches meet policy deadlines; report by severity to reveal delays affecting higher-risk vulnerabilities |
Time to patch (median) | How long from release to verified install? | Measures patching speed; use a consistent starting event to make comparisons meaningful |
Overdue patch count by age bucket | Where's the patch debt concentrating? | Highlights overdue patches and how long they’ve remained unresolved, helping teams prioritize remediation |
Deployment success rate | Are jobs completing? | Helps teams assess deployment reliability and identify installation problems that delay patching |
Patch failure rate by pattern | What's breaking and why? | Turns reporting into troubleshooting |
Reboot-pending endpoints | How many devices still require a restart to complete installation? | Identifies endpoints that need a restart to finish applying patches, helping teams and complete remediation |
Exception rate and age | Deliberate risk acceptance or just debt? | Shows how much patching is deferred and for how long, helping teams reassess exceptions |
KEV exposure | Are exploited vulnerabilities sitting unpatched? | CISA explicitly recommends using KEV for prioritization |
According to PDQ’s 2026 State of Sysadmin report, 51% of sysadmins say timely patch implementation takes up too much time. Reporting should reduce that burden by showing teams which devices and updates require attention first.
How should you set patch compliance targets and SLAs?
Patch compliance targets should reflect vulnerability risk, exploit activity, asset criticality, and operational constraints.
Define separate timelines for:
Emergency or actively exploited vulnerabilities
Critical security patches
High-risk security patches
Standard security updates
Nonsecurity updates
Business-critical systems requiring additional testing
CIS calls for monthly or more frequent OS and application patching in Control 7. PCI DSS Requirement 6.3.3 specifies patches for critical vulnerabilities within one month of release. But SOC 2, HIPAA, NIST CSF, and FedRAMP don't all impose the same timeline. Never collapse them into one generic "compliance deadline."
If you need framework-specific guidance, PDQ's cybersecurity compliance overview covers the foundational context.
How can patch compliance reports be misleading?
Patch compliance reports can be misleading when they exclude stale or offline devices, confuse deployment success with actual patch status, hide exceptions, ignore reporting freshness, or compare percentages across different scopes. A high compliance rate only means something when you know what was measured, when it was measured, and which policy defined compliance.
Excluding offline or stale endpoints. If a device disappears from the denominator because it hasn't checked in, your percentage improves while actual visibility gets worse. Show unknown separately.
Reporting deployment success instead of patch status. "Successfully sent 9,900 jobs" doesn't prove 9,900 endpoints are compliant.
Counting every patch equally. One missed low-risk update shouldn't obscure an actively exploited vulnerability on a domain controller. Segment by risk.
Ignoring the reporting timestamp. Patch state changes continuously.
Hiding exceptions. Approved exceptions should stay visible and identifiable. Otherwise "compliance" becomes moving things out of the denominator.
Treating every pending-reboot device as fully remediated. When an update requires a restart to finish applying, report that state separately until installation and remediation can be verified.
Comparing different scopes. A 96% across workstations isn't comparable to 96% across workstations plus servers plus third-party apps.
Every headline compliance percentage should answer: % of what, measured when, against which policy?
How often should you review patch compliance?
Patch compliance should be reviewed at different cadences depending on the audience and purpose. Sysadmins may need daily visibility into failures and stale endpoints, while IT leaders typically need weekly or monthly reporting on overdue patches, SLA risk, and compliance trends.
Example cadence | Primary audience | Purpose |
|---|---|---|
Continuous or daily | Sysadmins | Detect failures, stale endpoints, critical gaps |
Weekly | IT ops and security | Review overdue patches, recurring failures, SLA risk |
Monthly | IT leadership | Check trend compliance, patch debt, risk concentrations |
Audit cycle | Compliance and auditors | Look at historical evidence and control documentation |
How do you turn patch compliance reporting into remediation?
Turn patch compliance reporting into remediation by using the report to identify gaps, prioritize risk, deploy fixes, and verify that affected endpoints return to a compliant state. The report is not the finish line. It is the feedback loop.
Measure: Evaluate devices against current patch policy
Segment: Isolate noncompliant and unknown endpoints by risk, patch, OS, group, or age
Prioritize: Start with exploited vulnerabilities, critical systems, breached SLAs, and large exposure groups
Remediate: Deploy the update, fix the blocker, reboot where necessary, or document an approved exception
Verify: Reevaluate the endpoint and confirm its state changed
NIST's enterprise patch management guidance treats verification as part of the lifecycle rather than stopping at installation. If you're not closing the loop, you're just generating paperwork.
What should patch management reporting software provide?
Patch management reporting software should provide current patch status, device coverage, deployment results, data freshness, vulnerability context, and enough endpoint detail to move directly from identifying a gap to fixing it.
Current device inventory with Windows and third-party visibility
Missing and installed update status at the device level
Deployment success and failure data
Pending reboot visibility
Filtering by groups and attributes
Vulnerability context where available
Data freshness and last-seen timestamps
Custom and scheduled reporting
Exportable data and historical trends
Direct remediation from identified gaps
Support for remote endpoints
The question isn't which dashboard has the prettiest charts. It's whether you can go from "this is broken" to "this is fixed" without switching tools or exporting to a spreadsheet.
How does PDQ help with patch compliance reporting?
PDQ helps with patch compliance reporting by connecting device inventory, patch status, vulnerability data, deployment results, and remediation workflows in one place.
You can build reports from device inventory data, filter by software or Windows update status, schedule recurring reports, and export results. Vulnerability reports can also surface findings by severity and reporting window, helping you identify where patch risk is concentrated.
Windows update statuses such as not installed, in progress, pending reboot, failed, and installed make it easier to distinguish devices that are fully patched from those that still need attention. Dynamic groups can then organize affected devices by criteria such as update state so you can target remediation more precisely.
From there, PDQ connects reporting to action. Real-time endpoint visibility helps surface device health, deployment failures, and vulnerabilities, while automated patch management helps close the loop by moving from identified gaps to remediation and verification.
Manage Windows & macOS devices from anywhere
With PDQ Connect, get real-time visibility into remote and local devices, deploy software, remediate vulnerabilities, automate routine maintenance, and remotely troubleshoot endpoints from one easy-to-use platform.
Patch compliance reporting FAQs
What is a good patch compliance percentage?
There's no universal percentage that proves good patch management. Organizations should define targets based on scope, risk, SLAs, and applicable requirements, then separately report unknown or unevaluated devices. A 98% compliance rate means nothing if 15% of your fleet hasn't checked in this month.
What is the difference between patch compliance and vulnerability remediation?
Patch compliance measures whether systems meet your organization's patch policy. Vulnerability remediation focuses on resolving or mitigating vulnerabilities through patching, configuration changes, compensating controls, software removal, or other fixes. Patching is one remediation method, so a system can be patch-compliant and still have unresolved vulnerabilities caused by misconfigurations, unsupported software, or other issues.
Should exceptions count as patch compliant?
Exceptions may count as policy-compliant if your policy explicitly allows approved deviations. But they should never be labeled "patched." Always report them separately so you can distinguish between deliberate risk acceptance and plain old patch debt. An exception without an owner and expiration date is just technical debt with a better name.
How do you report devices that are offline during patching?
Use the device’s most recent verified status while its data remains within your defined freshness window. If that status shows a required patch is missing, report the device as noncompliant. Once its data becomes too stale to determine whether it meets policy, report it as unknown. Keep offline and stale devices in coverage metrics rather than removing them from the denominator.
