Improvements to the “Detailed Patch Report”

Desired Improvements

1. Grouping by customer and device

The report should be structured hierarchically:

Customer (If the report is limited to a single customer, this step can be omitted; in that case, the customer’s name should appear in the report header.)

Device

Successfully Installed Updates

Failed updates

Possibly a second report for cross-checking:

Approved but not yet installed updates

Pending or unapproved updates

All updates for a device should be displayed immediately one below the other. This should be followed by the next device belonging to the same customer.

2. Clear display of the patch status

The current status must be clearly visible for each update, for example:

Installed successfully

Installation failed

Approved but not yet installed

Installation pending

Restart required

Not applicable

Rejected

If a patch has been approved but could not be installed successfully, it must be clearly marked as “Failed.” In addition, the last installation attempt and, if available, the error message or error code should be displayed.

In the current report, pending updates are displayed only with information such as device, update, severity, and KB number. A clear status indication is missing.

3. Resolving Recurring Pattern and Definition Updates

For regularly updated pattern or definition updates, only the most recent relevant version should be displayed for each device. This applies in particular to updates such as:

Security Intelligence updates for Microsoft Defender Antivirus

Virus and malware definitions

Other frequently updated signature or pattern updates

The current report sometimes lists multiple versions of the same Defender update for the same device. This makes the list unnecessarily long and causes the truly relevant information to get lost.

One of the following solutions would be desirable:

By default, display only the most recent version per device

Optionally display older versions via “Show Details” or a similar option when generating the report

Group pattern updates in a separate section

Optionally hide pattern updates entirely from the customer list

4. More Informative Summary

The summary should not only display the total number of devices, installed patches, pending updates, and patch compliance, but should also include the following information:

Report period: last 7 days, etc.

Number of fully patched devices

Number of devices with failed updates

Number of devices with approved but not installed updates

Number of pending critical and important updates

Number of devices with a pending reboot

Patch compliance per customer

Explanation of how patch compliance is calculated

For example, the audited report shows a patch compliance rate of 24%, but it is not clear how this figure was calculated. To provide evidence to the customer, the basis for the calculation would need to be clearly explained.

5. Additional Useful Details

For each patch, the following information should be displayed whenever possible:

Customer

Device name

Operating system

Update name

KB Number

Category

Severity

Approval Status

Installation Status

Installation Date

Date of Last Installation Attempt

Error code or error description

Restart required

Applicable patch policy

The goal should be a clear, comprehensible, and auditable report that can be used both internally for technical verification and externally as proof of patching for customers.

The report should show at a glance:

which devices have been successfully patched,

which devices require action,

which approved updates failed,

why an update was not installed,

and how the reported patch compliance is broken down.

In our view, grouping by customer → device → patch status, clear status indicators, and the reduction of recurring pattern updates are absolutely essential.