How to calculate patch compliance without hiding unmanaged devices

Calculate device-level patch compliance by dividing the number of in-scope devices with current evidence that they meet the defined patch baseline by the total number of in-scope devices. Multiply by 100. Keep devices with missing or stale evidence visible in the denominator and report them as unknown, rather than silently excluding them.

The difficult part is agreeing which devices belong in that calculation.

A patching console can accurately describe the machines reporting to it while leaving a security leader with an incomplete view of the estate. An agent that stopped checking in, an acquisition still being onboarded, or a cloud account outside the reporting boundary can change what the percentage means.

This article proposes a practical reporting method: define the population independently of patch status, separate unknown from known noncompliance, and explain changes in the population alongside changes in the score. It is an operational measurement approach, not a universal regulatory formula.

What does patch compliance measure?

Patch compliance measures whether the assessed systems meet a specified patch requirement at a particular time. The requirement needs a baseline: which updates apply, when they become due, and what evidence establishes their status.

A percentage without that definition is hard to interpret. “Current” could mean all approved updates, all critical updates past their deadline, or one selected monthly release.

Write the measurement rule before calculating the result. Identify the software scope, applicable deadlines, reporting cutoff, and maximum acceptable evidence age. If operating systems and third-party applications have different rules, show that difference.

NIST describes enterprise patch management as a process that includes identifying, prioritizing, acquiring, installing, and verifying updates. Installation and verification belong in the workflow; a count of deployment attempts does not by itself establish completion. See NIST SP 800-40 Rev. 4.

Patch compliance also has limits. Meeting a patch baseline does not establish that a device has no exploitable vulnerabilities or that the organization meets every applicable compliance requirement.

Choose the unit before choosing the formula

Device compliance and patch-installation compliance answer different questions.

A device-level measure asks how many devices meet every applicable requirement in the stated baseline. A patch-instance measure asks how many required update installations have been completed across those devices.

Consider a hypothetical estate of ten laptops. Each requires ten updates. Nine laptops receive every update; the tenth receives none. The completed patch-instance rate and device compliance are both 90%.

Now distribute the same ten missing updates across all ten laptops, one missing update per laptop. Patch-instance completion remains 90%. Device compliance is now 0% under a rule requiring every applicable update.

Neither calculation is inherently wrong. They describe different conditions. Label the unit and avoid switching between them in a trend chart.

For fleet reporting, the approach below uses devices. Keep patch-instance counts as supporting operational detail.

Build the denominator outside the patch-status filter

Start with the reconciled inventory of devices subject to the chosen patch requirement. Do not define the population as “devices that returned a successful scan.”

CIS Control 1 addresses inventory and control of enterprise assets, including the identification of unauthorized and unmanaged assets. That broader inventory purpose supports checking the reporting boundary rather than assuming the patching tool contains the whole estate. See CIS Control 1.

Reconcile the sources appropriate to your environment. These might include endpoint management, cloud inventories, virtualization platforms, procurement records, and network discovery. They will not necessarily agree.

Use stable identifiers to resolve duplicates. Record why an asset was included or excluded, who owns that decision, and when its lifecycle status was last checked.

An unmanaged device discovered in a relevant business unit should trigger a scope decision. If it belongs in the defined population, retain it even when its patch status is unknown. If it genuinely falls outside the requirement, preserve the reason.

The denominator is still the known, reconciled population. No formula can prove that undiscovered devices do not exist. Report inventory limitations alongside the score.

Report verified compliance and evidence coverage together

For this proposed method, divide the population into three mutually exclusive states:

Use the same reporting cutoff and population for both measures:

Verified device compliance = verified compliant devices ÷ all in-scope devices × 100.

Assessment coverage = devices with a current, determinate assessment ÷ all in-scope devices × 100.

A determinate assessment can be compliant or noncompliant. Coverage therefore measures whether you have an answer, not whether that answer is favorable.

Suppose a hypothetical inventory contains 1,000 in-scope devices. Of these, 855 are verified compliant, 45 are known noncompliant, and 100 are unknown.

Reporting only the 900 assessed devices produces 95% compliance among assessed devices. Across the defined estate, verified compliance is 85.5%, assessment coverage is 90%, and the unknown share is 10%.

The 95% figure can remain as a labeled operational measure. It should not stand alone as the estate-wide result.

This structure also avoids calling all 100 unknown devices unpatched. Their condition needs investigation. The report can be conservative about what is verified without inventing their technical state.

Decide when evidence expires

A device's last known status is not automatically its current status. Define freshness rules that match the reporting purpose and operating environment.

AWS makes this limitation explicit for its own Patch Manager: compliance reports are point-in-time snapshots with a capture time. Its documentation also explains that subsequent scans can overwrite previous compliance data. See AWS patch compliance reporting.

Retain the assessment timestamp and baseline version used for each result. When evidence becomes too old under your reporting rule, move the device into unknown unless another accepted source supplies a current assessment.

Do not choose a universal freshness interval merely because it makes the dashboard look tidy. A frequently connected workstation and an intermittently connected field device may need different collection arrangements. Document those arrangements and keep the reporting labels explicit.

For the evidence needed to establish that a fix has taken effect, use the patch verification checklist. That is a separate question from whether the device was counted in the report.

Handle exceptions without changing the technical result

An approved delay should remain visible as a decision about treatment. Under a technical patch-baseline measure, approval alone does not establish that the required update is installed.

Keep exception status as an additional field. A device can be known noncompliant with an approved exception, or unknown with a pending investigation.

If your organization also reports policy compliance that includes approved exceptions, label that measure separately and explain its rules. Do not combine it with verified patch compliance under an ambiguous heading.

Remediation can take other forms. A valid configuration correction, component removal, or protective control may address a particular exposure. Record what was done and what the evidence supports. If the metric specifically measures patch installation, do not relabel an alternative treatment as an installed patch.

The reporting model should let leaders see those distinctions without forcing every resolution into the same category.

Explain why the percentage moved

A higher percentage does not necessarily mean more devices were patched. The denominator may have shrunk.

Suppose twenty noncompliant devices disappear from a feed. Removing them from the report could improve the score without any change to their condition. Keep them unresolved until their ownership, status, or retirement is established.

Conversely, discovering an unmanaged group can lower the score while improving the organization's understanding of exposure. The accompanying explanation matters.

For each reporting period, show the opening population, additions, verified removals, and closing population. Separate status changes caused by remediation from those caused by new evidence, expired evidence, or baseline changes.

Keep a fixed-group comparison when useful: how did devices present in both periods perform? Show it alongside the current-estate result, not as a replacement for newly discovered devices.

For broader context, see shifting metrics toward remediation effectiveness. Here, the immediate goal is narrower: make the population and evidence behind one percentage inspectable.

Frequently asked questions

Should offline devices count in patch compliance?

Keep an offline device in the denominator if it remains in scope. Its status depends on whether acceptable current evidence is available. When evidence expires, classify it as unknown rather than removing it or assuming it is unpatched.

Is an unmanaged device automatically noncompliant?

Not necessarily. Unmanaged describes its relationship to a management system; it does not establish its installed updates. If it is in scope and lacks sufficient evidence, report its patch status as unknown and assign the work needed to assess it.

What is a good patch compliance percentage?

A useful target depends on the defined baseline, deadlines, population, and organizational requirements. This article does not propose a universal benchmark. Evaluate the target alongside assessment coverage and the significance of unresolved devices, rather than treating a high aggregate score as proof of acceptable risk.

Can approved exceptions be excluded from the denominator?

In the proposed technical measure, retain in-scope devices and show exceptions separately. If a policy defines a different population or measure, disclose the exclusions and their effect. Otherwise, a reader cannot distinguish completed patching from accepted delay.

Recalculate one report before the next review

Choose one device group and one reporting cutoff. Reconcile its inventory against the patch report, then classify every in-scope device as verified compliant, known noncompliant, or unknown.

Present verified compliance and assessment coverage together. Attach the list of unexplained omissions, stale results, and disputed exclusions, with an owner for each.

The next review can then address concrete work: deploy a missing fix, restore an assessment, confirm retirement, or resolve ownership. The percentage becomes useful when the team can explain every device behind it.