Patch compliance reporting without a security team

Question and scope

This study asks what proportion of in-scope devices have the required patches installed and verified during a declared month. The unit is one device and one patch requirement, and the population is the asset list agreed before the study. The result describes coverage for that list, not the security of the whole business. Freeze the scope and the requirement set before extracting data. The scope note should say which business units, environments, and device types are included.

State whether the requirement is based on vendor severity, known exploitation, or an internal policy. Those definitions produce different denominators and should not be mixed in one percentage. Record the source and the date of the requirement list. A report that changes its definition every month cannot show a trend. If leadership wants a single number, publish the definition beside it so the number has a meaning.

Set the denominator from the inventory

Start with the asset inventory and remove devices that are retired, lost, or explicitly out of scope. Keep the removal reason and the approver beside each exclusion. Add devices that appear in the management tool but not in the inventory, because those are often the unmanaged ones. Reconcile the two lists before calculating anything. The reconciled list is the denominator for the report, and it should be saved with the date it was produced.

Count virtual machines, cloud workloads, and network devices if they fall within the policy. A laptop-only report can miss the server that exposes the most risk. Record the owner and the environment for each asset so the reader can see what is covered. The denominator should be reproducible by someone else from the same files. A device that cannot be attributed to an owner is still in scope and should be flagged.

Save the reconciled inventory as a dated snapshot before the report is written. The next month's count should start from the same list plus known additions and removals, not from a fresh export with unexplained differences. When a device changes owner, record the transfer rather than deleting the old row. That history explains why the denominator moved and prevents a coverage change from looking like a performance change.

Use more than one detection source

Use at least two sources when the device management tool is not authoritative. The endpoint agent, the vulnerability scanner, and the manual check each answer a different question. The agent may know that an update was installed, while the scanner knows whether the vulnerable service is still reachable. Record which source was used for each device. The report should name the sources so the reader can judge the coverage.

Treat a missing scan as unknown, not compliant. A device that has not checked in for thirty days is a gap in visibility even if its last result was green. Report the last check-in time beside the status. This single field prevents most of the false comfort in a patch dashboard. If a device is offline by design, label it as such rather than letting it disappear from the count.

Grade each device

Grade each device as verified, partial, or unsupported. Verified means the installation and the post-install check both appear in a source that reflects the device. Partial means the install is recorded but the service was not checked. Unsupported means the only evidence is an offered update or a user's assurance. The grade should be based on what the source shows, not on how likely the user thinks the update was applied.

Keep the grades visible in the report instead of collapsing them into a single pass rate. A high verified rate with a large unsupported group is a different situation from a lower rate with complete evidence. The grade tells the reader where to look next. It also protects the team from claiming more than the data shows. The report should make the unsupported group impossible to mistake for a pass.

Manage exceptions explicitly

An exception should name the device, the patch, the reason, the risk owner, and the review date. A vendor constraint is valid, but it still needs a compensating control and a plan. An exception with no end date becomes a permanent gap. Review all exceptions before publishing the monthly report. The reviewer should ask whether the constraint still exists, not only whether the device is still in service.

Separate a business-approved exception from a device that simply failed to update. The first is a decision, while the second is an operational problem that needs a fix. Mixing them hides the work required and makes the report look calmer than reality. Use different labels and different owners. The exception list should be short enough that leadership can read it in full.

Design the report

Show the denominator, the verified count, the unsupported count, and the exceptions in one table. Add the oldest overdue item and the business service it supports. Avoid a single headline percentage without the supporting counts. A reader should be able to trace every number back to a device list. The table should use the same column order every month so the eye can compare it quickly.

Write one sentence about the consequence of the largest gap and one sentence about the action being taken. Keep the tone factual, because a patch report is not a performance review. Send the same format every month so changes are visible. If a number cannot be produced, say so and explain the missing source. A short note about data quality is better than a polished number that nobody trusts.

Send the report to the person who can authorize the fix, not only to the team that collects the data. Add a short line for the decision requested, such as approving a maintenance window or funding a replacement. If no decision is needed, say that the report is for awareness and name the next review. A report that ends without an action tends to be archived without a response.

Use a second reader

Ask a second person to rebuild the count for a sample of devices from the source exports. Give them the definitions and the asset list, not the finished report. Compare the device-level results and investigate every difference. This catches both a formula error and a misunderstanding of the scope. The sample should include at least one device from each environment.

Record the reviewer, the date, and the corrections made. If the difference is large, rebuild the whole report rather than adjusting the total. The second read is especially important when the report goes to a client or an insurer. A reproducible count is the point of the exercise. The review note should be stored with the report so the next month starts from a known baseline.

Limits and next use

The report covers the devices and requirements in scope, using the sources that were available. It does not prove that an unpatched device was exploited, nor that a patched device is free of risk. A missing scan can make coverage look better or worse depending on how it is counted. State those limits in the report. The reader should know which part of the estate is invisible to the method.

Use the result to fix one visibility gap and one overdue device group. Then repeat the same report next month and compare the counts. If the unsupported group is not shrinking, the problem is detection rather than installation. The method should make that distinction obvious. A monthly cadence with a stable definition is more valuable than a perfect one-time audit.