Simple IT Distribution LTD

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:

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:

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.

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.

1. Measure: Evaluate devices against current patch policy

2. Segment: Isolate noncompliant and unknown endpoints by risk, patch, OS, group, or age

3. Prioritize: Start with exploited vulnerabilities, critical systems, breached SLAs, and large exposure groups

4. Remediate: Deploy the update, fix the blocker, reboot where necessary, or document an approved exception

5. 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.