Ensuring patch compliance across all endpoints

Patch compliance is the percentage of devices in an environment that have been successfully patched or otherwise remediated so they are no longer exposed to known vulnerabilities. A system counts as compliant when it has the patches your policy requires for its role and risk level; it counts as non-compliant when it is missing one or more of them.

The figure is always relative to a standard. You define what compliant means, usually by severity, so that a machine missing a critical patch is flagged while one missing a cosmetic update may not be. Patching compliance, then, is less about chasing 100% and more about holding the fleet at a defined, defensible level and proving it with data.

These three terms get used interchangeably, and they are not the same thing. The distinction matters when you are scoping a project or answering an auditor.

Put simply: patch management is the doing, patch compliance is the proof, and security compliance is the wider standard that proof feeds into. A tool can automate the management and generate the compliance evidence, but only your policy defines what compliant means. For teams running mixed fleets, cross platform patch management keeps that definition consistent across every operating system.

Patch compliance is maintained as a continuous cycle, not a one-time cleanup. Each stage below feeds the next.

Define a compliance policy

Set the standard first. Decide which patch severities make a system non-compliant and what your target rate is, so compliant is a defined threshold rather than a feeling. Without a baseline, the percentage means nothing.

Scan and assess continuously

Scan endpoints on a schedule to detect missing patches and measure each system against the policy. Continuous assessment is what keeps the compliance figure current instead of a snapshot that is stale by the next release cycle.

Remediate non-compliant endpoints

Deploy the required patches to systems that fall below the standard, in controlled waves during maintenance windows. Automated remediation is what closes the gap between detection and a system actually being compliant.

Verify and report

Rescan remediated systems to confirm the patch landed, then report compliance by system, severity, and SLA. Verification separates we deployed it from it is compliant, and reporting turns the state into evidence.

A compliance program you cannot quantify is not a program. These are the measures that make patching compliance visible and defensible.

Patch compliance rate

The headline number: the percentage of endpoints compliant with your policy at a point in time. Measured as compliant devices divided by total managed devices. Track it as a trend, not a single reading, since it shifts with every patch release.

Compliance by severity

A single blended rate hides risk. Break it out so you can see compliance against critical and important patches separately from low-severity ones, because a 95% overall rate still leaves you exposed if the missing 5% are all critical.

SLA adherence

Measure the share of patches deployed within the timeframe your policy sets for their severity. This is the metric auditors care about most, since it shows not just whether you patched, but whether you patched in time.

Remediation and failure metrics

Track mean time to patch, the count of repeatedly failing systems, and the number of endpoints that missed a cycle. These reveal where compliance breaks down and which machines need attention before they become the gap an attacker finds.

Reports are where patch compliance stops being an internal claim and becomes evidence. Patch Manager Plus surfaces non-compliant systems through predefined and dynamic reports, and sends automated email alerts for new updates, missing patches, and failed deployments, so administrators see which systems fall out of compliance without hunting for them.

Two reports do the core work of demonstrating compliance. The Vulnerable Systems Report separates healthy from vulnerable systems, showing how many endpoints are non-compliant, meaning not fully patched against critical updates. The Vulnerable Patches Report lists every missing patch across the network, so teams know exactly what to deploy to reach a fully patched status.

Around those, a complete patch compliance report set adds the System Health Report for an at-a-glance view of fleet status, and audit-ready reports that map patch status to the frameworks you answer to. Reports can be scheduled and emailed to stakeholders, and drilled into by system, severity, or SLA.

Even well-run teams lose compliance points to a predictable set of problems:

• Incomplete visibility. You cannot measure compliance for endpoints you do not know exist. Remote devices, shadow IT, and unmanaged machines create blind spots that quietly drag the real rate below the reported one.
• Remote and roaming endpoints. Devices that rarely touch the corporate network miss patch cycles, and without off-network patching they stay non-compliant while looking fine in a stale report.
• Third-party application sprawl. OS compliance is the easy part. The browsers, runtimes, and tools that make up most of the attack surface are harder to track and easy to leave out of the compliance picture.
• Failed and partial deployments. A patch that reports deployed but did not fully apply leaves a system non-compliant without anyone noticing, unless the process rescans to verify.
• Chasing 100%. Treating anything short of a perfect score as failure burns effort on low-risk updates while critical gaps wait. A severity-weighted target is more honest and more secure.

Most security and privacy frameworks treat timely patching as a named requirement, though they specify it differently.

• PCI DSS requires patching known vulnerabilities within defined timeframes, with the tightest windows for critical and high-severity issues.
• HIPAA does not set a fixed patch timeline but requires patching as part of the reasonable and appropriate safeguards protecting electronic health information.
• NIST guidance, including SP 800-40 on enterprise patch management and the Cybersecurity Framework, sets out patching as a core control.
• ISO 27001 requires a managed vulnerability and patch process with evidence that it is followed, rather than a specific deadline.
• SOX and GDPR do not name patching directly but impose data-integrity and data-protection duties that a lapsed patch process can breach.

Practical moves that raise and hold the compliance rate:

• Set a severity-weighted target, not a flat 100%. Define compliance against critical and important patches first, so effort follows risk.
• Automate the cycle end to end. Scanning, remediation, and reporting should run without manual triggers.
• Patch off-network endpoints directly. Use agent-based, VPN-free patching so remote devices stay compliant instead of drifting.
• Cover third-party applications, not just the OS.
• Verify, do not assume. Rescan after deployment so deployed and compliant are confirmed as the same thing.
• Report continuously. Keep audit-ready reports current so compliance evidence exists before an auditor asks.

Patch Manager Plus runs the full compliance cycle, from defining the standard to producing the evidence, as an automated loop across on-site and remote endpoints.

System Health Policy

Patch Manager Plus uses a compliance policy called the System Health Policy as the baseline for measuring compliance. It classifies systems by the severity of their missing patches into three states: Healthy systems have up-to-date patches, Vulnerable systems are missing Moderate or Low severity patches, and Highly Vulnerable systems are missing Critical or Important ones. The policy is customizable, so you can define which severities and how many missing patches move a system between states.

Patch automation

Automation is what keeps a fleet compliant rather than periodically cleaned up. Patch Manager Plus scans systems for missing patches, creates automated deployment tasks for non-compliant machines, deploys the right fixes, and confirms whether the environment is compliant, all without manual intervention.

Reporting and remote coverage

Compliance evidence is generated continuously through the reports covered above, and remediation extends to remote and roaming endpoints over the internet without a VPN, so machines off the corporate network stay compliant and counted. The result is a defensible compliance figure backed by audit-ready records, across Windows, macOS, Linux, and 1,100+ third-party applications.