Patch Compliance

Patch compliance is not a report. It's a real-time operational state and maintaining it requires more than running a deployment tool on a schedule and assuming the patches landed.

Most organizations can tell you their patch compliance rate at the end of last month. Far fewer can tell you their patch compliance rate right now across every managed system, for every patch that matters. That gap between reported compliance and actual compliance is where unpatched vulnerabilities persist and breaches begin.

1. Point-in-time compliance doesn't reflect continuous state

A compliance report produced after a patching cycle shows compliance at that moment. By the following week, systems have come online and gone offline, new software has been installed, patches have been rolled back for compatibility reasons, and agents have gone stale. The compliance number is accurate when it's produced and increasingly unreliable after that.

2. Coverage gaps are invisible until they cause problems

Systems that are offline during patching windows, endpoints with disconnected agents, cloud workloads outside agent coverage, and assets outside formal inventory all create patching blind spots. These systems appear in compliance reports as unknown — or don't appear at all — until an incident or external scan reveals them.

3. Compliance requirements vary by system class

Regulatory frameworks such as PCI DSS, HIPAA, CIS Controls often specify patching SLAs that differ by vulnerability severity, system type, and network exposure. A flat compliance metric that doesn't distinguish between system classes cannot demonstrate that the right systems were patched on the required timeline.

4. Third-party software is frequently excluded

Many patching programs focus on OS-level patches and miss third-party applications that are frequent exploit targets. A system with current OS patches but outdated third-party software is not fully compliant regardless of what the OS patch report shows.

Continuous, not periodic, compliance measurement

Compliance state is measured continuously not at the end of a patching cycle. Every change in patch state — new deployment, patch removal, agent disconnection, new asset added — is reflected in the compliance view immediately.

Full software scope

Compliance measurement covers:

• Operating system patches across all managed OS versions

• Third-party application patches for installed software

• Firmware updates for network and endpoint hardware

• Cloud workload and container base image patch state

SLA-tiered tracking

Patches are tracked against defined SLA tiers — based on severity, asset criticality, and regulatory requirements. Compliance is measured not just as 'patched or not' but as 'patched within the required timeframe for the required system class.'

Exception management and evidence

Legitimate exceptions — compatibility issues, operational constraints, formally accepted risks — are documented, tracked against review timelines, and reported separately from unknown gaps. Compliance evidence distinguishes between 'exception accepted' and 'unknown status.'

Audit-ready evidence

Compliance evidence is generated continuously and available for audit on demand — not assembled manually from patching system exports before each review.

• Continuous compliance monitoring: Patch state is tracked continuously across all managed assets — with compliance metrics that reflect current state rather than last-cycle results.
• Full software scope: OS patches, third-party application updates, and cloud workload patch state are all tracked in the same compliance model — eliminating the third-party blind spot that plagues many programs.
• SLA-tiered compliance tracking: Patch SLAs are defined by severity tier and asset class. Compliance is measured against those SLAs, so regulatory and policy requirements can be demonstrated with specificity.
• Coverage gap visibility: Assets with lapsed agent coverage, systems outside patching scope, and cloud resources without assessment data are surfaced explicitly — not hidden in unknown status categories.
• Exception management: Formally accepted exceptions are tracked separately from compliance gaps, with compensating controls documented and review timelines enforced.
• Audit-ready reporting: Compliance evidence is continuously generated and available on demand, supporting regulatory audits without requiring manual data assembly.

• Overall patch compliance rate
• Compliance rate by severity tier
• Compliance rate by asset class
• SLA compliance rate
• Third-party application compliance rate separately from OS compliance
• Coverage gap rate
• Exception volume, age, and review compliance
• Compliance trend over rolling 90-day period