Endpoint operations research
Patch Compliance Reporting and the Device You Forgot
Why patch compliance percentages overstate coverage, how missing devices and stale agents distort the denominator, and how to report a range that survives audit.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
A patch compliance figure is a ratio, and most of the risk lives in the denominator. Devices that never check in, agents that stopped reporting, and machines excluded from the policy can all disappear from the calculation while remaining on the network.
This paper describes a reporting method that keeps the missing devices visible and separates compliance from coverage.
Compliance is a ratio with a hidden base
The numerator is usually devices with the required patch installed. The denominator is whatever the reporting tool considers in scope. If the tool defines scope by successful check-in, the devices most likely to be unpatched are excluded by construction.
Coverage is a separate measure: the share of known devices that report at all. A high compliance rate on low coverage is not reassurance.
Report both numbers side by side. A single percentage invites the reader to assume full coverage.
Build the denominator from the asset register
Start with the managed device register, then reconcile it against the patch tool, the identity provider, and the network. Each source contributes devices the others miss.
Classify each device as reporting and compliant, reporting and non-compliant, known but not reporting, or unknown. The last two are the interesting groups.
Freeze the comparison date. A register exported on Friday and a scan from Monday will disagree for uninteresting reasons.
Stale agents and missing devices
An agent that has not checked in for thirty days is not evidence of compliance. It is evidence of absence. Treat it as unknown until the device is confirmed.
Look for devices that exist in the identity provider but never appear in the patch tool. Those are often personally owned machines, loaners, or virtual machines created outside the standard image.
Record the reason for each missing device. "Unknown" is acceptable in a first report; it is not acceptable as a permanent state.
Grace periods and approved exceptions
A patch released yesterday should not appear as a failure today. Define a grace period per severity and report devices inside it separately from devices that missed the deadline.
Approved exceptions need an owner, a reason, and an end date. Exceptions without an end date become permanent exclusions and quietly shrink the denominator.
Show exceptions in the report rather than removing them. A reader can then see how much of the result depends on approved risk acceptance.
Weight by exposure where the data allows
A count treats a kiosk and an internet-facing server as equal. Where the register records exposure, report the internet-facing group separately.
Do not invent a weighting scheme without data. A simple split by exposure and device type is more defensible than a composite score.
Keep the raw counts available so a reader can recompute the result under a different weighting.
Reporting that survives audit
Publish the definitions, the extraction queries, the coverage rate, the exception list, and the count of unknown devices. Attach the evidence rather than summarizing it away.
State the remediation target and the actual result for the period. If the target was missed, say so and name the constraint.
Store the report with the source exports so the next auditor can reproduce it without rebuilding the environment.
Limitations
The method measures reported state, not exploitability. A compliant device can still be vulnerable to an unpatched application.
Asset registers are imperfect. The unknown group is a measure of that imperfection as much as of patching.
Organizations with diverse device ownership should expect a wider range and should not compare percentages across business units without checking definitions.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the patch compliance reporting and the device you forgot data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to patch compliance reporting and the device you forgot, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Authoritative sources | 6 | Declared source register |
| Device states tracked | 4 | Proposed schema |
| Provider performance claims | 0 | Scope boundary |
Sources
- Cybersecurity Framework 2.0Used for the governance and continuous-improvement framing of the measurement routines described here.
- Cross-Sector Cybersecurity Performance GoalsUsed as a public reference for baseline security practices that small teams can measure without a bespoke framework.
- Security and Privacy Controls for Information Systems, SP 800-53 Rev. 5Used for control-language on access, audit, and configuration management. It does not prescribe the local metrics in this paper.
- Standards for Internal Control in the Federal Government (Green Book)Used for the separation of design, operation, and evidence in the review protocols.
- Guide for Security-Focused Configuration Management, SP 800-128Used for configuration inventory and baseline control concepts.
- Guide for Enterprise Patch Management Planning, SP 800-40 Rev. 4Used for patch management lifecycle and prioritization concepts.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review