Reporting Patch Compliance Honestly

Patch compliance reports are read by clients, insurers and auditors. The standard version overstates protection in consistent ways.

The control described in “Reporting Patch Compliance Honestly” also consumes technician time before, during and after each maintenance window. A provider evaluating this working reference can record that operational effort by client and work item, making verification and follow-up visible without confusing a timesheet with proof that a patch succeeded.

For an independent operational benchmark, compare the local practice with CISA guidance on patches and updates; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

The four overstatements

Pending reboots counted as patched, which the previous note covers.

Machines with no agent excluded from the denominator, so the estate looks better than it is.

Third-party applications outside the catalogue not counted at all.

And excluded machines quietly dropped, rather than shown as excluded.

Each is defensible individually and together they produce a figure meaningfully higher than reality.

What an honest report shows

Total machines known, including those without agents.

Patched and rebooted.

Patched, pending reboot.

Excluded, with the count and the reasons.

Not reachable.

Third-party coverage separately.

Six lines rather than one percentage.

Why providers resist it

The honest number is lower, and the client comparison is against whatever their previous provider reported.

Which means the first honest report looks like a decline in service.

Explain the method when you change it, and show both figures for one cycle, which removes the objection almost entirely.

The insurance and audit dimension

Patch compliance increasingly appears in insurance questionnaires and audit scopes.

A figure that overstates protection is a problem for the client if it is relied on.

And it is a problem for you if the method is examined after an incident.

Being able to show the method is the protection, and it needs to exist before it is asked for.

Automating it

Monthly, generated rather than assembled by hand.

Same format every time, so the trend is visible.

And with the exclusions list attached, because exclusions that only appear in a footnote get forgotten by both parties.

What the client should do with it

Approve or challenge the exclusions.

Decide on the pending-reboot gap.

Fund what is needed for the unreachable machines.

Which means the report should end with decisions for them, not just numbers for you.

The internal use

Your own view should be the same figures per client, compared.

A client consistently below the others usually has a structural reason — reboot policy, unmanaged machines, an exclusion list nobody reviewed — and the comparison finds it.

What to check

Does your report count pending reboots as patched?

Are machines without agents in the denominator?

Are exclusions shown with reasons?

And does the report end with anything the client has to decide?

The point

Compliance reports overstate in four consistent ways.

An honest version is six lines rather than one percentage.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.